If you're using TB you can actually hide certain brushes.

Just go to the View tab on the right and deselect Detail Brushes. 

I use Netradiant, and never could get into TB unfortunately (although I like the sound of TB2 - I may have to have a goosey at that).

For now, I notice that rebb's txqbsp has an option to "make detail leak" for this exact purpose, so I can try that I guess. 

Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities ... altho I don't know much about Radiant these days. 

Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities ... altho I don't know much about Radiant these days.

Hiding anything in netradiant does not exclude it from compile, so that would not help in debugging detail-sealing-void issues 

Use txqbsp_xt, there is a switch -makedetailleak that does what you want. 

Aye, that will have to do 

In radiant, you just press L to bring up the entity list, and select all the func_details by clicking the first one and shift-clicking the last one in the list... you just just delete them, save as, and compile the detail-less version. 

In radiant, you just press L to bring up the entity list, and select all the func_details by clicking the first one and shift-clicking the last one in the list... you just just delete them, save as, and compile the detail-less version. 

I know there's been plenty of talk of a prefab feature before, and I think last time it ended with people talking about doing it editor-side.

However, I never like the idea of restricting the choice of editors, and I know plenty of us are using an editor that is no longer in active development (e.g. netradiant) and really want to stick with it, so is it worth talking about a compiler-side prefab feature?

The user interface would be simple - a "func_prefab" entity with a key that points to the filepath of a .map file containing whatever you want copying over. Rotation should work as expected. I don't think scaling would get used as much but that might also be worth supporting

Of course in old editors you'd lose the ability to see the geometry in your map, but in a lot of cases I don't think this would be much of an issue as you'd position the brushes in your prefab map file so that a sensible anchor point would be at the origin.

Thoughts? 

Is how to ensure that the textures are still aligned. Translation is easy, scaling is not so easy, and rotation is a bitch. Also difficult are targetnames etc. 

someone mentioned having written or used such a tool on their jam map. Seems like a great idea to me, I also like making it a standalone tool so it's not tied to one editor or compile tool.

Sleep- one idea to help with texture alignment is to have the postprocessing tool convert the map to Valve 220. That should make it easier to preserve texture alignment. Since it's a postprocessor it doesn't matter if you editor can read 220, and all qbsp's these days can. 

Eric, I didn't think anyone was paying attention when I mentioned that during the last jam! :)

The "someone" in question was me. Over a couple of days before map jam 6 I hacked together some changes to Metapyziks' "VMFInstanceInserter", and while building "Princess of China" used it to place the light fixtures, skin bridges, totems, and of course googly eyes.

VMFII was built to allow the use of the func_instance entity in branches of the Source engine whose tools don't natively support it, namely Half-Life 2 and its episodes. With the map and FGD file formats of Source being based, as they are, on the Quake/Worldcraft tradition, I figured I could simply conform both types of files to the expected formats on input to VMFII, then postprocess them back to Quake land before spitting out the results. It seems to have worked out, and saves the trouble of duplicating an entire codebase of translation/rotation code.

The .map branch of my fork of the project can be found at https://github.com/ItEndsWithTens/VMFInstanceInserter/tree/add_map_support if you're interested. Github makes it easy enough to get back to the upstream project if you want to look at that, and you can see https://developer.valvesoftware.com/wiki/Func_instance for more details of how instances work in Source.

As for features, name fix up works just fine, prepending or appending a name (either one of your choice or an automatically generated unique) to your entity connections to make sure each instance remains separate, and variable replacement is no different. The func_instance_parms, _io_proxy, and _origin entities mentioned on that SDK Docs page don't work, mind you, but that's not unique to my Quake additions.

There are some caveats:

-I haven't released any binaries of my custom changes yet; I could always run off a few private builds for testing, but I haven't yet contacted the original developer to see if he's receptive to support for other games, or if he's satisfied with my approach in the event he is.

-I haven't updated the documentation, and there's a bug in Jackhammer I just realized I forgot to mention in its respective thread that keeps this tool from working conveniently there.

-The program is written in C#, so running it in Linux/OSX is sure to be tricky. What research I've done suggests it's not impossible, though, especially without any GUI libraries to worry about, and I have access to a Mac Mini with the latest OS X and as many Linux VMs as I have disk space for, so I can certainly take a crack at building it there.

-There's no scaling support. I don't have enough 3D graphics theory under my belt to even begin tackling a thing like that, and I don't know what effect it might have on Source instances (which don't support it either) in any event, so I don't know how realistic this one is.

-My code currently requires the Valve 220 .map format, but really just because that's what Jackhammer produces, and I was building my map in that editor. I can take a look at adding a little something to handle other types of map, I suppose. 

That sounds very interesting!

PS: I wouldn't bother with scaling - I mean there might be some situations where you might want to scale a prefab (e.g. the depth of an arch) - but you've got to worry about what the textures do on the surfaces that get affected by the scaling (e.g. inside of the arch), and you're probably better off just making multiple prefabs to cover the small number of scale variations that you'd want. 

The dev builds now have Hexen 2 support ("-hexen2" flag for qbsp. Thanks Spike!), and also the qbsp "-epsilon" flag from txqbsp.

http://quakespasm.ericwa.com/job/tyrutils-ericw/ 

I'll start a dedicated thread around here eventually, so as not to hijack this one, but I thought I should mention I finally got around to cleaning up and releasing the instance thing I talked about.

The changes I made to that other project, VMFII, turned out to be awfully clumsy implemented that way, so I turned the code into its own wrapper project. Curious parties can try out Quinstance from the releases tab of its Github page: https://github.com/ItEndsWithTens/Quinstance

Instructions are included, have fun! 

So it's almost like how external bsp's are used as bmodels? 

I'll tentatively say yes, I believe it's something like that, but I've never worked with bmodels before, only heard vague whisperings of their existence.

I think the best way to describe it is that it's like using prefabs, but any changes you make will automatically be applied to every instance you've already placed, and using a standalone tool means it's editor and compiler agnostic. 

Can Jackhammer render a preview of the func_instance? That would be crazy. 

I'll add support to TrenchBroom 2 as well. 

Sadly no, eric, you don't get a preview in Jackhammer. I only focused on JH when building the included FGD because it's the editor I was using. Positioning things can be slightly irritating when you can't see what you're placing, but keeping Quake running in a window makes it easy to adjust/recompile/reload/repeat, so it's workable. Of course I'd love to see actual display of the instance contents, but it's just wishful thinking for now.

SleepwalkR, that sounds wonderful! Bear in mind I'm not trying to present this as the be-all end-all solution, just one I found useful for my own project. If someone comes up with a better way to do things, I'd be just as happy to use that. 

a copy of the other map's contents will have appeared where the func_instance once was

Are they aligned by their center coords? If this is the case, I would probably try to make func_instance a brush entity of the same size as the prefab, like a bounding box. That would help keep things on grid. 

Ah, thanks for the question, I'll need to clear this up in the documentation. The instance contents are not positioned based on their collective center, no. The center of the point entity and the origin of the instance map are lined up. All objects in the Filename map get offset from the func_instance by the same distance they're offset from their own map's origin, so it's reasonably straightforward to predict where things will be when all's said and done.

The Source engine tools' version of instances does have a func_instance_origin that lets you define a custom origin, actually, but VMFII doesn't yet implement that, so it won't work with Quake maps until that changes.

I should have a News post written up in a few minutes, so if it's accepted we can take further discussion over there. Hang tight! 

When using func_detail, you have leaves (subdivided volumes of the map, including func_detail) and clusters (volumes ignoring func_detail). The vis speedup when using func_detail comes from vis only looking at portals between clusters.

What it was doing before was writing a copy of the visdata for a cluster for each leaf in that cluster - I just changed vis to write a single copy of the visdata for each cluster, and then all of the leaves in the cluster reference the same visdata offset in the bsp file.

All this really does is shrink the bsp file (telefragged.bsp is 10mb smaller) and maybe load a tiny bit faster as a result, but it seems like a nice optimization. Seems to be safe with old engines (winquake.exe) too. 

 

Does light use the pvs data (if present) in any way to speed up traces?