Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
MTrop

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

Recommended Posts

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!

Share this post


Link to post

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. ;)

Share this post


Link to post

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.

Share this post


Link to post

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/

Share this post


Link to post

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.

Share this post


Link to post

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!

Share this post


Link to post
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'?

Share this post


Link to post
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).

Share this post


Link to post

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).

Share this post


Link to post
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 by MTrop

Share this post


Link to post
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.

Share this post


Link to post

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 by boris

Share this post


Link to post

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 by boris

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post
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 by MTrop : Add Github issue.

Share this post


Link to post
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!

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

@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 by MTrop : Figured it out

Share this post


Link to post

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.

Share this post


Link to post
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)

Share this post


Link to post

@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 by Giomancer : Released non-alpha

Share this post


Link to post

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.

 

unknown.png

 

unknown.png

Share this post


Link to post

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

Share this post


Link to post
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!

Share this post


Link to post

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!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×