MTrop's Doom Tools Update (DMXConv, DImgConv, DECOHack, DoomMake)

[MTrop]

HEY, EVERYBODY!

Head over to the Official DoomTools Thread in Doom Editing if you want up-to-date release notes and notifications.

ALL new updates will be there, so FOLLOW that thread if you want to be notified about updates!

 

There's an INSTALLER now! No more PATH putzing! It will even embed a (smaller) JRE if you don't have Java!

 

 

STILL IMPORTANT: You'll need Java 8 or higher installed to run these!

 

NOTE: If you already have DoomTools installed (and on your PATH), you can just type doomtools --update at the command line and it will update in-place!

 

Main Website

Github Repository

Latest Releases (Windows CMD and BASH)

 

The First Thread

 

 

Installation (Same as Last Time)

 

Unzip/untar the release to its own directory, and then add that directory to the list of directories in your PATH environment variable.

 

 

You again? What's this about?

 

Hey, everybody, I'm MTrop. You may remember me from enjoyable WADs such as this 22-year-old pile of junk that people somehow still like and this short romp that's pretty okay I guess. But did you know I'm a programmer?

 

...you did? Well that's good, because I've got more programs for ya!

 

As with the previous thread, this is a set of utilities written in Java and built on this fantastic library that I also wrote (DW thread here). Since I went over a bunch of the utilities in the last thread, I'm only gonna go over the new ones here, and let me tell you: you're probably gonna want to use them.

 

 

DMXConv
 

SLADE3 does an okay job at converting sounds from WAV to Doom's DMX format, but you are like me and chuck your sounds in a project tree and want to convert all of them at once for importing later, this'll do it! Works best if you have FFmpeg on your PATH or somewhere on your computer - then you can convert practically EVERY SOUND FORMAT THAT EVER EXISTED to DMX! If not, it'll still use the existing Java SPI framework for conversion, if you want.

dmxconv sounds/*.wav -o ./converted/sounds

Typing `--help` will give you more options and explanations. Keep in mind that this is a one-way utility - it does not convert from DMX back to other formats.

 

 

DECOHack

 

I think you're really gonna love this one. Are you ready? Because I don't think ya are!

 

Have you ever wanted to create some kind of insane mod for Vanilla Doom (and other classic Dooms) but wished that there was a better programmatic way to write weapon, ammo, sound, string, par time, and thing definitions with a DECORATE-like language? Introducing DECOHack, the thing that does exactly that!

 

DECOHack takes a file (or series of files) written in a DECORATE-ish language and turns it into a DEH/BEX file that can be loaded into your favorite source port, or patched into your favorite executable via DeHackEd! Supports all patch schemes up to Extended (aka DEHEXTRA).

decohack code.dh --output dehacked.deh

Hate backpacks? Turn them into BFGs!

#include "classpath:decohack/doom19.dh"
#include "classpath:decohack/constants/friendly_things.dh"

// copy BFG pickup into backpack
thing MTF_BACKPACK : thing MTF_BFG
{
    //keep ednum, though
    ednum 8
}

Make an Imp with a worse attack!

#include "classpath:decohack/doom19.dh"
#include "classpath:decohack/constants/friendly_things.dh"

thing MTF_IMP free states
thing MTF_IMP "Worse Imp"
{
    health 200
    speed 12
    
    clear states
    States
    {
        Spawn:
            TROO AB 10 A_Look
            Loop
        See:
            TROO AABBCCDD 3 A_Chase
            Loop
        Melee:
        Missile:
            TROO EF 8 A_FaceTarget
            TROO G 6 A_BruisAttack
            Goto See
        Pain:
            TROO H 2
            TROO H 2 A_Pain
            Goto See
        Death:
            TROO I 8
            TROO J 8 A_Scream
            TROO K 6
            TROO L 6 A_Fall
            TROO M -1
            Stop
        XDeath:
            TROO N 5
            TROO O 5 A_XScream
            TROO P 5
            TROO Q 5 A_Fall
            TROO RST 5
            TROO U -1
            Stop
        Raise:
            TROO ML 8
            TROO KJI 6
            Goto See
    }
}

The sky's the limit (within reason, as it is still limited to Doom engine quirks and limitations)!

 

If you're worried about how many states you have left (in total or action-pointer allocated), you can run DECOHack with the `--budget` switch. Full help available via the `--help-full` switch. You can do a lot! It's all documented, even the worst of Doom's hardcodings!

 

 

DoomMake

You've stuck with me long enough - I think you're finally ready for the big guns.

 

Have you ever wanted to start a new project, but didn't want to organize everything, and still have it produce WADs that you can maintain in a code versioning system like Git, compile together in an automated fashion, or keep providing builds via an ultra-nerdy thing like Continuous Integration?

 

Well, in case that's you, you're in luck!

 

DoomMake is here to help you build that giant project with all sorts of bells and whistles with a single command, and produce something compiled together and playable (and with some setups, a reduced texture set)! It leverages WadScript and turns it into a do-anything-you-want build tool that isn't tied to one operating system or environment. You can even call all the rest of the tools in the DoomTools toolset!

 

You can start a new project with maps and new textures sourced from WADs:

doommake newproj --new-project maps-texturewads

Or even a giant vanilla mod from scratch with all sorts of things, and make it Git-repository-ready:

doommake newproj --new-project maps-assets-textures decohack run git

And then when you want to build your project in it's current state, you just switch to its project directory, and...

doommake

 

It's that easy! Want to feel its power? Try cloning and building this project for starters: https://github.com/MTrop/doommake-example

 

 

As always, chuck some issues my way if stuff doesn't work, or if you've got some feature requests. Follow the GitHub repository to be notified of updates and releases.

 

Happy Dooming, y'all! Make some cool stuff!

Edited April 16, 2022 by MTrop
Added more updates

[skillsaw]

I've been working with DoomTools for a week or so and it's been pretty great!

 

DecoHack seems to me like the way everyone should be doing DeHackEd from now on - it's more human-understandable and faster to represent thing and state definitions in a DECORATE-like syntax than in DeHacked files or by manually tracing through WhackEd state charts. I can't imagine doing DeHackEd work any other way after trying it. The only real shortcoming I've run into is having issues related to hardcoded Doom behavior, but the documentation was extremely helpful in figuring that out -- and, realistically, I would have run into the same issues with any other tool.

 

I've also been using WadMerge to set up a single command build. I have all project resource files organized in a .zips-as-a-wad style folder structure (that I push up to github) and use a single WadMerge script to build the entire folder into a .wad file (using a single command in a terminal window). DoomMake seems even more powerful, and I plan to look into using that as well. I imagine as the project grows being able to build just the maps portion, just the textures portion, etc, could be useful.

 

For anyone who is a bit skeptical I highly recommend giving it a shot, especially so if you have experience working with git and would like to take advantage of using it for wad development. For those who don't work with it, there are a bunch of reasons why it's really nice....

• Instead of constantly backing up copies of a monolithic binary file (say, your 100mb magnum opus megawad) to your dropbox folder, you only need to push up the assets you've actually changed since you last pushed your work.
• If you are working with a group of contributors, you can each independently push changes up (adding more textures, adding music, updating dehacked, edf, or decorate, etc) without the need to pass around the file or to have one single person take ownership of updating the resource. This has been great for me as others have made contributions to Doom projects of mine and I basically only need to click a button to pull those changes into my local copy. Note that git doesn't handle merges on binary files (for obvious reasons) so you can still run into conflicts that can't really be resolved if you both work on the same map or the same image file, etc -- so that does still require coordination, but generally people are working on different maps and different assets anway.
• git will keep a versioned history of every single file you work with, so you can revert to an old copy if necessary. In fact, with DoomMake set up, it is trivial to build the project as it existed at any point in time. [nerding out] Having a history of your progress is kind of cool in its own right, but it's even cooler when it can be interactive!
• probably more stuff...

Thanks MTrop!

[Doomkid]

These programs (and their descriptions) are great, they’ll surely be a huge help to modders. I’m especially happy to see DECOhack, I really think it’s going to make the .DEH creation process easier for a lot of users who get overwhelmed by making DEHs the old fashioned way. Thanks a ton!

[Xaser]

I'm also using these for a project, and can attest that the workflow is friggin' awesome. I'll post more details about my own setup when that project gets announced, but tl;dr this will save you a ton of brain cells if you're managing a wad that's any larger than a handful of maps. ;)

[MTrop]

Hey, everybody. Some big updates.

 

I've added a bulk image conversion utility called DImgConv for creating PLAYPAL, COLORMAP, TINTTAB, TRANMAP, and Graphics and Flats from common image formats like GIF, JPEG, or PNG (via Java ImageIO), as well as adding a bunch of built-in functions for WadScript/DoomMAke for generating and manipulating image data. If you're clever enough, you can throw together a batching system that composites image data, converts them to Doom image data for a target palette, and merges all of them into a WAD!

 

Also, DECOHack has been updated to allow manipulation of the miscellaneous offset data on each state and better handling of function pointer parameter values on MBF/SMMU action pointers. Now, you can take advantage of previously undiscovered Doom EXE knowledge that's sweeping the community!

 

Latest release is here.

[MTrop]

Bumping to say that the latest update contains a version of DECOHack that supports MBF21! As well as lots of other fixes!

 

https://github.com/MTrop/DoomTools/releases/tag/2021.06.15-RELEASE

 

[MTrop]

Watch out for the BUMP!

 

Apologies - this is probably the last time I'll do this, but the latest release of DoomTools removes the final limitation in DECOHack where you couldn't pre-declare labels before they were used in actor "States" blocks. Now you can!

 

State indices via labels are now assessed/reassigned after the "States" block is fully read on Things and Weapons, which means any labels used in that block will use the latest position defined within that block (the state name plus ":"). Anything not declared nor re-declared during that block will use the label's current state index assignment (in case of copied Things/Weapons and what-have-you). If a label is never declared nor defined on that actor after the States block is parsed, DECOHack will complain at you.

 

NOTE: Be on the lookout for bugs. I tested this pretty well and didn't encounter any problems, but just in case you see the value "1234567890" anywhere in your compiled patch, that means the label back-filler didn't work for some reason. Whoops!

 

Latest Release as of right now: https://github.com/MTrop/DoomTools/releases/tag/2021.09.08-RELEASE.

 

Check the main website periodically for new releases (and some helpful docs, maybe some guides in the future): https://mtrop.github.io/DoomTools/

Edited September 8, 2021 by MTrop

[Nikku4211]

I am currently trying to integrate the .deh file I was already making in WhackEd into my DoomMake project. How do I do this?

 

The only method I know is to put the .deh file in the _global subfolder of the asset folder, but that means I have to name it 'dehacked.deh', and the extra files that WhackEd generates from it will also share the 'dehacked' filename.

[MTrop]

Huh. Weirdly enough, that's a use case that I haven't considered! Usually the patch in DoomMake projects would come in the form of a DECOHack-compiled patch. Not to worry, though - you might need to do some small tweaking to your project.

 

Since it sounds like you put together an asset-driven project at the very least, you should have a file in the project's "scripts" directory called "merge-assets.txt". Open that file and add a line to it after the "mergedir out $1/assets/_global nomarkers" line:

mergefile  out $1/assets/patch/dehacked.deh

Then, create a directory called "patch" under the project's "src/assets" directory. Add your DeHackEd stuff (including the patch file) to the "patch" directory.

 

After you do this, only the dehacked.deh file will be merged in, and you can keep WhackEd's metadata files in there too so that you can keep editing with WhackEd!

Edited September 10, 2021 by MTrop

[Nikku4211]

1 hour ago, MTrop said:

After you do this, only the dehacked.deh file will be merged in, and you can keep WhackEd's metadata files in there too so that you can keep editing with WhackEd!

Awesome. Is it also possible to have the .deh file be renamed to DEHACKED when it gets imported to a WAD if it's not already called 'dehacked.deh'?

[MTrop]

6 hours ago, Nikku4211 said:

Awesome. Is it also possible to have the .deh file be renamed to DEHACKED when it gets imported to a WAD if it's not already called 'dehacked.deh'?

 

Yup. There's an optional parameter in the MERGEFILE WadMerge command that specifies an entry name for the merged file:

MERGEFILE [symbol] [path] [opt:entryname]
    Reads file from [path] into [symbol].
    [symbol]:    The symbol to add to.
    [path]:      The file to add.
    [entryname]: (Optional) If specified, this is the entry name to use
                 to import as.
    ................................
    Returns: OK if merge successful,
             BAD_SYMBOL if the destination symbol is invalid,
             BAD_FILE if the provided file does not exist or is a directory.

So that MERGEFILE line could be written as:

mergefile out $1/assets/patch/myreallycoolpatch.deh dehacked

...and it will be imported as "DEHACKED" (all entry names are automatically converted to upper-case).

Edited September 10, 2021 by MTrop

[Nikku4211]

How do I get the .deh to be automatically distributed within the .zip the WAD is placed in?

 

I know most modern source ports have some sort of option to load DeHackEd from a lump, but I prefer to distribute the .deh file with the WAD in addition to having a DeHackEd lump so that it's easier to remember that you have to load the DeHackEd patch.

 

Also, is it possible to automatically set a graphic's offsets? I'm trying to centre my custom M_DOOM image, which has a resolution of 210x66(Don't worry, it works just fine in Chocolate).

[MTrop]

16 hours ago, Nikku4211 said:

How do I get the .deh to be automatically distributed within the .zip the WAD is placed in?

If you are using a project created in a recent version of DoomMake, there should be a line in your project's "doommake.script" file that calls ZIPFILES() to package up your distributable ZIP. It takes a list of files, so you'll have to add the patch file to the list. Hopefully the scripting language is understandable enough!

 

A quick guide is here: https://mtrop.github.io/DoomTools/rookscript-guide.html

A reference to all of the DoomMake built-in functions are here: https://mtrop.github.io/DoomTools/doommake-functions.html (look in the DoomMake-specific functions section for ZIPFILES).

 

16 hours ago, Nikku4211 said:

Also, is it possible to automatically set a graphic's offsets? I'm trying to centre my custom M_DOOM image, which has a resolution of 210x66(Don't worry, it works just fine in Chocolate).

Automatically? I'm not sure. If it works in Chocolate but not in other ports, it may be a port-specific problem (with port-specific solutions) if changing the offsets in the graphic itself does not yield correct results. You can change offsets in SLADE in either Doom-format graphics or PNGs and DoomMake will either convert or import the graphics, preserving offsets as-is, or you can provide a DImgConv metadata file with the convertible graphics to override those offsets (see DImgConv's `--help` for details).

Edited September 13, 2021 by MTrop

[Nikku4211]

5 hours ago, MTrop said:

If you are using a project created in a recent version of DoomMake, there should be a line in your project's "doommake.script" file that calls ZIPFILES() to package up your distributable ZIP. It takes a list of files, so you'll have to add the patch file to the list. Hopefully the scripting language is understandable enough!

 

A quick guide is here: https://mtrop.github.io/DoomTools/rookscript-guide.html

A reference to all of the DoomMake built-in functions are here: https://mtrop.github.io/DoomTools/doommake-functions.html (look in the DoomMake-specific functions section for ZIPFILES).

 

Automatically? I'm not sure. If it works in Chocolate but not in other ports, it may be a port-specific problem (with port-specific solutions) if changing the offsets in the graphic itself does not yield correct results. You can change offsets in SLADE in either Doom-format graphics or PNGs and DoomMake will either convert or import the graphics, preserving offsets as-is, or you can provide a DImgConv metadata file with the convertible graphics to override those offsets (see DImgConv's `--help` for details).

Alright thanks I got it working.

[boris]

How can I just modify some properties of a thing? Say I want to make a stronger imp, I have this code:

 

#include <doom19>
#include <friendly>


thing MTF_IMP : thing MTF_IMP "Strong Imp"
{
    health 120
    speed 12
}

 

But the resulting DeHackEd is the following, with all frames set to 0:

 

Patch File for DeHackEd v3.0
# Created with DECOHack v0.17.0 by Matt Tropiano
# Note: Use the pound sign ('#') to start comment lines.

Doom version = 19
Patch format = 6


Thing 12 (Strong Imp)
Hit points = 120
Speed = 12
Initial frame = 0
First moving frame = 0
Injury frame = 0
Close attack frame = 0
Far attack frame = 0
Death frame = 0
Exploding frame = 0
Respawn frame = 0

I would expect the frames to not show up at all, since they are the same as the original.

 

[edit] Turns out the inheritance has to be left out, i.e.

 

thing MTF_IMP "Strong Imp"
{
    health 120
    speed 12
}

just modifies the thing with the given values.

Edited September 18, 2021 by boris

[boris]

But I have another question: how do I add new sounds (as introduced by DEHEXTRA)? I just can't figure it out, and the documentation isn't really helpful in that regard.

 

[edit]

 

So I've been told to use the FRExxx names for the sounds.

Edited September 18, 2021 by boris

[Wavy]

Not sure if this is a silly question, but I'm curious if there is there a way to covert a DeHackEd into a DECOHack file (or even a group of them).

 

I'm making something in MBF and I've done a pretty decent amount of editing in WhackEd but I want to port it to DECOHack as I feel it'd be easier to edit. Would that be possible or would I need to reimplement my DeHackEd from scratch in DECOHack?

Edited September 18, 2021 by Wavy

[MTrop]

There is currently no way to convert a DeHackEd patch to a DECOHack source file.

 

There is critical information lost in a DeHackEd file that would enable me to create a human-readable patch of some kind that makes sense, such as how states link to Things or Weapons. It can be inferred through some references, but in order to be correct, I would need to try to group together states in a meaningful way via the "Next State" indices (which is not always helpful), and then create stubbing for each Thing or Weapon that points to those states.

 

All of that would require a lot of work and assumptions that I can never be sure of 100%, and even then, you'd still need to break up the results into something meaningful to yourself. Maybe one day when everything else is done I'll look into seeing if it is feasible in some way, but for the moment (and the future), it can not and will not be done.

 

I'm sure you'll find it's still easier to port everything to DECOHack by hand. A lot of time spent modding is in design, rather than implementation, anyway.

[MTrop]

On 9/17/2021 at 6:38 PM, boris said:

I would expect the frames to not show up at all, since they are the same as the original.

I would also expect this as well. This is a strange bug, especially since it did a copy from itself to itself.

 

I'll have to take a look.

 

EDIT: Added an issue: https://github.com/MTrop/DoomTools/issues/52

Edited September 24, 2021 by MTrop
Add Github issue.

[Wavy]

12 hours ago, MTrop said:

There is currently no way to convert a DeHackEd patch to a DECOHack source file.

 

There is critical information lost in a DeHackEd file that would enable me to create a human-readable patch of some kind that makes sense, such as how states link to Things or Weapons. It can be inferred through some references, but in order to be correct, I would need to try to group together states in a meaningful way via the "Next State" indices (which is not always helpful), and then create stubbing for each Thing or Weapon that points to those states.

 

All of that would require a lot of work and assumptions that I can never be sure of 100%, and even then, you'd still need to break up the results into something meaningful to yourself. Maybe one day when everything else is done I'll look into seeing if it is feasible in some way, but for the moment (and the future), it can not and will not be done.

 

I'm sure you'll find it's still easier to port everything to DECOHack by hand. A lot of time spent modding is in design, rather than implementation, anyway.

Ok. This makes sense. Thanks for the reply!

[Giomancer]

So I started playing around with DoomTools about a fortnight ago, and it's been interesting. I've put most of my efforts into learning DoomMake and ripping apart its various scripts and customizing things to my liking (f/e, "doommake clean" cleans both the 'build' and 'dist' directories, while "doommake release" builds a distcopy). I've started working on "libraries" to extend what I can do within the framework of DoomMake.. I'll post if/when I have something working.

[boris]

So I installed 2021-09-21-B, which includes DECOHack 0.18.0, which should support the editor keys. But they don't seem to work. For example this simple DECOHack

 

#include <mbf21>
#include <friendly>

thing MTF_IMP "Strong Imp"
{
    //$Category Monsters/Strong
    //$EditorSprite TROOG1

    health 120
    speed 12
}

 

turns into this DeHackEd file:

 

Patch File for DeHackEd v3.0
# Created with DECOHack v0.18.0 by Matt Tropiano
# Note: Use the pound sign ('#') to start comment lines.

Doom version = 21
Patch format = 6


Thing 12 (Strong Imp)
Hit points = 120
Speed = 12

 

As you can see the special metadata comments are missing.

[MTrop]

@boris That's weird - it works when I try it in my mod, but not when it's a single Thing. I'll take a closer look.

 

EDIT: Oh, Lordy - I figured it out. The comment key context is getting cleared at the wrong time due to how I'm starting the thing body parse.

 

If you put those lines after one of those property lines, it'll work. Should be an easy fix.

Edited September 26, 2021 by MTrop
Figured it out

[MTrop]

I guess since this thread's a tad more active, I can post an update.

 

Latest version of DoomTools is up. Fixes the following:

DecoHack
--------

Changed for 0.18.1

* `Fixed` Editor keys were not being saved if a Thing body didn't have parse-able content right after body start.
* `Changed` Copying a definition from the exact same one will not perform a copy, as there is nothing to do.

If you have DoomTools (version 2021-09-21 and higher) installed and on your PATH, typing doomtools --update will grab it.

[MTrop]

On 9/25/2021 at 4:54 PM, Giomancer said:

So I started playing around with DoomTools about a fortnight ago, and it's been interesting. I've put most of my efforts into learning DoomMake and ripping apart its various scripts and customizing things to my liking (f/e, "doommake clean" cleans both the 'build' and 'dist' directories, while "doommake release" builds a distcopy). I've started working on "libraries" to extend what I can do within the framework of DoomMake.. I'll post if/when I have something working.

Just noticed this post.

 

By all means, let me know what you put together! I may be able to incorporate some of it into DoomMake's default templates if they're universally useful.

 

(I've really been meaning to put the command to clean the dist folder in the clean target - dunno why I haven't done that sooner)

[Giomancer]

@MTrop

edf.7z

The 7z file contains:

• doommake.properties

• merge-edfs.script

• doommake-libee.script

• doommake.script

 

Since my current project is for Eternity, I decided to start with adding EDF handling. The most difficult part was trying to decide how to deal with reading a single file then the whole directory. The way the merge script works currently requires a cleanup step in post, but I keep wondering if there isn't a more elegant way to do it.

 

EDIT: Finished, cleaned up, and updated!

Edited October 4, 2021 by Giomancer
Released non-alpha

[boris]

As of version R3833 UDB has options to run pre and post commands when reloading resources, and pre commands when testing a map. This was specifically designed with Doommake in mind (but of course it works with other programs, too). So when you use Doommake and make changes to your folder structure you can just tell UDB to load the resources, and have it run Doommake before doing so. This is also especially useful for testing the map in more classic oriented ports, since with some trickery you can get it to build the texture WAD from multiple texture WADs, since you can't load multiple texture WADs in those ports.

 

 

[Hitboi]

Incredible tools, I think that Wtexport saves a lot of time when creating wads using custom textures from a big texture pack.

[MTrop]

12 hours ago, Hitboi said:

Incredible tools, I think that Wtexport saves a lot of time when creating wads using custom textures from a big texture pack.

That was the goal, my friend!

 

I think I gotta start making a tutorial page for DoomMake so that project creation can really be streamlined. After DSDHacked support in DECOHack, though. Almost done!

[MTrop]

What, up everybody: A new version of DoomTools has been released. DECOHack now supports DSDHacked!

There's a bunch of updates:

-DECOHack-
Changed for 0.19.0

Fixed: A_JumpIfHealthBelow did not accept negative values for the health reference value.
Fixed: Actor label values were not backfilled properly if the action that used them needed applying to many frames on one line.
Added: Auto-things and free-able things (all patches).
Added: Aliases for things and weapons via "alias thing" and "alias weapon" statements.
Added: DSDHACKED patch support.

-DoomMake-
Changed for 0.9.0

Added: "dsdhacked" as a valid DECOHack patch type.

When making a DSDHacked patch, new sound references and new sprite names will be automatically added to the appropriate places in the patch, without any new declarations required on the author's part!

 

You're also gonna want to familiarize yourself with some new stuff added to DECOHack, since it will make some things easier:

 

 

Thing Aliases
 

You can specify identifier aliases for thing slots by using the following:

alias thing DoomImp 12

...so the next time you refer to it, you can write:

thing DoomImp
{
    // ... code
}

The alias works in every place you can use a thing reference or slot:

thing DoomImp free states

A_Jump(thing DoomImp death)

thing 200 : thing DoomImp "Imp Copy"
{
    // ... thing body
}

Thing alias identifiers are case-insensitive.

 

Weapon Aliases

 

You can specify identifier aliases for weapon slots by using the following:

alias weapon Shotgun 2

...so the next time you refer to it, you can write:

weapon Shotgun
{
    // ... code
}

The alias works in every place you can use a weapon reference:

weapon Shotgun free states

weapon 4 : weapon Shotgun "Shotgun Copy"
{
    // ... weapon body
}

Weapon alias identifiers are case-insensitive.

 

 

Auto-Things

 

Things can be freed and filled automatically like states. To free a single thing slot:

thing free <INTEGER>

To free an explicit range (inclusive):

thing free <INTEGER> to <INTEGER>

Examples:

thing free 151
thing free 151 to 250

In order to fill the next free Thing, you need to define Things using the "auto" keyword:

auto thing <IDENTIFIER> [ : thing ( <INTEGER> | <IDENTIFIER> ) ] [ <STRING> ]
{
    // ... same thing body like always ...
}

Note that you'll need to use an unused identifier (or alias) to represent the new Thing when you need to refer to its index later. The identifiers are case-insensitive.

 

Examples:

auto thing NewImp "New Imp"
{
    // ... code ...
}

auto thing BetterImp : thing NewImp "Better Imp"
{
    // ... code ...
}

...then in action pointer functions (and other places that use thing references), you can refer to them later since they are now aliased:

A_SpawnThing(thing NewImp)
A_RandomJump(thing NewImp death, 128)    // Thing state label

Any place that would ordinarily use a Thing index can use an auto-thing identifier in place of the index.

 

Things that are edited directly or auto-filled this way are not "free" anymore, similar to how "free" states work.

 

You can modify auto-filled Things later (remember, definitions cascade!) by writing a normal Thing definition body:
 

thing BetterImp
{
    // ... code ...
}

 

Additionally, when you include the base patches now (via #include <doom19> or other similar directives), all things and weapons will use (G)ZDoom's class names as aliases for the original things and weapons. Be careful when using these with patch types that use original thing/weapon slots - hardcodings still apply!

 

Also, when including <extended>, <mbf21>, or <dsdhacked>, the appropriate state and thing ranges will already be freed, so you can immediately start adding new things without worrying about overwriting existing slots with auto.

 

More information in the main documentation.

 

Alright, everybody - let's see some DSDHacked patches! Get modding!

Edited October 27, 2021 by MTrop