So, every so often i find a lose file inside certain wads. Some are dehacked files like deh and bex, and i understand i have to use the -deh and -bex commands respectively. I also read somewhere that -file works too but i'm not sure.
Then, i found some other files i'm not sure if it's the same, like acs and hhe. Do i run those and anything else i find with -file?
Question about lose files in wads
Re: Question about lose files in wads
Sometimes, people package dehacked files loose inside the zip and inside the WAD. Source ports that can read the embedded file from the WAD do not need you to add the loose one if the mod also has an embedded file (present as a lump called DEHACKED inside the WAD/PK3). Unfortunately, it isn't always clear whether the WAD author has done this or not and, in such cases, the only way to be sure is to look inside the WAD yourself to see if it has a DEHACKED lump. Newer projects are likely to have the embedded lump; older projects not so much.
Originally, DEH files were a way of distributing hacks to the doom.exe that people had to apply themselves using the DeHacked program. Doom itself could not read them (and distributing hacked exe files was not allowed). So old projects would include DEH files to allow people to hack their own ones. Moving on a little, eventually the ability to read DEH files was added to source ports, but not all immediately adopted the ability to read them as a DEHACKED lump inside a WAD. So authors would include both - but, again, if the WAD has a DEHACKED lump, there is no need to add the separate one.
HHE is like DeHacked, but for Heretic. It was never as fully featured as DeHacked, but it does most of the DEH-like functions well enough. Most ports do not support HHE files at all. Pretty sure GZDoom does not support it - so no point in loading one.
[For info, there was also a Hexen version called HEX that was less featured than HHE and I there was also a Strife one too (SeHackEd). Again, pretty sure none of those are supported by GZDoom.]
ACS files loose in the zip are usually just there as a way of distributing the source code for any ACS that may be in the project. ACS files need to be compiled before they can be run. This should have already been done and the compiled code will be present as the BEHAVIOR lump in the map data (or as a library inside a project that has some scripts that can be run independent of which map is being played). Most times, people include the source ACS as a scripts lump inside the WAD or as uncompiled source inside the WAD/PK3 (as well as the compiled version, of course), but that wasn't always as easy to do as it is now. So sometimes it would just be loose in the zip. A loose ACS file is just there for record purposes. It cannot be run uncompiled and you don't need to do anything with it.
As a general rule, a well constructed modern project should run using the project file with no additional files needed unless there are specific additional options/tweaks/mutators for the project. Other than that, DEH files are the only loose files you are likely to need to run separately, and only when a DEHACKED lump is not already present in the WAD/PK3 (as explained above).
The only other common file that you might see is a LMP file. If it is there, it will probably be a demo file that allows Doom to play back a recording of a game. However, unless the demo came from the version of GZDoom that you are running, it probably won't work. Such demo files are more common for source ports where demo compatibility (often to show speed-running) is a focus of the port.
So, the TL:DR version of the above is that you almost never need to load a separate file to run a project in GZDoom; the main exception being a DEH file for a project that does not also include an embedded DEHACKED lump.
Originally, DEH files were a way of distributing hacks to the doom.exe that people had to apply themselves using the DeHacked program. Doom itself could not read them (and distributing hacked exe files was not allowed). So old projects would include DEH files to allow people to hack their own ones. Moving on a little, eventually the ability to read DEH files was added to source ports, but not all immediately adopted the ability to read them as a DEHACKED lump inside a WAD. So authors would include both - but, again, if the WAD has a DEHACKED lump, there is no need to add the separate one.
HHE is like DeHacked, but for Heretic. It was never as fully featured as DeHacked, but it does most of the DEH-like functions well enough. Most ports do not support HHE files at all. Pretty sure GZDoom does not support it - so no point in loading one.
[For info, there was also a Hexen version called HEX that was less featured than HHE and I there was also a Strife one too (SeHackEd). Again, pretty sure none of those are supported by GZDoom.]
ACS files loose in the zip are usually just there as a way of distributing the source code for any ACS that may be in the project. ACS files need to be compiled before they can be run. This should have already been done and the compiled code will be present as the BEHAVIOR lump in the map data (or as a library inside a project that has some scripts that can be run independent of which map is being played). Most times, people include the source ACS as a scripts lump inside the WAD or as uncompiled source inside the WAD/PK3 (as well as the compiled version, of course), but that wasn't always as easy to do as it is now. So sometimes it would just be loose in the zip. A loose ACS file is just there for record purposes. It cannot be run uncompiled and you don't need to do anything with it.
As a general rule, a well constructed modern project should run using the project file with no additional files needed unless there are specific additional options/tweaks/mutators for the project. Other than that, DEH files are the only loose files you are likely to need to run separately, and only when a DEHACKED lump is not already present in the WAD/PK3 (as explained above).
The only other common file that you might see is a LMP file. If it is there, it will probably be a demo file that allows Doom to play back a recording of a game. However, unless the demo came from the version of GZDoom that you are running, it probably won't work. Such demo files are more common for source ports where demo compatibility (often to show speed-running) is a focus of the port.
So, the TL:DR version of the above is that you almost never need to load a separate file to run a project in GZDoom; the main exception being a DEH file for a project that does not also include an embedded DEHACKED lump.
-
Opus132
- Posts: 11
- Joined: Mon Aug 08, 2022 3:05 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: Question about lose files in wads
Nice, that saves me a lot of trouble then.