The Official DoomTools Thread

[eev]

Whoops you did mention that, I completely missed it for all this time... sorry.

[MTrop]

It's okay. Anything "preprocessor" is going to be a tricky thing.

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.09.05-RELEASE

 

You will probably want this release as it updates a long-standing bug in graphic conversion.

Changes
-------

- **2024-09-05** Updated DoomStruct to `2.16.0`. [Changes here.](https://github.com/MTrop/DoomStruct/releases/tag/2.16.0-RELEASE)

DImgConv
--------

### Changed for 1.4.0

* `Fixed` Palette index 255 was considered for color matching. This is incorrect on patches/graphics (but correct on flats).

 

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.09.11-RELEASE

 

This fixes a small, but important bug.

DoomMake
--------

### Changed for 0.26.1

* `Fixed` Fixed a typo in utility-created `doommake.properties` files.

WTEXport
--------

### Changed for 1.5.4

* `Fixed` Some texture sets were being erroneously classified as STRIFE-formatted texture sets due to a typo.

 

[Doomy__Doom]

Inspired by the problem of this thread - id1 resources probably need special treatment in Doommake/WTexScan/??? for the purposes of merging patches/textures/animated/switches with other boom-format resource packs without violating no-redistribution-of-id-owned-resources matter.

 

I imagine more people will start doing things like id1+otex/32-in-24-tex/you-name-it-tex eventually and bump straight into merging animated and subsequent cleanup of stray id1 resources.

[MTrop]

I don't think it needs special treatment - whatever WAD you use as your "base" WAD file in WTEXport will not have its data copied over (it doesn't need to be a full IWAD).

 

So, if id1-res.wad gets used as the base resource, only its texture entries (not data) get used as the base to build the new texture data, which means the player using a new PWAD that uses its resources plus others from other texture WADs will need to include id1-res.wad when they play.

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/2024.10.03-RELEASE

Changes
-------

- **2024-10-03** Updated DoomStruct to `2.17.0`. [Changes here.](https://github.com/MTrop/DoomStruct/releases/tag/2.17.0-RELEASE)

WTEXport
--------

### Changed for 1.6.0

* `Fixed` Some new textures that "existed" but had different patch ordering or no new patches were not copied over. (Issue #118)

 

[Scorcher]

EDIT: Mistaken

Edited October 6 by Scorcher

[MTrop]

7 hours ago, Scorcher said:

Projectile group is currently broken as of this update:

 

Not a bug. Barons and Hell Knights are already part of Projectile Group 1, so it is not considered a change, and will not make it into the patch.

[Doomy__Doom]

43 minutes ago, MTrop said:

 

Not a bug. Barons and Hell Knights are already part of Projectile Group 1, so it is not considered a change, and will not make it into the patch. 

If I understand dsda-doom's implementation correctly, any custom projectile groups are appended to the hardcoded list, which serves solely to implement the vanilla behaviors.

https://github.com/kraflab/dsda-doom/blob/bcfb3afc9c093d6e18de4d5f23c404b1c19416a5/prboom2/src/d_deh.c#L1956

// mbf21
    // custom groups count from the end of the vanilla list
    // -> no concern for clashes
    case 25:
      mi->infighting_group = (int)(value);
      if (mi->infighting_group < 0)
      {
        I_Error("Infighting groups must be >= 0 (check your dehacked)");
        return;
      }
      mi->infighting_group = mi->infighting_group + IG_END;

So "Infighting group = 1" in dehacked becomes something of a "Infighting group = 5" or such under the hood.

 

I've quickly tested several major ports (dsda, woof, gzdoom, retro), and in all of them the following two patches are not equivalent:

--------1-------
Thing 18 (Hell Knight)
Infighting group = 1

Splash group = 1

Thing 12 (Imp)
Infighting group = 1
Projectile group = 1
Splash group = 1


--------2-------
Thing 18 (Hell Knight)
Infighting group = 1
Projectile group = 1
Splash group = 1

Thing 12 (Imp)
Infighting group = 1
Projectile group = 1
Splash group = 1

[Scorcher]

1 hour ago, MTrop said:

Not a bug. Barons and Hell Knights are already part of Projectile Group 1, so it is not considered a change, and will not make it into the patch.

 

Huh, I didn't know it was applied by default, I assumed giving the Baron a custom projectile without grouping them manually would then cause them to infight, good to know. :)

[Gez]

 

4 hours ago, MTrop said:

Not a bug. Barons and Hell Knights are already part of Projectile Group 1, so it is not considered a change, and will not make it into the patch.

It should be considered a change, because it actually is one.

 

3 hours ago, Doomy__Doom said:

So "Infighting group = 1" in dehacked becomes something of a "Infighting group = 5" or such under the hood.

typedef enum {
  IG_DEFAULT,
  IG_END
} infighting_group_t;

typedef enum {
  PG_GROUPLESS = -1,
  PG_DEFAULT,
  PG_BARON,
  PG_END
} projectile_group_t;

typedef enum {
  SG_DEFAULT,
  SG_END
} splash_group_t;

The default groups are 0, and so far only projectile_group has a non-default value defined. So IG_END is 1, SG_END is 1, and PG_END is 2. Infighting group = 1 in dehacked will therefore turn to infighting_group = 2 under the hood.

 

This whole scheme also means that when you have Projectile group = 1 for the knight or baron in your dehacked, it is not the default value. You cannot have the default value. Because whatever value you give, it will add PG_END to it, so +2; and so if you wanted to end up with 1 you'd have to give -1, but that will just make it groupless:

    case 26:
      mi->projectile_group = (int)(value);
      if (mi->projectile_group < 0)
        mi->projectile_group = PG_GROUPLESS;
      else
        mi->projectile_group = mi->projectile_group + PG_END;
      return;

In other words, not defining projectile group for the knight or baron means that it will keep its default value of 1, while giving it explicitly a value of 1 means it will have a value of 3 (1+PG_END = 1+2). If you want to have the imp in the same projectile group as the knight and baron, you'll have to define the projectile group for the imp, the knight, and the baron -- setting it to PG_BARON is impossible to a mod, so you have to redefine all three.

[MTrop]

So I guess the question I then have is, is this an error in implementation or an error in DECOHack? If the port in question is not setting the correct value, then it's on the port to fix, rather than making the utility account for an implementation mistake.

 

It doesn't make sense to me that setting a value in DeHackEd should set the incorrect one port-side.

[Doomy__Doom]

My reading, fwiw, is that:

1) MBF21 spec does not require source ports to implement vanilla behaviors using infighting groups and does not reserve PG=1 for HK/Baron. It only requires that "if a dehackeded patch says PG=M and M>0, then those things do not damage each other".

 

2) dsda-doom's implementation chose to migrate vanilla behavior to PG, and created an extensible enum and patching behavior to future-proof need for hardcoded behaviors. It is a pure coincidence that PG_BARON happens to be at position "1" in enum, and may theoretically (if unlikely) change in the future. Even if the enum changes, it stays compatible with all preexisting patches since IGs internally start at enum length.

 

3) other source ports as mentioned above exhibit the same behavior of PG=1 - one has to explicitly set it for HK/Baron. Some ports have pretty much verbatim dsda's approach with PG_END enum - Odamex, Doom Retro, Woof. GZDoom instead of having a special PG for baron, relies on comparing actor classes if PG has the default value of 0 (in GZ hellknight inherits from baron). Eternity Engine seems to create its own ThingGroup objects based on PG value, and Barons/HKs are defined through EDF features.

 

So my conclusion is that PG has to go on the patch at all times, because its internal handling is effectively implementation-defined. Projectile group = M only means actual number M within the text of the patch. Ditto infighting and splash groups.

 

It's probably a good idea to get some actual port devs input though.

[CrazyDoomguy]

Exist there Dehacked thing groups for "A_BFGSpray"? Example monster shots BFG ball, but BFG spread can damage same group

 

Quote

Things

Dehacked Thing Groups
 

Infighting

Add Infighting group = N in Thing definition.

N is a nonnegative integer.

Things with the same value of N will not target each other after taking damage.
 

Projectile

Add Projectile group = M in Thing definition.

M is an integer.

Things with the same value of M will not deal projectile damage to each other.

A negative value of M means that species has no projectile immunity, even to other things in the same species.

Splash

Add Splash group = S in Thing definition.

S is a nonnegative integer.

If an explosion (or other splash damage source) has the same splash group as the target, it will not deal damage.

 

[CrazyDoomguy]

ERROR: (D:\Doom\Decohack\Decohack.dh) Line 37, Token "Speed": Health value (2000000) not between 0 and 999999, inclusively.

FYI, if I set Health over 999,999, an error appears. However, if I manually write it in Dehacked, there is no error in DSDA

 

[MTrop]

I set the max values to what was the max in Whacked and other editors. I'll have to look at the tables to figure out what the true maximums are.

[finnks13]

Hiya, I just want to report a small issue that occurred with the "state protect" feature.

 

I tried to protect states 0 to 1999, but this caused decohack to hang and not respond or throw an error. After I found the part in the decohack reference where it says that states 0 and 1 are protected by default, I instead tried protecting states 2 to 1999, and this let the patch compile immediately. I've tried compiling via the command line and the DoomTools GUI and they have the same behaviour in this case. I assume not being able to re-protect protected states is intended, but the program hanging and not giving an error isn't, with how good decohack normally is about being specific with error messages.

 

I've attached the decohack source of the patch that causes the problem here: decohack_bug.zip (It currently does not compile, but editing line 6 to say "state protect 2 to 1999" will allow it to do so.)

[MTrop]

Hmmm. This is a perplexing bug, and has to do with how I'm storing which indices are protected.

 

Created an issue: https://github.com/MTrop/DoomTools/issues/119

[MTrop]

So, I'm trying to solve a perplexing issue regarding Sound Indices when it comes to editing Sound info - do those entries start at 0, or do they start at 1? WhackEd starts them at 0, whereas it's 1 in function calls and everywhere else.

 

So, is WhackEd wrong, or is it always off by 1 for the entries themselves?

 

Issue in question: https://github.com/MTrop/DoomTools/issues/120

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.11.08-RELEASE

 

This release fixes some important bugs, so upgrade pronto! Also, @exl, you might want to double-check what index you are writing sounds from in WhackEd - the sound entries are supposed to start at 1, not 0 - I double-checked this with DeHackEd 3.1.

Changes
-------

- **2024-10-19** Added `--java` switch to DoomTools (and About Java dialog to GUI).

DECOHack
--------

### Changed for 0.34.0

* `Fixed` Any clause that sets intervals (freeing things, protecting states) may create a condition that causes an endless loop. (Issue. #119)
* `Fixed` Sound entries were off by 1 due to a misunderstanding of what index sound entries started at. (Issue #120)

 

[exl]

Turns out sound reading was broken anyway, on top of indeed being 0-based. Thanks for mentioning that!

[MTrop]

I can't take all the credit - credit goes to @Napsalm for verifying that it was a bug in the first place!