http://triptohell.info/moodles/junk/tyr-h2.patch
adds -hexen2 argument to qbsp to generate a h2(mp) bsp.
vis and light also accept hexen2 bsps.

doesn't do anything about palettes.
silently ignores hexen2's extra 'light' attribute of each plane, if specified. this is consistent with other hexen2 tools (iiuc).
doesn't do any special behaviour with watervis, so unlike hexen2 lava is watervised by default.
do NOT try loading a hexen2 bsp in a quake engine (other than ones that explicitly support it). doing so will likely result in crashes (and vice versa).

-hexen2 -bsp2 are accepted simultaneously. fteqw supports this, other hexen2 engines will need to be tweaked now that there's a tool that can actually generate them. this relaxes the clipnode limit that otherwise severely limits the sizes of hexen2 maps (to two fifths of a quake map, approx).

let me know if I broke anything... 

wow, thanks! this will be nice to have.
I will test this a bit and merge it in.

ExportClipNodes is confusing, I don't get what the "diff" variable is doing and why was it only modifying model->headnode[1], but it will probably be clear if I watch it in the debugger. 

yeah, that took me a while to figure out too...

its reordering the clipnode trees because they're calculated by hulls then models, but stored in the file as models then hulls, so the previously stored hulls need to be remapped to cope with the clipnodes added into the previous models (ie: clipcount has changed since the tree for the previous hull was generated).
the alternative would be to store the trees as-is and fix them up later.

I forgot to do anything about world.spawnflags&1 signifying mission pack+hulls. I'm not sure that there's much point in it not being set, but meh. 

Hexen 2 bsp2 support - cool, I might finish my big H2 map then. I considered using it elsewhere but it doesn't really match there either. It has been just collecting dust since it broke the format like a clumsy child breaks eggs. :-/

just like my ROEM maps have been collecting dust since I got vaguely pissed off with RMQ gameplay and Quake at large but was too bored, sick, busy to do much about it. Can't puzzle out the gameplay but also can't release them for vanilla quake (too big, too spacious etc)

anyway, hordes of fucking archer knights, at the ready? I'll have to try H2BSP2 some day.

uh, Hexen 2 jam in honour of this feature? Or am I hallucinating. I probably am. No one makes Hexen 2 maps anymore. If you want to Hexen 2 map, hit me up? 

Detail brushes that are (I imagine) accidentally used to seal the void are bad, right? Might it be worth putting in a -nodetail switch or something that lets you do a test compile that discards all the detail brushes, allowing you to find leaks that are purely in the (non-detail) world brushes? 

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.