EXE hacking

[axdoomer]

Incredible! I wish we had all these hacks 20 years ago.

 

16 hours ago, xttl said:

still needs to be done:

• [...]
• anything else?

 

My suggestions:

• -dm3 to enable Deathmatch 3.0 rules. (weapons stay, items respawn)
• random sound pitch support

Deathmatch 3.0 is easy to implement. If my memory serves me well: In the function P_RespawnSpecials, there's a check for "deathmatch != 2" that makes the function return, you can make it "deathmatch < 2". Then the variable that gets set to 1 or 2 when the parameters -deathmatch or -altdeath are specified must be set to 3 when -dm3 is specified.

I've never been able to implement a new command line parameter in my hacks, so I just made -deathmatch set "deathmatch = 3" in my DM 3.0 hack. Did you have to make the EXE bigger when you added new command line parameters or did you reuse available space? (like the padding that Watcom puts between functions and contains junk)

Edited July 11, 2020 by axdoomer

[xttl]

I'm almost sure I once made a DM3.0 hack but I don't have it anymore, and it must have been years ago. I don't like random pitched sfx myself at all, but ehh, why not. (it only needs two arguments swapped in some calls to DMX, right?)

 

Transplanting the better GUS support from older versions of DMX in would be a cool idea (I even have a real 1MB GUS card lying around, though no DOS PC to put it in set up currently), but too complex / time consuming to implement. :(

 

10 hours ago, axdoomer said:

I've never been able to implement a new command line parameter in my hacks, so I just made -deathmatch set "deathmatch = 3" in my DM 3.0 hack. Did you have to make the EXE bigger when you added new command line parameters or did you reuse available space? (like the padding that Watcom puts between functions and contains junk)

 

Watcom always puts the full size (4096 bytes) last page into the exe for all sections except the final one, even if all the space isn't used, so I increased the vsize of the code section in LE header and got over 2900 bytes to use that way (2911 exact IIRC, currently used: 1532). IIRC at least one of Budko's hacks also did this to implement something (Hexen+ maybe?).

 

When I run out of those bytes, I'll probably start overwriting unused functions (like W_Profile, Z_DumpHeap, Z_FileDumpHeap, DDT's linked lists) next or load more code from a file on disk. (I already load an external file for Nerve/Sigil text strings to save more of those 2911 bytes in the last page for code)

 

I patch the old code on the fly which works on all platforms I know of despite the LE section privileges usually set to RX only for the code section. Perhaps it might become a problem at some point with LE Loader though... link1 link2 (I am going to put an option in to force all sections to just always have RWX privileges but who knows how long OSes are going to allow that)

Edited July 11, 2020 by xttl

[axdoomer]

10 hours ago, xttl said:

 I don't like random pitched sfx myself at all, but ehh, why not. (it only needs two arguments swapped in some calls to DMX, right?)

 

Apparently so. You have to swap "pitch" and "sep", but I never understood why the stereo separation still worked while the sound pitch was broken. If one was broken, both should be broken because of the swap.

[xttl]

There's an explanation in this thread:

 

specifically:

 

On 1/23/2016 at 3:07 AM, nukeykt said:

The sound code also updates non player sounds every tic, and always calls SFX_SetOrigin function with neutral pitch value. As a result DMX plays every sound with neutral pitch.

 

Later down in the thread, Linguica tested and found out there is a slight random variation in balance between L/R channels:

 

https://www.doomworld.com/forum/post/1549696

 

On another note: now that I got xdelta3 running in DOS, I started wondering if there would be interest in a downgrader package for Hexen v1.1 => Hexen retail store (full game) beta (and why not Hexen v1.0 => beta too), and would everyone here (esp. admins) be ok with uploading something like that? I think there's not one out there already (but maybe I just didn't search well enough :-)

[xttl]

New version:

 

• -fakenet parm added (all cheats intentionally still work in this mode)
• -requiem parm added (loads requiem.wad & reqmus.wad automatically and changes automap names)
• -forceopl3 added, also added -opl3mono to disable the awful (on headphones at least) hard L/R panning
• -dm3 added
• -brightfix added (makes zombieman and cyberdemon shooting frames fullbright)
• -nerve now loads nerve.wad and raises limits automatically without additional parms
• -doomplus parm (sets doom+ equivalent limits, though still only visplanes/vissprites/drawsegs are implemented)
• -skullbug is there but it doesn't work right yet (it doesn't do momz=-momz at all for floor bounces, instead of doing it but after momz has been set to 0 already, which IIRC can somehow desync demos...)
• sigil mode sets SKY5 now but otherwise isn't quite finished

 

I tried adding a key combo (easier to check for than a new cheat sequence ;) CTRL+ALT+K for killing all monsters on the map, but didn't quite manage to get it working right yet so it's disabled.

 

edit: One thing I thought about adding was a fix for the silent (west facing) respawns bug, but the problem is that it's cheating if the other player(s) don't also agree to enable that fix, and it is something that can't trigger a consistency failure. On the other hand, doesn't all serious 1v1 deathmatching happen in ZDaemon nowadays?

 

udoomhack_r2.zip

Edited July 13, 2020 by xttl

[fabian]

4 hours ago, xttl said:

-requiem parm added (loads requiem.wad & reqmus.wad automatically and changes automap names)

 

Great work, though this one appears a bit random. I mean, where is e.g. the -mm switch that loads mm.was and mmmus.wad?

[xttl]

10 hours ago, fabian said:

Great work, though this one appears a bit random. I mean, where is e.g. the -mm switch that loads mm.was and mmmus.wad?

 

Yeah I'm not actually sure if I'll keep it, it's really hard to decide where to draw the line if not sticking to strictly official (NR4TL & Master Levels) and semi-official (Sigil) expansions only. There are also already strings for Fava Beans and BTSX1 in the xtradata.bin file but no code yet.

 

(why Requiem? somehow I found it first back in the 90s and ended up linking it more than MM or MM2, neither of which I've still even played further than the first few maps, but if I don't forget about support for all non-official expansions, I'll add them them too)

 

^{oh yeah I guess HacX could also be considered official since it was licensed, but I never liked it much and it requires lots of DeHackEd modifications}

Edited July 13, 2020 by xttl

[Redneckerz]

Id wager less than Batman Doom :p

 

That UDoom v2 release is great. Have to sleep first but it is shaping up to be something special.

[plums]

12 hours ago, xttl said:

-opl3mono

Every port should have this option. Hard L/R panning for anything that's not dead-centre is indeed awful.

 

For the cheat sequence, you might be able to allow IDCLIP for Doom 1 and then take over IDSPISPOPD? You could also override IDCHOPPERS since no one uses that lol

Edited July 14, 2020 by plums

[Redneckerz]

15 hours ago, xttl said:

New version:

So this is going to be an amalgation of all your previous hacks (Nerve, Sigexe, Doom32, and so on) + Doom Plus limits and some more. 

 

I have to apologize for the consistent expletives but i cannot not be impressed with this work, same with LE Loader. When this UDoom executable is finalized ill be using it as my default executable for Vanilla stuff.

10 hours ago, xttl said:

 

Yeah I'm not actually sure if I'll keep it, it's really hard to decide where to draw the line if not sticking to strictly official (NR4TL & Master Levels) and semi-official (Sigil) expansions only. There are also already strings for Fava Beans and BTSX1 in the xtradata.bin file but no code yet.

Perhaps the official add-ons as seen in Doom Unity? That's still somewhat official. But supporting every Vanilla Megawad out there seems a bit excessive?

 

[xttl]

13 hours ago, Redneckerz said:

So this is going to be an amalgation of all your previous hacks (Nerve, Sigexe, Doom32, and so on)

 

Yes, that's the general idea. One EXE to rule them all, or something.

 

13 hours ago, Redneckerz said:

Perhaps the official add-ons as seen in Doom Unity?

 

I don't know about that, at least I wouldn't want to stick to only them if I'm going to add anything besides NR4TL, Sigil and Master Levels because it leaves some of my old favourites out (eg. Requiem, Alien Vendetta, Fava Beans). I might add some generalized mechanism to load replacement map names longer than possbile via DHE. (but longer intermission texts than possible in vanilla, changing intermission texts at all for wads which originally didn't change them, or changing map numbers after which texts are shown are not going to go in because it can affect demo sync).

 

Does anyone mind if I make the EXE file longer than original? cracker.exe/.crk style patching (just offset: old byte => new byte) doesn't really make sense after that, it'll have to be xdelta3, bsdiff or something else instead.

 

edit: I think source ports allow adding longer strings than originally possible in DEH files, and there's also BEX, MAPINFO, etc. so maybe I could use some kind of a binary format (I am not going to even attempt to write any kind of text parsing in ASM, I couldn't write a good parser even in C because I really am not that good at this) which contains wad names and assigned map names, then a tool which converts from DHE/BEX/MAPINFO to that format. WADs like Requiem and Fava Beans which don't come with a DEH file (or AV which only has a DEH with abbreviated names) would be included in the binary file out of the box.

Edited July 14, 2020 by xttl

[Redneckerz]

1 hour ago, xttl said:

 

Yes, that's the general idea. One EXE to rule them all, or something.

The executable will be named accordingly to LOTR.exe :')
 

1 hour ago, xttl said:

I don't know about that, at least I wouldn't want to stick to only them if I'm going to add anything besides NR4TL, Sigil and Master Levels because it leaves some of my old favourites out (eg. Requiem, Alien Vendetta, Fava Beans). I might add some generalized mechanism to load replacement map names longer than possbile via DHE. (but longer intermission texts than possible in vanilla or changing map numbers after which texts are shown are not going to go in because it can affect demo sync).

This is a difficult one to have an opinion over because this sounds like a personal preference for your favorite map sets.

1 hour ago, xttl said:

Does anyone mind if I make the EXE file longer than original? cracker.exe/.crk style patching (just offset: old byte => new byte) doesn't really make sense after that, it'll have to be xdelta3, bsdiff or something else instead.

Not at all, i have described CRACKER.exe on the wiki, but if xdelta3/bsdiff are also used, how do those work then?

Cracker/.crk style patching is easy to distribute (just a .crk file) so i wonder how it works with xdelta3/bsdiff.

 

Other than that i obviously don't mind, but is the resultant executable still 1:1 compatible with the original vanilla executable?

1 hour ago, xttl said:

 

edit: I think source ports allow adding longer strings than originally possible via DHE files, and there's also BEX, MAPINFO, etc. so maybe I could use some kind of a binary format (I am not going to even attempt to write any kind of text parsing in ASM, I couldn't write a good parser even in C because I really don't do this for a living ;) which contains wad names and assigned map names, then a tool which converts from DHE/BEX/MAPINFO to that format. WADs like Requiem and Fava Beans which don't come with a DHE file (or AV which only has a DHE with abbreviated names) would be included in the binary file out of the box.

I am not entirely sure if executables with included DehackEd patches are legit, several wads have a corrected release which seperates the dehacked patch as a seperate file.

[xttl]

It works like this: xdelta3 -d -s old.exe patchfile new.exe

 

I'll supply 4 separate patchfiles for the 4 different original v1.9 exes: regular, ultimate, final r1, final r2. The last one of those will be very small, the others will be larger because there are more differences compared to the base file. (for an earlier version of the hack the diff sizes were about: 125kB, 121kB, 48kB, 1.3kB respectively)

 

I might write some kind of a fancy UI which can automatically detect the old exe version and apply the correct patch (which are packaged into a single separate file, or into the patcher EXE itself), but right now the only thing I have is plain command line xdelta3 compiled for DOS, almost straight (couple of very minor changes were needed to get it to compile using Open Watcom) from the github repo I linked earlier.

[xttl]

16 hours ago, Redneckerz said:

but is the resultant executable still 1:1 compatible with the original vanilla executable? 

 

Yes of course, but I decided not to expand the file anyway (at least not yet), instead I moved all code except for a small loader into an external file

 

16 hours ago, Redneckerz said:

I am not entirely sure if executables with included DehackEd patches are legit, several wads have a corrected release which seperates the dehacked patch as a seperate file.

 

Well, the reason they did that was because they did not want to distribute complete (albeit modified) copies of doom(2).exe, it has little do with how many builtin map names are included (or not).

Edited July 14, 2020 by xttl

[Redneckerz]

6 hours ago, xttl said:

It works like this: xdelta3 -d -s old.exe patchfile new.exe

 

I'll supply 4 separate patchfiles for the 4 different original v1.9 exes: regular, ultimate, final r1, final r2. The last one of those will be very small, the others will be larger because there are more differences compared to the base file. (for an earlier version of the hack the diff sizes were about: 125kB, 121kB, 48kB, 1.3kB respectively)

 

I might write some kind of a fancy UI which can automatically detect the old exe version and apply the correct patch (which are packaged into a single separate file, or into the patcher EXE itself), but right now the only thing I have is plain command line xdelta3 compiled for DOS, almost straight (couple of very minor changes were needed to get it to compile using Open Watcom) from the github repo I linked earlier.

Short and concise explanation, perfect :) Thank you for this. Reading into it some more, this is a more general program for writing patches as opposed to cracker.exe, so its obviously more versatitle.

Good to hear also that the executable is still as vanilla as it can be - Too bad we can't go back in time and have such an executable back in 1996. But today, it might be a worthwhile executable never the less :)

 

15 minutes ago, xttl said:

Well, the reason they did that was because they did not want to distribute complete (albeit modified) copies of doom(2).exe, it has little do with how many builtin map names are included (or not).

In that timeframe it was understandable since id was privy on the legal salad of these things. But the executables need an IWAD anyway to function, so without it, they are just duds in that sense.

[xttl]

https://github.com/RandalLinden/DOOM-FX/blob/master/source/rlplayer2.a#L215

 

Just remove that somehow to get your circlestrafing.

 

I'm currently trying to find an assembler for this thing, found something called ARGOS2.EXE but it needs either OS/2 or old WinNT/Win2K to run apparently, lol.

 

somehow posted in the wrong thread...

Edited July 15, 2020 by xttl

[Redneckerz]

Its difficult to pick between FastDoom and @xttl's One Hack to Rule them all executable, because the latter would have been revolutionairy in the 90s.

Apologies for the enthusiasm, i just can't wait to test the finished hack/product out.

[OpenRift]

 

On 7/13/2020 at 1:13 PM, xttl said:

New version:

 

• -fakenet parm added (all cheats intentionally still work in this mode)
• -requiem parm added (loads requiem.wad & reqmus.wad automatically and changes automap names)
• -forceopl3 added, also added -opl3mono to disable the awful (on headphones at least) hard L/R panning
• -dm3 added
• -brightfix added (makes zombieman and cyberdemon shooting frames fullbright)
• -nerve now loads nerve.wad and raises limits automatically without additional parms
• -doomplus parm (sets doom+ equivalent limits, though still only visplanes/vissprites/drawsegs are implemented)
• -skullbug is there but it doesn't work right yet (it doesn't do momz=-momz at all for floor bounces, instead of doing it but after momz has been set to 0 already, which IIRC can somehow desync demos...)
• sigil mode sets SKY5 now but otherwise isn't quite finished

 

I tried adding a key combo (easier to check for than a new cheat sequence ;) CTRL+ALT+K for killing all monsters on the map, but didn't quite manage to get it working right yet so it's disabled.

 

edit: One thing I thought about adding was a fix for the silent (west facing) respawns bug, but the problem is that it's cheating if the other player(s) don't also agree to enable that fix, and it is something that can't trigger a consistency failure. On the other hand, doesn't all serious 1v1 deathmatching happen in ZDaemon nowadays?

 

udoomhack_r2.zip

So I did some testing today with your udoomhack executable, and I noticed that it also inherits the same problem that the id Anthology doom2.exe seems to suffer from, that being that player controls don't work when used to generate a doomhack.exe via dehacked. Have you found out about this phenomenon this since this was posted?

[xttl]

Hello, no sorry for no activity for while. Have had a bit of a love/hate thing gong on with spending too much time on games, Internet, and computers and tech in general for a while, plus some issues in life.

 

Cannot guarantee there how much if any further activity there will be, either, but today I happened to play around with the Aztech Sound Galaxy Pro 16 AB emulation in PCEm and found out Doom/DMX cannot detect MPU-401 with that setup. Music works fine if DMX is forced to always to detect the MPU, though.

 

No idea if there's a bug in DMX MPU detection code, if the MPU implementation of the card (or even all Aztech cards) is just too crappy, or if the emulation in PCEm is buggy in some way that prevents detection by DMX. Could be any of those. Regardless of which it is, I added a -forcempu parm to udoomhack to work around it. Perhaps it could be useful on some real hardware too.

 

Sorry if there's some half-finished thing in here from last time which I forgot about already that breaks stuff.

 

udoomhack_r3.zip

 

 

On 9/16/2020 at 1:10 PM, OpenRift said:

So I did some testing today with your udoomhack executable, and I noticed that it also inherits the same problem that the id Anthology doom2.exe seems to suffer from, that being that player controls don't work when used to generate a doomhack.exe via dehacked. Have you found out about this phenomenon this since this was posted?

 

I haven't really been a big user/lover of DHE since the late 1990s so I actually didn't know about this. :P I guess the reason that happens could be because DHE doesn't really know about the proper layout (offsets) of the Anthology EXE file, touches some bytes it shouldn't, yet due to some "good" luck the game doesn't crash but instead "only" controls become broken.

 

If this is the reason, then ideally somebody should just update DHE to support the Anthology binary. Dunno if anybody will ever do that. Maybe I will eventually, maybe not. No promises, definitely.

Edited October 30, 2020 by xttl

[OpenRift]

9 minutes ago, xttl said:

Hello, no sorry for no activity for while. Have had a bit of a love/hate thing gong on with spending too much time on games, Internet, and computers and tech in general for a while, plus some issues in life.

  

Cannot guarantee there how much if any further activity there will be, either, but today I happened to play around with the Aztech Sound Galaxy Pro 16 AB emulation in PCEm and found out Doom/DMX cannot detect MPU-401 with that setup. Music works fine if DMX is forced to always to detect the MPU, though.

  

No idea if there's a bug in DMX MPU detection code, if the card (or even all Aztech cards) is just too crappy, or if the emulation is in PCEm is buggy in some way that prevents detection by DMX. Could be any of those. Regardless of which it is, I added a -forcempu parm to udoomhack to work around it. Perhaps it could be useful on some real hardware too.

 

Sorry if there's some half-finished thing in here from last time which I forgot about already that breaks stuff.

 

udoomhack_r3.zip

 

 

 

I haven't really been a big user/lover of DHE since the late 1990s so I actually didn't know about this. :P I guess the reason that happens could be because DHE doesn't really know about the proper layout (offsets) of the Anthology EXE file, touches some bytes it shouldn't, yet simply due to some "good" luck the game doesn't crash but instead "only" controls become broken.

  

If this is the reason, then ideally somebody should just update DHE to support the Anthology binary. Dunno if anybody will ever do that. Maybe I will eventually, maybe not. No promises, definitely.

Well I would suggest giving Fdoompp another try, this time based on the unpatched non-anthology version to work with dehacked. It would honestly eliminate a lot of steps for what you're trying to do with the one exe to rule them all tactic. The problem with that is that the offsets for each executable (Doom, Doom 2, Final, anthology) are different, it's going to be very, very hard to have compatibility with dehacked patches for all four without going into source port territory. Even just in the context of Final Doom, how would you be able to apply patches for it if they're all based on the unpatched version?

 

For your own sanity's sake, it would be much easier to make a real Final Doom-plus from the unpatched exe to drop into your Plutonia and TNT directories than making an exe hack that:

 

• Is compatible with 1/2/Final dehacked patches
• Converts Final Doom patches to use anthology's offsets, or alternatively requires Final Doom patches to be in a completely different format
• Requires an updated version of dehacked for either of those things to work

I dunno about you but that sounds like a much harder task to accomplish than raising limits in the unpatched Final executable.

[xttl]

10 hours ago, OpenRift said:

The problem with that is that the offsets for each executable (Doom, Doom 2, Final, anthology) are different, it's going to be very, very hard to have compatibility with dehacked patches for all four without going into source port territory

 

DHE actually has always handled this quite well for supported versions. You can create a patch using v1.666 and apply it to v1.9 or vice versa, or create a patch using regular v1.9 and apply it to Ultimate v1.9 or vice versa. It's just that proper, full support for the second Final Doom has never been included in any version of DHE, and even support for the first Final Doom executable was only added in a late modification after Greg Lewis had already moved on to newer games and greener pastures. The source code to this modification has been lost, and the author is dead, IIRC.
 

10 hours ago, OpenRift said:

Well I would suggest giving Fdoompp another try, this time based on the unpatched non-anthology version to work with dehacked.

 

The Anthology version is just a much nicer base to use because it's the most complete and bugfree version. :(

 

Maybe one day I'll see if I can get DHE to work with the Anthology executable if nobody else wants to do it. DHE is open source, but 1) has to be compiled with the old Borland C++ compiler and would need some work to compile with Open Watcom which I'd much prefer to use, 2) source code to the Final Doom v1 update was never released.

 

edit: Actually, In theory it should already be possible to make it work with the Anthology version by specifying a custom Doom version in dehacked.ini ini and then manually specifying the offsets. But you won't be able to modify Final Doom specific text strings unless you use the Final Doom patched version I think, and I'm not sure if it allows to customize the offsets.

Edited October 30, 2020 by xttl

[xttl]

@OpenRift, can you link/attach a DEH patch you want to use but which doesn't work with the Anthology exe? I'll try and see if I can make DHE apply it correctly by editing offsets in dehacked.ini. Preferably something which doesn't require any wads, but post the wads too if it does.

[OpenRift]

19 minutes ago, xttl said:

@OpenRift, can you link/attach a DEH patch you want to use but which doesn't work with the Anthology exe? I'll try and see if I can make DHE apply it correctly by editing offsets in dehacked.ini. Preferably something which doesn't require any wads, but post the wads too if it does.

Well the #1 example that comes to mind is Plutonia 2. The only need for increased limits as far as I know is the usual savegame overflow nonsense. Otherwise it works perfectly fine with v1.

 

https://www.doomworld.com/idgames/levels/doom2/megawads/pl2

 

Edited October 30, 2020 by OpenRift

[P41R47]

59 minutes ago, xttl said:

@OpenRift, can you link/attach a DEH patch you want to use but which doesn't work with the Anthology exe? I'll try and see if I can make DHE apply it correctly by editing offsets in dehacked.ini. Preferably something which doesn't require any wads, but post the wads too if it does.

 

40 minutes ago, OpenRift said:

The only need for increased limits as far as I know is the usual savegame overflow nonsense. Otherwise it works perfectly fine with v1.

Same with TNT: Revilution

[xttl]

PL2 is something I would very much consider adding builtin support for to UdoomHack anyway (like how it already has eg. -nerve, -sigil, -requiem, -mm, -mm2 parms!). A major and cool mod.

 

Regardless, I got DHE 3.1 working with the Anthology executable now. dehacked.exe needs to be modified though, because the offsets for values from the F4 ("miscellaneous") page cannot be adjusted from dehacked.ini for whatever reason. The values that could be adjusted from the ini file seem to be (mostly?) already correct anyway, either they're the same or DHE autodetects the correct ones somehow.

 

A lot of these "miscellaneous" settings actually modify immediate values in the game code, not values in data tables like other stuff, so no wonder the Anthology exe gets totally fucked if you try to patch it using a version of DHE that doesn't know about it. You could also see how the F4 page in DHE is full of garbage if you looked at the unmodified Anthology using it.

 

So attached to this post is a modified DeHackEd v3.1 exe. This version ONLY works with the Anthology executable. Do NOT try to use it with regular Final Doom or it will destroy the target exe.

 

Sorry, but it has to be this way because source code for DHE 3.1 is not available, only 3.0, and I can't be bothered to warez and install Borland C++ to recompile it anyway.

 

Basically download original dhe31.zip from idgames, setup it for Final Doom as usual (version=5 in dehacked.ini) but replace dehacked.exe with mine.

 

Please report back if there are any problems.

 

dehantho.zip

 

edit: pl2.deh and suprwep8.deh seem to work but eg. dmarmy3.deh crashes, too tired to fix that, live with it for now. I suspect the problem might be code pointer replacements do not work correctly. I'll also add bultin PL2 support to UdoomHack.

Edited October 31, 2020 by xttl

[OpenRift]

3 hours ago, P41R47 said:

 

Same with TNT: Revilution

Something interesting about TNT: Revilution is that even if you load in something like Chocolate Doom, it crashes on startup with this error

 

Despite this it's still labelled as vanilla-compatible. If I run it in Crispy it launches no problem.

[OpenRift]

2 hours ago, xttl said:

PL2 is something I would very much consider adding builtin support for to UdoomHack anyway (like how it already has eg. -nerve, -sigil, -requiem, -mm, -mm2 parms!). A major and cool mod.

  

Regardless, I got DHE 3.1 working with the Anthology executable now. dehacked.exe needs to be modified though, because the offsets for values from the F4 ("miscellaneous") page cannot be adjusted from dehacked.ini for whatever reason. The values that could be adjusted from the ini file seem to be (mostly?) already correct anyway, either they're the same or DHE autodetects the correct ones somehow.

  

A lot of these "miscellaneous" settings actually modify immediate values in the game code, not values in data tables like other stuff, so no wonder the Anthology exe gets totally fucked if you try to patch it using a version of DHE that doesn't know about it. You could also see how the F4 page in DHE is full of garbage if you looked at the unmodified Anthology using it.

 

So attached to this post is a modified DeHackEd v3.1 exe. This version ONLY works with the Anthology executable. Do NOT try to use it with regular Final Doom or it will destroy the target exe.

  

Sorry, but it has to be this way because source code for DHE 3.1 is not available, only 3.0, and I can't be bothered to warez and install Borland C++ to recompile it anyway.

  

Basically download original dhe31.zip from idgames, setup it for Final Doom as usual (version=5 in dehacked.ini) but replace dehacked.exe with mine.

  

Please report back if there are any problems.

 

dehantho.zip

Well first of all: holy shit, it actually works!! 

 

HOWEVER, I do a savegame test with PL2 and it still freezes on attempting to quicksave. Has the savegamesize limit not been raised for udoomhack? Or am I missing something here?

[xttl]

Yeah, unfortunately I didn't get around to increasing save game buffer size yet.

 

Also with regards to your problem loading TNTR in Chocolate, have you tried using -merge or -nwtmerge instead of -file? It might also require it's .deh to be always loaded if it uses a vanilla dehacked trick to load sprites without merging wads. That discussion probably belongs more in the Chocolate Doom support thread anyway. :P

Edited October 31, 2020 by xttl

[OpenRift]

Just now, xttl said:

Yeah, unfortunately I didn't get around to increasing save game buffer size yet.

  

Also with regards to your problem loading TNTR in Chocolate, have you tried using -merge or -nwtmerge instead of -file? That discussion probably belongs more in the Chocolate Doom support thread anyway. :P

Yeeeeaaah you should probably add that savegame buffer increase, that's like the first thing I think people want out of exe hacks.

 

As for TNTR, yeah, seems merging the IWAD just works. I didn't know you had to do that for Revilution.

[xttl]

10 hours ago, OpenRift said:

Yeeeeaaah you should probably add that savegame buffer increase, that's like the first thing I think people want out of exe hacks

 

Sure, but it is also a bit more complex to add than anything that has been already implemented so far, at least if done right (=with direct saving to disk file added, unfortunately game exe doesn't already include normally unused code for that like Heretic & Hexen do). Same reason longtics isn't in yet, it needs more extensive game asm code patching which is annoying to do on the fly (the previous hacks which included it statically patch it into the exe on disk, this hack tries to keep almost all patching in memory except for short "loader" that is patched into normally unused space added for padding code section to 4kB page size). I have been implementing the simplest features first.