MTrop
[DECOHack] New things can't have properties set to 0
Setting a property to zero on a newly created thing will leave that property out of the deh patch. This leaves the property's initialization to the engine, which can then cause discrepancies. For example, GZDoom sets default height to 16, which causes +SPAWNCEILING things to be offset from the ceiling.
Example code:
#include <extended>
auto thing Meat: thing NonsolidMeat2 { height 0 }
auto thing Tree: thing BigTree { radius 0 }
auto thing Ball: thing DoomImpBall { damage 0 }
thing Meat2 { height 0 }
thing TorchTree { radius 0 }
thing BaronBall { damage 0 }
Resulting DEH:
Thing 17 (Baron fireball)
Missile damage = 0
Thing 91 (Grey tree)
Width = 0
Thing 103 (Hanging arms out)
Height = 0
Thing 151 (Hanging arms out 2)
ID # = 59
Hit points = 1000
Width = 1310720
Reaction time = 8
Bits = 768
Mass = 100
Initial frame = 902
Thing 152 (Large tree)
ID # = 54
Hit points = 1000
Height = 1048576
Reaction time = 8
Bits = 2
Mass = 100
Initial frame = 915
Thing 153 (Imp fireball)
Hit points = 1000
Speed = 655360
Width = 393216
Height = 524288
Reaction time = 8
Bits = -2147416560
Mass = 100
Initial frame = 97
Death frame = 99
Alert sound = 16
Death sound = 17
Does this happen with other source ports? If not, this is a compliance issue with GZDoom rather than an issue with DECOHack, since those ports would correctly be setting those properties to 0 by default.
Testing only height for now, will test more extensively when I get more time. Here's a test wad.
Other than GZ, it also happens in Helion and UDB. Though UDB "defaults" to height 20 even if height 0 is explicitly specified in dehacked. And Helion doesn't draw the vanilla zero-height thing at all (culled by ceiling?). In DoomRetro, Crispy, DSDA, Nugget, Eternity and the Kex port it defaults to 0.
Anyway, is there an actual spec to be in compliance with? Or is it basically seniority-based (i.e. DoomRetro being the reference)? I don't disagree with the port probably being at fault, but it would be nice to have it spelled out somewhere. And I assume you're building the deh by comparing to some master table, so this isn't an easy fix on your end.
As a sidenote, the imp fireball bits in the first post prevent the deh from loading in WhackEd (tested 1.3.2 and redskull-1.2.4). I'm still pretty new to dehacked, so I'm not sure what the 32 leading 1s are supposed to do. The ports don't complain.
Unfortunately, there's no spec for the EXTENDED range. In this case, it would have to be what the first generation ports already do to initialize "new" Things.
As far as I can find, it looks like if the code was blindly based off of the PrBoom/DSDA implementation where the Thing in extended range or higher is needed, it is calloc'ed into memory, which would blank all of the fields, setting all of them to 0. All ports that use this code or something similar to this code will have the same behavior. If it happens in GZDoom and Helion (which would definitely not use the existing initializing code), I'd report it to them so that they aren't still unaware of how ports already initialize "new" Things.
Also, those Imp Fireball bits translate to 0b10000000000000010000011000010000 (32-bit), which match a translucent projectile. Not sure why Whacked wouldn't load it, it knows about the TRANSLUCENT bit.
GZ probably has them inheriting from a default zscript actor under the hood, or something to that effect. And maybe a similar thing in Helion with decorate. Anyway, I'll do the reports, but probably in a couple days (trying to finish a thing).
WhackEd will load it if I replace the value with 2147550736, with the same translucent flag. Could be a platform issue? int32/int64
That bitflag field should be a 32-bit integer, so WhackEd might be in the wrong, here. Could be a platform issue at its core, not sure.
In order to alleviate some pains with this sort of thing, I added a clause to allow a full dump of an object's properties: force output.
This will allow users to force the output of all of an object's properties, even if they do not differ from defaults, and should make ports get the correct values when read.
Added in commit 2d000d272acad0f5ac07cfe61081764f4abd2e1d.