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

Very nice! Seems to work as expected, but I got a problem getting auto things in action pointer functions to work. I have this DECOhack code (converted from ZScript Blood Demon from Realm 667):


 

auto thing BloodDemonArm "Blood Demon Arm"
{
    ...
}


auto thing BloodDemon "Blood Demon"
{
    ...

    states
    {
        ...
        Death:
            ...
            SRG2 J 0 A_SpawnObject(thing BloodDemonArm, 0.0, 10.0, 0.0, 32.0, 0.0, -8.0, 4.0) // This is line 68
            ....
        ...
    }
}

 

That's pretty much as in the example, but I get the following error:

 

ERROR: (src\decohack\blooddemon.dh) Line 68, Token ",": Expected thing label name.

 

Line 68 is the one with the A_SpawnObject action pointer function. DECOhack recognized BloodDemonArm as a correct thing, because changing the thing to something invalid produces a different error.

 

A_SpawnObject(thing lalala, 0.0, 10.0, 0.0, 32.0, 0.0, -8.0, 4.0)

 

results into the error

 

ERROR: (src\decohack\blooddemon.dh) Line 68, Token ",": Expected valid thing alias: "lalala" is not a valid alias.

 

Full DECOhack file is attached.

 

 

blooddemon.zip

Share this post


Link to post

D'oh! I'll take a look.

 

I wonder if I should also make things named with an identifier use that name as the display name by default, if none was specified. Hmmm...

Share this post


Link to post

Since it looks like it'll take some more time for DSDHacked to get some more traction, and DEHEXTRA being more widespread, I'm wondering if it'd be viable to have some "auto sprite" feature in DECOHack. I.e. being able to use new (not defined in Doom or DEHEXTRA) sprites, like the "SRG2" sprite in the example I posted at the top of this page, then have DECOHack figure out which "SPxx" it wants to assign when compiling to DEHACKED. Same for the actual sprite image files, they could have their normal names (like "SRG2A0.xxx") in the "assets/sprites" or "convert/sprites" directory and just be compiled into the asset .WAD as "SPxx".

 

That would also make it easier to build a repository of DECOHack things, since the things could use unique sprite names, without the user having to go on a renaming spree to sort out all the "SPxx" names.

Share this post


Link to post

This loop

    each (pngFile : pngList) {
        arguments = ["/c3", "/f0", "/d8", "/kgrAb", "/y"];
        arguments->listadd(pngFile, 0);
        println("Compressing " + pngFile + "...");
        execresult(exec(exepath, arguments, envvars(), exeworkdir, stdout(), stderr(), stdin());
    }

iterates properly but only displays to stdout the first time through. Worse, the loop stops the rest of the script from displaying its own output, though I've confirmed that everything does get built correctly. I've spent the past day or two trying to figure out what's going on, trying different things, and I'm fairly sure I'm simply too much of a novice to understand.

 

bad.png.c490a3e84b97d6003edc19e381ef8bfc.png

With the output-quashing loop

 

normal.png.2c26745fddc37f6f33465ae428817f3f.png

What the script outputs normally; note the textures and project wads print their success.

Share this post


Link to post

Uh oh. Hopefully this isn't a terrible bug in exec. I'll have to dig further. It's probably a stream issue. Maybe standard-out is getting closed after the process finishes when it shouldn't be? I'll have to take a look.

 

For the time being, you may be able to write to a buffer (bufnew), open an output stream to it (bosopen), pass that to exec as the output, then read it into a string (bisopen, csropen), and print the string output (each csiterate), but that's gonna get complicated.

 

EDIT: Maybe something like this?

each (pngFile : pngList) {
    arguments = ["/c3", "/f0", "/d8", "/kgrAb", "/y"];
    arguments->listadd(pngFile, 0);
    println("Compressing " + pngFile + "...");

    outbuf = bufnew(32 * 1024) // 32k.
    execresult(exec(exepath, arguments, envvars(), exeworkdir, bosopen(outbuf), stderr(), stdin());
    each (line : outbuf->bisopen()->csropen()->csiterate()) {
        println(line);
    }
}

 

Edited by MTrop : added example

Share this post


Link to post
8 hours ago, boris said:

Since it looks like it'll take some more time for DSDHacked to get some more traction, and DEHEXTRA being more widespread, I'm wondering if it'd be viable to have some "auto sprite" feature in DECOHack. I.e. being able to use new (not defined in Doom or DEHEXTRA) sprites, like the "SRG2" sprite in the example I posted at the top of this page, then have DECOHack figure out which "SPxx" it wants to assign when compiling to DEHACKED. Same for the actual sprite image files, they could have their normal names (like "SRG2A0.xxx") in the "assets/sprites" or "convert/sprites" directory and just be compiled into the asset .WAD as "SPxx".

 

That would also make it easier to build a repository of DECOHack things, since the things could use unique sprite names, without the user having to go on a renaming spree to sort out all the "SPxx" names.

 

With MBF21 quickly superceded by DSDHACKED, I can't imagine that you'd see much use out of a mid-generational feature like this, especially since what you are suggesting requires the cooperation of more than just DECOHack to get the job done for very little gain.

 

Perhaps this will be the nudge that the other ports need to adopt DSDHACKED! Until then, people just sharing their source code should suffice. It's possible to copy the source DECOHack code into a single file with a DECOHack switch, so that it can be stored in the released WAD (I recommend "DEHSRC" for the lump name, or maybe a different one so that the program used is more clear?). DoomMake can do this in its DECOHack template projects, automatically.

Share this post


Link to post

 

On 11/6/2021 at 8:40 PM, MTrop said:

Uh oh. Hopefully this isn't a terrible bug in exec. I'll have to dig further. It's probably a stream issue. Maybe standard-out is getting closed after the process finishes when it shouldn't be? I'll have to take a look.

To give you more details, the process in question is a windows-native command line utility called pngout. Your idea for a workaround was partially successful, at least, as the rest of the doommake script was able to print to the console. Unfortunately, however, pngout also refused to print to the buffer, so I made do with declaring the output stream as null, which worked.

 

 

 

 

Edited by Giomancer : Improved post

Share this post


Link to post

Is there a "reference implementation" of all the things and weapons? I.e. how each one of them would look like in DECOHack, like the GZDoom wiki has? Looking at the GZDoom wiki works ok-ish, but the actors have some stuff that DeHackEd doesn't have.

Share this post


Link to post

At the moment, no.

 

I also debated whether DECOHack should prefill its "base" data with a reference code set, but I felt that would be a lot of needless extra parsing, not to mention that states and stuff would end up in incorrect places without micromanaging the state fill (not very readable or useful).

 

I wonder if I could get away with having a mechanism that auto-generates certain actors, but that too will need to know about some kinds of hardcodings or else some implementations would not work on a straight copy (I'm looking at you, chaingun code pointers!).

 

It might have to be done by hand, but at the moment, it's not a priority. The GZDoom wiki stuff works okay enough for a reference point.

Share this post


Link to post

Bumping to let you all know that DECOHack had a major bug fixed (introduced around the DSDHACKED support version):

 

Sound definitions and use of EXTENDED sound indices were off by 1, which would have potentially broken your EXTENDED patches (and a few sound definitions if you replaced those).

 

Please doomtools --update or download the new release!

 

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

Share this post


Link to post

That's strange. I can't replicate this error. From that message, it sounds like a thing definition is unclosed or unterminated from a previously included file, and the internal includes don't have anything like that. 

 

This code produces no errors on my side:

/*****************************************************************************
 * DECOHack Patch File
 * Main
 ****************************************************************************/

#include <extended>
#include <friendly>

alias thing AmbienceTemplate 151

 

What version of DECOHack/DoomTools are you running? Aliases were added in DECOHack 0.19.0.

 

Share this post


Link to post

I was expecting the issue to still be occurring but for some reason suddenly when I reach out for help it just magically stops throwing errors. Weird.

Share this post


Link to post

Ran into a new problem where, for some reason, the directories that are supposed to be converted just don't get converted. They just get sent into the wads as just pngs. Is there a way to have them properly convert?

image.png.61a9787b09631c318ac5dfc5cbfc3a8e.png

For some reason, it says "up to date" even though nothing's in them.

Edited by Obsidian Plague : actually y'know what there is a problem

Share this post


Link to post

I think you're using it the wrong way around.

 

You have to put the files you want to convert into the "convert" subdirectories, not in the "assets" subdirecoties. The converted files will be written to the "assets" subdirectories. The files in the "assets" subdirectories will be put into the WAD without any other modification.

Share this post


Link to post

To add, a directory tree is considered "up-to-date" if no changes were detected in it from the last execution - which includes an empty directory staying empty.

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
×