Open kitchen-ace opened 9 months ago
Although I added support for the HEHACKED lump to Crispy (it was done for this project), I'm not sure we should encourage its use for modding Heretic. It's much less developed than DEHACKED for Doom, and there are no tools other than the original DOS HHE
program.
I think the HHE
support in Chocolate Heretic was mainly done for compatibility with old PWADs.
Everything about HEHACKED is absolutely a mess, no argument there.
I didn't read everything on the doomuniverse thread, but I assume they're only using HEHACKED for strings? Quoth The Raven also uses one for this purpose, and @NightFright2k19 was also using it for a patched up version of H!Zone. Unfortunately right now there's no way to get episode 4 or 5 strings without -hhever 1.3
.
An alternative option might be to support BEX syntax strings for the obvious stuff -- level names, episode names, and end texts at a minimum. Any theoretical full-featured HEHACKED replacement is better off using this syntax anyhow. ZDoom actually supports naming Heretic map names through Dehacked with the label HHUSTR_ExMy
and end texts with HExTEXT
(an embedded wad lump must be named DEHACKED, but can also read other lumps with INCLUDE
) but not episode names AFAICT. See https://github.com/ZDoom/gzdoom/blob/master/wadsrc/static/mapinfo/heretic.txt
I didn't read everything on the doomuniverse thread, but I assume they're only using HEHACKED for strings?
Yes, you're right.
ZDoom actually supports naming Heretic map names through Dehacked with the label HHUSTR_ExMy and end texts with HExTEXT (an embedded wad lump must be named DEHACKED, but can also read other lumps with INCLUDE) but not episode names AFAICT.
I didn't know about this. I think it is better to implement UMAPINFO support in Crispy, but it will take time.
Just a random idea: if the lump is HEHACKED for Heretic, then for Hexen it should be... HEXACKED? ;)
Will resolve #1167
I chose to implement checking a HHEVER lump; relying on heuristics alone is too ambiguous (though might be beneficial as an addition), and adding the info in the HEHACKED lump itself is too annoying for people who might want to work with HHE and would constantly have to manually edit their patch.
Outstanding issues:
I get this warning that I don't know how to fix properly:
crispy-doom/src/heretic/d_main.c:1195:9: warning: implicit declaration of function ‘SetHHEVersionFromLump’ [-Wimplicit-function-declaration]
including
"deh_htic.h"
, where the function is declared, gives an error instead:crispy-doom/src/heretic/deh_htic.h:53:8: error: unknown type name ‘deh_section_t’
I'm probably missing something obvious but I'm not sure what.
Do I need to sanity-check the HHEVER lump? We only need to ever read 3 bytes from it.
Right now I've set it to ignore the HHEVER lump if
-hhever
is specified, but there's no technical reason this needs to be the case; it seems fine if you add a patch with-deh mypatch.hhe -hhever 1.0
and then read more patches from HEHACKED lumps from the wad, with HHEVER set to 1.3. Thoughs/opinions?Even with this implementation, it's still possible to load 1.0 patches (the default) outside of a wad without a
-hhever
parameter. I think this is important since that's necessary for autoload without specifying a HHE version.