Creating an "Auto-Dehacker" for vanilla?

[Redneckerz]

23 minutes ago, Doomkid said:

The real reason is that, even in an OS where Doom.exe and Dehacked.exe work (either DOS or 16bit Windows), there's a bit of rigamarole: You have to run Dehacked, then confirm you want to generate a clean/new Doomhack, press W to write your changes to Doomhack.exe, close the program, then rename Doomhack to <insert name here>.exe.

 

I basically just wanted a tool that automated all of that crap with a single run (which would have to be able to run in DOS). I figured it could all be done with a batch file that just executes all of those commands in order, but the hard part - which would make it an "all purpose" tool - would be getting it to automatically detect whatever .deh file is in the same directory as the tool itself, so that it knows what .deh is to be loaded into Dehacked, and thus which .deh will be used to generate a new modified DoomHack.exe

Would The Ultimate WAD.BAT be of use here?

[Lobo]

58 minutes ago, Redneckerz said:

My impression is that you only need to run DeHacked once. See below :)

I quite get that. The .deh file name will make a unique executable with the unique name. But first you need to have DoomHack in place, and that's the one you generate with DeHacked.

 

So basically, this is what i think you mean:

• Generate a DoomHack.exe through DOS Dehacked
• Run AutoDehack and select Roks.deh
• Clicking on ''Process'': AutoDehack uses the Doomhack.exe that we generated by DeHacked and the resultant exe is Roks.exe
• Done.

 

 

You're putting the horse behind the cart :) You don't get a Doomhack.exe unless you apply a .deh file first.

 

You generate doomhack.exe by using Dehacked.exe to apply/patch a .deh to the original Doom.exe. There's no point having a doomhack.exe which is just a renamed copy of Doom.exe: you have to patch Doom.exe with the .deh file which gives you an altered/patched Doom.exe. 

 

Unfortunately, here that isn't happening because dehacked.exe won't run for me and therefore won't generate a doomhack.exe.

[Redneckerz]

10 minutes ago, Lobo said:

You're putting the horse behind the cart :) You don't get a Doomhack.exe unless you apply a .deh file first.

:O I see now. I can generate a DoomHack.exe without any .deh file however through DOS Dehacked. Its just a copy of Doom2.exe.

 

But i see what you mean. IR Stupid.
 

10 minutes ago, Lobo said:

Unfortunately, here that isn't happening because dehacked.exe won't run for me and therefore won't generate a doomhack.exe.

So basically what one needs is a cheezy wrapper that translates DeHacked calls from DOS to Windows.

And here is exactly why you preserve things - Myk had an auto-patcher but i can't find jack about it.

[JadingTsunami]

1 hour ago, Redneckerz said:

So basically what one needs is a cheezy wrapper that translates DeHacked calls from DOS to Windows.

 

@Lobo - I think the easiest way to tie this off is use the GUI to generate a .INI and a .BAT in the same folder. The .BAT would run Dehacked with the INI file and generate the EXE.

 

The process would (unfortunately) be two-phase:

 

1. Run the GUI to generate the .INI and .BAT

2. Go to DOSBOX and run the .BAT to generate the hacked .EXE

 

The alternative I can see is to get ahold of Borland and write it in a DOS CPP program. There may be some way to send remote commands to DOSBOX but I'm not aware of it.

[Lobo]

I guess there are several workarounds but at the end of the day we'll be jumping through hoops and needing to do multiple steps to achieve something which in theory needed to be a simple click-boom-done process.

[JadingTsunami]

22 minutes ago, Lobo said:

I guess there are several workarounds but at the end of the day we'll be jumping through hoops and needing to do multiple steps to achieve something which in theory needed to be a simple click-boom-done process.

 

I suppose the Dehacked source is available; recompilation for Windows is an option. There is also WhackEd4 which is open-source and written in Python. Adding a new command line argument for a "batch mode" would be another.

Edited June 1, 2020 by JadingTsunami

[Lobo]

The more I think about it the less sense the whole thing makes.

 

Like Redneckerz said near the beginning, just having the patched Doom.exe is not very useful anyway because the vast majority of .deh mods will use custom graphics so you're gonna have to mess with DeusF 95% of the time.

 

Seriously, just use a sourceport! ;)

[Doomkid]

Even outside of the obvious "use a source port" option, running dehacked and generating a doomhack.exe in DOS literally takes about 20 seconds anyway.. I partially wanted this for my own laziness, but also for anyone who had trouble getting .deh files to work right in vanilla -- but, actually thinking about it -- it's probably a safe assumption that anyone with the patience to even bother booting DosBox just to to play Doom probably can handle the process of running dehacked and generating a DoomHack.exe manually 😅

[Doomkid]

32 minutes ago, JadingTsunami said:

I suppose the Dehacked source is available; recompilation for Windows is an option.

Recompiling a 32bit version of DeHackEd would definitely solve the problem and make the AutoDehacker which Lobo made a whole lot more viable.

 

My preference would be a "DOS compatible variant of AutoDehacker" just because it feels like someone wanting to run vanilla Doom is probably already going to have exited to DOS anyway, but that's splitting hairs. Really, either/or would be grand.

 

Also, just to give some context to why I wanted this.. I was hoping to include it with this big "100% DOS compatible" pack of wads, many of which come with a .deh lump. Just so you know I wasn't arbitrarily requesting this for no other reason than my own insanity!

 

[Redneckerz]

16 minutes ago, Doomkid said:

Even outside of the obvious "use a source port" option, running dehacked and generating a doomhack.exe in DOS literally takes about 20 seconds anyway.. I partially wanted this for my own laziness, but also for anyone who had trouble getting .deh files to work right in vanilla -- but, actually thinking about it -- it's probably a safe assumption that anyone with the patience to even bother booting DosBox just to to play Doom probably can handle the process of running dehacked and generating a DoomHack.exe manually 😅

I think generating DoomHack isn't the hardest part of this process.. it is something Lobo did reference, which is DeusF. A lot of these bat files featured in these WADS make a DoomHack first and then append the whole thing using DeusF, before writing it down to a final executable.

 

So if you want to go all-DOS, you will have to take DeusF into account. And an automatic recognition for which WAD needs DeusF and which does not is quite difficult. If you would want that, then it would be wise to only do this for the bigger releases.

 

13 minutes ago, Doomkid said:

Recompiling a 32bit version of DeHackEd would definitely solve the problem and make the AutoDehacker which Lobo made a whole lot more viable.

 

My preference would be a "DOS compatible variant of AutoDehacker" just because it feels like someone wanting to run vanilla Doom is probably already going to have exited to DOS anyway, but that's splitting hairs. Really, either/or would be grand.

 

Also, just to give some context to why I wanted this.. I was hoping to include it with this big "100% DOS compatible" pack of wads, many of which come with a .deh lump. Just so you know I wasn't arbitrarily requesting this for no other reason than my own insanity!

 

You know that's actually a perfect argument as to why you would want to do have this.

[Lobo]

ok, so now I see you're not nuts! 😉

 

But I still think you could have saved yourself a world of pain just including some almost-vanilla source port which can handle deh and pwads right out of the box. I'm thinking an older version of prboom or something along those lines.

[Redneckerz]

12 minutes ago, Lobo said:

ok, so now I see you're not nuts! 😉

 

But I still think you could have saved yourself a world of pain just including some almost-vanilla source port which can handle deh and pwads right out of the box. I'm thinking an older version of prboom or something along those lines.

Another possibility might be using DOSBox as a GUI. The VanillaDM project provides a real easy to use GUI to set up DOSBox multiplayer Vanilla Doom sessions, and even includes settings to configure its included DOSBox.

 

If a native program is not possible, a glorified frontend that makes DOSBox behave more like an actual port could be another option. That way you can do the whole DeHackeD thing through a GUI whilst launching it in DOSBox. Including DeHacked in such a package would be easy - Its not a big program after all.

 

Also DoomWiki seems to be down at the moment.

[JadingTsunami]

@Doomkid I think you will have to decide what direction you want to take.

 

It is fairly simple to create a crawler that will:

 

1. Go into each subdirectory and look for a .WAD and .DEH file.

2. If found, generate a DeHackEd INI and BAT file that would construct the EXE for that WAD/DEH pair.

 

This would let you, on your local machine, generate batch files for running each WAD/DEH pair and release that with the WAD pack.

 

The more generic options are:

 

1. 32-bit DeHackEd (or modified WhackEd4) + AutoDehack from Lobo

2. DOS DeHackEd + New DOS Program

3. DOS DeHackEd + DOSBOX wrapper

 

To me, option 1 above makes the most sense. But you may have other goals.

[P41R47]

After a few days reading all this thread, i wondered why WhakEd doesn't have an option to generate a doomhack.exe.
Isn't whaked a modern version of the old dehacked? or at least, a modern way to generate dehacked patches?

So, why it doesn't have an option for generating a doomhack.exe?
Please, correct me if i'm wrong.

I think it would be faster, easy, if we talk to @exl and find a way to properly implement this as a feature, because, every now and then, we need to check things out on the original .exe

[andrewj]

4 hours ago, P41R47 said:

I think it would be faster, easy, if we talk to @exl and find a way to properly implement this as a feature, because, every now and then, we need to check things out on the original .exe

It looks to me like WhackEd can only read an EXE, not modify/create a new one.

 

In other words, it's main purpose is to be a DEH editor, not an EXE patcher.

[Redneckerz]

2 hours ago, andrewj said:

It looks to me like WhackEd can only read an EXE, not modify/create a new one.

 

In other words, it's main purpose is to be a DEH editor, not an EXE patcher.

But so is DeHackED. And generating a DoomHack executable requires more than just DeHacked in order to make a custom executable (Not to be confused with limit raising executable's which are hex-edited)

 

12 hours ago, JadingTsunami said:

@Doomkid I think you will have to decide what direction you want to take.

 

It is fairly simple to create a crawler that will:

 

1. Go into each subdirectory and look for a .WAD and .DEH file.

2. If found, generate a DeHackEd INI and BAT file that would construct the EXE for that WAD/DEH pair.

 

This would let you, on your local machine, generate batch files for running each WAD/DEH pair and release that with the WAD pack.

 

The more generic options are:

 

1. 32-bit DeHackEd (or modified WhackEd4) + AutoDehack from Lobo

2. DOS DeHackEd + New DOS Program

3. DOS DeHackEd + DOSBOX wrapper

 

To me, option 1 above makes the most sense. But you may have other goals.

I am not DoomKid (Oh hell no, i can't even compare to his works!) but i would go with option 3 as that re-uses most of what already exists. a 32 bit DeHackEd means a source change, but i can imagine someone like @fraggle, in the same spirit as his libtextscreen tool, to make some weird Chocolate DeHackEd that essentially does what Chocolate Doom does, but for DeHackEd. So with the ability to generate DoomHack executables and such.

 

You could expand upon that by integrating native DeusF support since the two programs were so often used together, similarily to how Chocolate Doom takes some liberties to enhance the experience, but only where that makes sense.

 

It would certainly be the most elegant option since its a straight conversion of DeHackEd to Windows, and because of Fraggle's Quality seal of approval. Just sharing a thought.

 

''But can't you use Whacked then?'' Well yeah, but you will miss out on the things that make DeHackEd (Especially in conjunction with DeusF) unique. Whacked does not recreate DeHacked's full feature set fully: It creates the same kind of patch that DeHacked produces, but it does not fully emulate DeHackEd whatsoever.

But in the here and now (I imagine porting DeHacked over to Windows is no easy task despite sources available), Option 3 makes the most sense for me.

Besides, DoomKid wants to stay in the DOS realm, so the above only really is an option if you want to recreate the Dos experience natively on Windows, which by all means is quite a feat, i figure.

[JadingTsunami]

@Doomkid Here is something to try. You need to make sure your DEHACKED.INI loads patches from the current directory (i.e., make sure that your INI file has patchdir = .).

 

Running this will (a) find all the .DEH files in the directory, (b) prompt the user to choose one, then (c) apply it as a patch and copy DOOMHACK.EXE to the dehacked patch name with a .EXE extension.

 

You might need CWSDPMI, just unzip that to the same folder as the executable.

 

I did not do a lot of error checking or polishing, because I want to see if this is even useful before putting more time in it.

 

I am not able to run much on my local machine, so I'm relying on your feedback to know what's working and what isn't.

filepick.zip

[Redneckerz]

3 hours ago, JadingTsunami said:

@Doomkid Here is something to try. You need to make sure your DEHACKED.INI loads patches from the current directory (i.e., make sure that your INI file has patchdir = .).

 

Running this will (a) find all the .DEH files in the directory, (b) prompt the user to choose one, then (c) apply it as a patch and copy DOOMHACK.EXE to the dehacked patch name with a .EXE extension.

 

You might need CWSDPMI, just unzip that to the same folder as the executable.

 

I did not do a lot of error checking or polishing, because I want to see if this is even useful before putting more time in it.

 

I am not able to run much on my local machine, so I'm relying on your feedback to know what's working and what isn't.

filepick.zip

I could test this out aswell because of similar interests.  Will do so later.

[JadingTsunami]

5 hours ago, Redneckerz said:

I could test this out aswell because of similar interests.  Will do so later.

 

Thanks. Of course I would not test in your main copy of files in case anything goes awry; use a test folder instead.

 

If this ends up being useful, I'm considering making this more generic, where the program and its arguments could be specified from a config file. This could be a means to extend to DeuSF patching.

 

@Lobo I also realized that DOSBOX has an AUTOEXEC.BAT capability. One option to tie off your program and make it "DOSBOX-compatible" is to write out a DOS batch file with the DeHackEd and copy/move commands in it. The user has to keep that batch file in their AUTOEXEC.BAT so it runs at DOSBOX start-up. Then, any time they use your DeHackEd Patch selector it would take effect the next time they open DOSBOX. Just something to consider.

[Redneckerz]

6 minutes ago, JadingTsunami said:

 

Thanks. Of course I would not test in your main copy of files in case anything goes awry; use a test folder instead.

 

If this ends up being useful, I'm considering making this more generic, where the program and its arguments could be specified from a config file. This could be a means to extend to DeuSF patching.

 

@Lobo I also realized that DOSBOX has an AUTOEXEC.BAT capability. One option to tie off your program and make it "DOSBOX-compatible" is to write out a DOS batch file with the DeHackEd and copy/move commands in it. The user has to keep that batch file in their AUTOEXEC.BAT so it runs at DOSBOX start-up. Then, any time they use your DeHackEd Patch selector it would take effect the next time they open DOSBOX. Just something to consider.

Will do.
Ill be putting this in a test folder with just DeHacked, the ini, Doom exe, a deh patch and Doom wad and see how far it goes.

 

I like the idea of making this more generic  - Particularly in combination with DeusF. Ill get back to this after dinner and do some testing.

[Lobo]

2 hours ago, JadingTsunami said:

 

@Lobo I also realized that DOSBOX has an AUTOEXEC.BAT capability. One option to tie off your program and make it "DOSBOX-compatible" is to write out a DOS batch file with the DeHackEd and copy/move commands in it. The user has to keep that batch file in their AUTOEXEC.BAT so it runs at DOSBOX start-up. Then, any time they use your DeHackEd Patch selector it would take effect the next time they open DOSBOX. Just something to consider.

Handing the baton over to you chief. Your program runs native in MSDOS which is just what is needed here: anything I do would just be wierd workarounds and crude hacks.

 

I'm sorry I didn't get around to trying it yet, as I'd need to setup DosBox to give it a whirl. But @Redneckerz gives good bug reports, just wait and see!

[Redneckerz]

I must be doing something wrong in here. Here is my .ini, bolded is what i changed
 

Spoiler

# This is the DeHackEd v3.0a config file.
# Lines that start with '#' are comments.

# 'editname' is the name of the Doom exe file to hack.  The 'normalname'
# should be the name of your original (unmodified) Doom exe file.  The
# 'normalname' exe will NOT be modified by DeHackEd, but only referred
# to at several times for pristine data.

# For Ultimate DOOM
editname = c:\dhak\doom.exe
normalname = c:\dhak\doombak.exe

# For DOOM ][
# editname = c:\dhak\doom2.exe
# normalname = c:\dhak\doom2bak.exe

# The name and location of your Doom WAD.
wadname = c:\dhak\doom.wad

# For DOOM ][
# wadname = c:\dhak\doom2.wad

# The path to your Doom directory.  This is where Doom will be run
# from when you 'r'un Doom inside DeHackEd.
# pathname = c:\dhak

pathname = c:\dhak

# Command line arguments when Doom is run from within DeHackEd.
params = -skill 4 -warp 8

# The directory to look for patch files in.
patchdir = c:\dhak\

# Determines whether DeHackEd asks if you would like to reload the original
# exe data every time you load a patch file.  It is true by default, but
# just remove the pound sign from the next line to turn it off.
askatload = false

# Whether or not DeHackEd shows the cool logo on startup.  True by default,
# just remove the pound sign to skip the logo.
#loadlogo = false

# Options for soundblaster cards.  sbaddress is the address of your card,
# sbirq is the IRQ for the card, and sbdma is the DMA channel.  Use a
# DMA of -1 for auto-detect.
#sbaddress = 220
#sbirq = 5
#sbdma = -1

# Added by John K. for changing THING names
namefile = thing.nam

# The following are all optional, and are included only in the hopes that
# they might be used to fend off future Doom versions, if any more pop
# up.

# Doom version #
#        0 for Doom 1 1.666
#        1 for Doom 2 1.666
#        2 for Doom 2 1.7, 1.7a
#        3 for Doom x 1.9
#        4 for Ultimate Doom 1.9
# version = 2

version = 4

# The size of the user-defined Doom exe file.
#size = 715493

# These are the offsets for the various data sections...
#thingoff   = 677472
#soundoff   = 645924
#frameoff   = 650396
#spriteoff  = 649844
#ammooff    = 638872
#weaponoff  = 638904
#textoff    = 691064
#cheatoff   = 642244
#textlength = 24072

Astro.deh is in the same directory, not a sub. Ignore portal.deh, i am trying Astro.deh.

This is what i get as the console spits out:
(It shows a menu of all the .deh's it found in the same directory, which is Astro.deh and Portal. deh. This worked well. I picked 1, which is Astro.deh.


The old DoomHack.exe is literally a copy of the Doom2.exe in the same directory that i made a minute prior, so i am not sure why it now says its not the same. I also tested this with a completely new DoomHack and the two errors (Thing cannot be opened, Astro.deh does not exist) remain.

 

Astro.Deh does exist obviously, and its in the path where filepick says there isn't any.

I doubt THING name (Which is from John K added in Dehacked 3.1) is the issue. I picked Astrostein 1, by the way.

I should note that Doomkid might be a better tester for this since he dabbles in Dehacked all the time and i am just a casual user to replicate old skool installation stuff.
 

10 minutes ago, Lobo said:

Handing the baton over to you chief. Your program runs native in MSDOS which is just what is needed here: anything I do would just be wierd workarounds and crude hacks.

 

I'm sorry I didn't get around to trying it yet, as I'd need to setup DosBox to give it a whirl. But @Redneckerz gives good bug reports, just wait and see!

Heh, well i reckon the above report is more a failure on my end than Jading's.
 

[JadingTsunami]

4 minutes ago, Redneckerz said:

Astro.Deh does exist obviously, and its in the path where filepick says there isn't any.

 

Thanks for testing. That error is actually coming from DeHackEd. I think it has a bug for absolute paths, I was only able to get it to work if I added patchdir = . like I mentioned.

 

It's a bit awkward, but if you still see the failure with patchdir = . I can take a further look inside DeHackEd to try and see why it's failing.

 

[Redneckerz]

6 minutes ago, JadingTsunami said:

 

Thanks for testing. That error is actually coming from DeHackEd. I think it has a bug for absolute paths, I was only able to get it to work if I added patchdir = . like I mentioned.

 

It's a bit awkward, but if you still see the failure with patchdir = . I can take a further look inside DeHackEd to try and see why it's failing.

 

Ooooh, so patchdir essentially has to be blank, but with a dot (.)  Lemme test this out real quick.

EDIT: Yes, that seems to work. It correctly sees Astro.deh and merges it with DoomHack and does not  throw the ''Astro.deh does not exist'' error. The Thing error remains, however.

The resultant exe name is still DoomHack but i reckon that's on purpose?

[JadingTsunami]

Just now, Redneckerz said:

The resultant exe name is still DoomHack but i reckon that's on purpose?

 

There should be 2 .EXE files after the program completes: DOOMHACK.EXE and a duplicate version named ASTRO.EXE which has the merged changes in it. (Of course it is just the patch name with .EXE at the end, so it won't always be ASTRO.EXE).

 

I didn't delete DOOMHACK.EXE to avoid messing with the user's files. But this can be considered as an improvement if desired.

[Redneckerz]

2 minutes ago, JadingTsunami said:

 

There should be 2 .EXE files after the program completes: DOOMHACK.EXE and a duplicate version named ASTRO.EXE which has the merged changes in it. (Of course it is just the patch name with .EXE at the end, so it won't always be ASTRO.EXE).

 

I didn't delete DOOMHACK.EXE to avoid messing with the user's files. But this can be considered as an improvement if desired.

.... I am such an idiot. I didn't scroll up the entire folder XD. Yes, its there. Perhaps the program can print a reference to this? Because it now simply states DOOMHACK.exe and that 1 file is copied.

 

Ofcourse, one can just look in the folder and see the difference.

So as i see it, Filepick is able to correctly merge a .deh patch with DoomHack, keeping DoomHack, and making the merged copy be the duplicate version with merged changes in it.

 

I think you should retain Doomhack, i think its a good visual indicator to denote which file gets used for the merge (DoomHack).

PS: Portal.deh spits out a ton of errors but its likely because its not the main deh. It got correctly read however. Doomhack just gets replaced by a new copy internally all the time.

[JadingTsunami]

2 minutes ago, Redneckerz said:

I think you should retain Doomhack, i think its a good visual indicator to denote which file gets used for the merge (DoomHack).

 

Sure, I can put something in there to print out the EXE that was generated. I think it's a good idea.

 

Conceptually, is the program as it works today giving the desired behavior? It was written to match Doomkid's original criteria of selecting a single DEH patch and merging it in.

 

I will see about putting together a release as a standalone tool if it's useful. I don't run Vanilla (I always use a sourceport) so I'm guided by the input in this thread and not my own experience here.

[Redneckerz]

Double edit: Launching Astro.exe takes up some time, but it kicks in an error:
W_GetNumForName: Not found!

 

I remember Astrostein did this originally aswell, but i think the basic execution works. Perhaps @Doomkid can do some quicker iterations with various deh's.

Perhaps also an additional parameter for DeusF appending?

Edited June 3, 2020 by Redneckerz

[Lobo]

40 minutes ago, Redneckerz said:

Double edit: Launching Astro.exe takes up some time, but it kicks in an error:
W_GetNumForName: Not found!

 

@Doomkid

Pretty sure that error is because it needs custom graphics, so you need to DeusF it.

[Redneckerz]

6 minutes ago, Lobo said:

Pretty sure that error is because it needs custom graphics, so you need to DeusF it.

Well then! We need a DeusF parameter :P

I like the elegance of the program so far now though. But without taking over the topic, let DoomKid shed his light on this aswell.