Hexen 2 Modification

[stevenaaus]

Yay for H2 modders
I still have a big soft spot for this game.

[leileilol]

i'd love to play it with people but there's several factors why not:

- not many people own it
- the single player game itself is pretty bad and is probably the second weakest Quake engine singleplayer ever (second to CIA Operative Solo Missions)
- it's still expensive on steam, which fights incentives to purchase it until mass sale seasons or Quakecons
- my Free Data project seems to be in a standstill with a H2MDL exporting pipeline issue (reapplying the palette/importing skin in QME 3.1 is such a pain, as well as setting special translucency bitflags for alphatests/explosions/etc)
- no interest in said project, despite having some distinct art direction and a whole new palette


Also, while it's not obvious due to the thematic setting, Jedi Knight II and Jedi Academy with ForceMod makes it play very similar to Hexen II. but it's all pointless says the Free Software demigod who wants to make a free media project for a freeware game....

[revelator]

The old BSP editor also supports hexen2 and also has opengl preview.

I helped porting the code some time back, but it could use some improvements.
Sadly im not really fit for any major coding atm due to illness, but if someone finds the time it could pretty easily be brought up to speed.

[Spike]

leileilol, could always just depend upon texture replacements. :s

[goldenboy]

What Hexen 2 really, really needs, is BSP2 support. I had to abandon work on a Hexen 2 level a few months ago because it ran into the clipnodes limit. Here's why:

The Hexen 2 devs added more clipping hull sizes for monsters, but forgot to increase the corresponding limit in the BSP format. As a result, Hexen 2 allows for much smaller levels than even Quake.

No, the hub system is not a solution. That still requires you design your level around the hub system, which simply is not always feasible.

I would make several Hexen 2 maps if this issue was resolved. I've got a large and beautiful one on the shelf, already, but cannot finish it because it won't compile. This situation is a huge turn-off for artists.

Another turn-off is the license mess. If I can't be sure that something is GPL, I'm always debating if I should touch it with a 10 foot pole.

And if someone lectures me again about how "big levels aren't needed or appropriate" you can shove it where the sun doesn't shine. Artists should not be limited by 20 year old file format restrictions.

[qbism]

bsp2 + HoT = HOT!

[Spike]

gb, I think that's something to ask Tyrann for, and boils down to only 3 steps...
1: increase MAX_MAP_HULLS from 4 to 8, and fix all the code to cope with that change. Map should then load in hexen2 engines. Obviously, this gets complex if you wan the same bsp to support q1bsp29+q1bsp2+h2bsp29+h2bsp2, depends how clearly bsp2 was implemented I guess. There's no version hints that say whether its got space for 4 or 8 hulls. FTE uses a hueristic: if dq1model_t[0].numfaces==0. If its 0 then its a regular q1 model. If its not 0, then the bsp has really weird face ordering or its hexen2. Obviously, if you use commandline arguments or just change the preprocessor constant then you don't need that heuristic.
2: Change the size of hull 2, and generate hulls 3+4+5. Sizes should be -24 -24 -20 24 24 20, -16 -16 -12 16 16 16, -8 -8 -8 8 8 8, -48 -48 -50 48 48 50. Hull generation may require a few extra calls in multiple places. The actual hull sizes are specified somewhere around brush.c's LoadBrush function.
3: Optionally flag the map as 'mission pack' by setting worldspawn's spawnflags |= 1 (earlier versions of hexen2 used some other size for hull 4, thus the engine doesn't know the size and will normally refuse to use it unless its flagged like this). Or you can just require the mapper/editor to do this.

once the maps exist, it'd be much easier to get engine modders to add support. until then there's only one engine that supports it.

[qbism]

Does that mean FTE already could support bsp2 in Hexen2? Are there still essentially (3) slightly different engine implementations (file formats) of bsp2 including RMQ, FTE and DP?

[Spike]

hexen2 has a different 'dmodel_t' lump. this lump is not affected by the bsp2 stuff as everything was ints+floats in the first place.
so while I've never actually tested h2bsp2 support in fte, there's no reason it won't work.

fte has never defined its own bsp2 variant, except in terms of modifiers that also apply to bsp29 - it merely considers the hexen2 support feature as distinct and complementary from the bsp2 feature. However you define it, you're not likely to want it for q1 modding as it would pretty much break shamblers, ogres, vores, etc.
Thus any 'extra' format support in fte that isn't supported in rmq or dp is exclusively useful to hexen2 and not quake, so there's no concern about fragmentation, if that's what you were getting at.

I would expect a qbsp that supports both to provide separate -bsp2 and -h2 arguments or something, as the two features are distinct (or to simply notice the useless extra brush .map fields and ignore them other than defaulting to hexen2 output).

And yeah, I forgot about those extra .map fields you find in hexen2 .maps. That's the problem with focusing on engines instead of tools I guess. Anyway, they're not used, the qbsp can ignore them if I recall correctly.