[Dehacked Vanilla] Monster Speed Value of "10.0" vs "10"

[Arsinikk]

Hey guys,

 

So I got a pretty strange Dehacked thing I'm trying to figure out. So I have a monster with it's speed set to 10.0, which if you open the dehacked file in Whacked it will give an error that the speed value is not an integer.

 

What's strange is that having the speed set to 10.0 works perfectly fine in Vanilla and all ports... and I like the speed of the monster when it is set to this value.

 

I started to run into an issue when trying to convert my dehacked into decorate for this particular monster, since it seems that the speed being set to 10.0 is actually a little bit faster than it being set to 10.

 

I guess my question is what actual integer speed would be equivariant to what 10.0 is in dehacked? (since speed 10 is actually slower)

 

And would it be possible to have a decorate speed to mimic the same behaviour of 10.0 in dehacked?

[Gez]

2 hours ago, Arsinikk said:

I started to run into an issue when trying to convert my dehacked into decorate for this particular monster, since it seems that the speed being set to 10.0 is actually a little bit faster than it being set to 10.

That doesn't sound right.

[Arsinikk]

@Gez I've recorded a video showing the "difference"... I honestly can't tell if I'm just have a sort of placebo effect or if there actually is a difference, but it does seem to me that 10 in gzdoom does seem slower.

 

 

[Gez]

The only instance I can think of where 10.0 would be really different from 10 is when you're using fixed point values. Because fixed point values are actually integers under the hood, with a factor of 65536, so that decimal values can still be expressed. In that case, 10 would just be 10, while 10.0 would actually be 655360.

 

But that cannot be the case here because with such a massive difference, there could only be two possible outcomes: either the "speed 10" imps are normal speed and the "speed 10.0" imps are game-breakingly glitchingly fast to the point they seem to teleport constantly instead of actually moving; or the "speed 10.0" imps are normal speed while the "speed 10" imps are so absurdly slow they don't seem to move at all.

 

You wouldn't get in a situation where you can't really tell for sure but it seems like one might be slightly faster than the other.

 

 

Also, one way you can test it scientifically: record a demo. Then switch the speed value to the other format and play back the demo. If it stays in sync... it's the proof you're imagining things.

[hobomaster22]

6 hours ago, Arsinikk said:

So I got a pretty strange Dehacked thing I'm trying to figure out. So I have a monster with it's speed set to 10.0, which if you open the dehacked file in Whacked it will give an error that the speed value is not an integer. 

What you are experiencing is a quirk of how dehacked files are parsed in most Doom ports. Whacked is assuming that it must be an integer, and complaining that you put a decimal. The assumption is correct, but because of how the parsing was implemented it doesn't actually work that way. I've dug into this before and what happens is the string is parsed using sscanf with %d, and the implementation of sscanf causes it to stop parsing at the decimal and returns success. In this case 10.0 just becomes 10. Because of this quirk anything after the decimal is ignored, so 420.69 would just become 420.

[maxmanium]

7 hours ago, Arsinikk said:

-snip-

 

Is that the Imp Class II from Strain but with BruisAttack?

[Arsinikk]

56 minutes ago, maxmanium said:

 

Is that the Imp Class II from Strain but with BruisAttack?

Yes lmao

[Arsinikk]

5 hours ago, hobomaster22 said:

In this case 10.0 just becomes 10. Because of this quirk anything after the decimal is ignored, so 420.69 would just become 420.

 

Yeah, I think that this only happens when I'm using WhackEd, because the program is kinda coded weird when it comes to copying and pasting numbers and sometimes adds the ".0" at the end. Though in my testing, it seems that whether the speed is 10.0 or 10, it is exactly the same when recording / playing demos. And since the speed value is an integer and not fixed point, it doesn't cause much of an issue. If it was fixed point like the values width or height, it'd prob cause an issue.

 

But it's good to know that Dehacked will just ignore the ".0" at the end of an integer value and round it, not actually affected the value. 

 

 

 

7 hours ago, Gez said:

Also, one way you can test it scientifically: record a demo. Then switch the speed value to the other format and play back the demo. If it stays in sync... it's the proof you're imagining things.

 

So I did a bunch of tests with demos and I can conclude that there is no difference between 10 and 10.0 when it comes to dehacked in either DSDA Doom or GZDoom.

 

However, I did find that adding "speed = 10" in decorate as opposed to not adding it and just using the dehacked speed value, does slightly change the speed of the imps and causes a demo desync: (audio is purposely layered to show differences)

 

 

I don't know if it's that much of a difference for like the normal player to notice. But my guess is that when you add a speed value to decorate, ZDoom's speed algorithm takes over the default Dehacked speed (which is slightly different?)

 

Just a minor question:

The main reason I wanted to add decorate for the monsters is that I wanted max compat for the wad... Although this particular wad is complevel 2 and I don't know if it's really needed to add a speed value for decorate, since I think most ports that read decorate also read dehacked (correct me if I'm wrong)...

I mostly wanted to add decorate for the monsters so I could add custom obituaries for ZDoom ports.

Edited February 17, 2022 by Arsinikk

[Gez]

I don't think you can really make a meaningful comparison between DECORATE and DEHACKED because they won't be the same actors.

 

DEHACKED can only modify existing actors. It can't create new ones.

DECORATE can only create new actors. It can't modify existing ones.

 

So in your comparison, you're comparing two different mobj classes. And that can be enough to provoke a desync even if it seems they use the exact same code.

 

Also there's no such thing as a "speed algorithm". Speed is just a value.  When a monster calls A_Chase, it teleports by <Speed> units in a cardinal or ordinal direction, unless its moves are all blocked. Then it doesn't move. This behavior is identical regardless of DEHACKED, DECORATE, or ZScript.

Edited February 17, 2022 by Gez

[Arsinikk]

15 minutes ago, Gez said:

DEHACKED can only modify existing actors. It can't create new ones.

DECORATE can only create new actors. It can't modify existing ones.
...
And that can be enough to provoke a desync even if it seems they use the exact same code.

I am a little confused on this from the fact that in the video above, both videos have a DECORATE declared "ACTOR NewImp : DoomImp replaces CommanderKeen" which replaces the dehacked imp.

 

Literally the only difference is that one has an add "Speed 10" line in the DECORATE.

 

Also while DECORATE can only create new actors, it also apparently takes attributes from the initial dehacked actors?

Because in one of these examples, I didn't put "Speed 10" and yet I replaced the dehacked monster with a decorate actor... So it must've pulled the speed info from the dehacked.

 

20 minutes ago, Gez said:

Also there's no such thing as a "speed algorithm". Speed is just a value.  When a monster calls A_Chase, it teleports by <Speed> units in a cardinal or ordinal direction, unless its moves are all blocked. Then it doesn't move. This behavior is identical regardless of DEHACKED, DECORATE, or ZScript.

I only mentioned this because I know that ZDoom uses different movement and physics than like DSDA Doom or PrBoom+. Like weird things like I'm not sure if it's possible to do glides in ZDoom, no momentum on decorations, etc. So it wouldn't surprise me that I might notice the monsters having slightly different movement in ZDoom, and maybe it's more noticeable when they move much faster.

[Gez]

There's no such thing as an initial DEHACKED actor.

 

The DoomImp in GZDoom is a ZScript actor. Its speed is 8.

 

GZDoom will first process the ZScript code, then in second it processes the DECORATE code (this way DECORATE actors can inherit from ZScript actors, but not the other way around), and finally it processes DEHACKED code.

 

DEHACKED is processed last because, again, DEHACKED cannot create new actors. It can only modify existing ones. So it needs the vanilla actors to exist first, and all the vanilla actors are declared in ZScript code.

 

So what happens?

Scenario #1: you have a NewImp that inherits from DoomImp without changing anything, and you use DEHACKED to change the imp's speed to 10.

1. ZScript code from gzdoom.pk3 is parsed. Actor class DoomImp is created with speed 8.
2. DECORATE code from your mod is parsed. Actor class NewImp is created, inheriting the values from DoomImp. It therefore gets speed 8.
3. DEHACKED code from your mod is parsed. Actor class DoomImp has its speed changed to 10. This only has a effect on DoomImp, and does not impact NewImp, because NewImp is already created and finalized by the time DEHACKED is handled.

The result is NewImp has a speed of 8, while DoomImp has a speed of 10.

 

Scenario #2: you have a NewImp that inherits from DoomImp but also sets speed to 10, and you use DEHACKED to change the imp's speed to 10.

1. ZScript code from gzdoom.pk3 is parsed. Actor class DoomImp is created with speed 8.
2. DECORATE code from your mod is parsed. Actor class NewImp is created, inheriting the values from DoomImp but explicitly setting its speed to 10, overriding the inherited value.
3. DEHACKED code from your mod is parsed. Actor class DoomImp has its speed changed to 10. Again, this has no effect on classes derived from DoomImp.

The result is that NewImp has a speed of 10, and DoomImp also has a speed of 10.

Edited February 17, 2022 by Gez

[Arsinikk]

Ok, so I understand that the DoomImp is a ZScript actor with a default speed of 8, just like in normal doom.

 

I also understand that the process is ZScript > DECORATE > DehackEd.

 

I even follow your scenarios, up until the part where 

28 minutes ago, Gez said:

DoomImp has its speed changed to 10

 

I do not understand how this would be happening if I haven't changed the normal DoomImp with DECORATE, and I haven't touched the normal Imp in DehackEd.

 

This is what I have in DECORATE (you can comment/uncomment the speed attribute):

ACTOR NewImp : DoomImp replaces CommanderKeen
{
  Health 60
  //Speed 10
  PainChance 300
  SeeSound "wolfss/sight"
  HitObituary "$OB_NEWIMPHIT"
  Obituary "$OB_NEWIMP"
  States
  {
  Spawn:
    TROO AB 10 A_Look
    Loop
  See:
    TROO A 20
    TROO AABBCCDD 1 A_Chase
    Goto See+1
  Melee:
  Missile:
    TROO EE 15 A_FaceTarget
    TROO F 3 A_BruisAttack
	TROO G 1 A_SpidRefire
    Goto See+1
  Pain:
    TROO H 4
    TROO H 4 A_Pain
    Goto See+1
  Death:
    TROO I 8
    TROO J 8 A_Scream
    TROO K 6
    TROO L 6 A_NoBlocking
    TROO M -1
    Stop
  XDeath:
    TROO N 5
    TROO O 5 A_XScream
    TROO P 5
    TROO Q 5 A_NoBlocking
    TROO RST 5
    TROO U -1
    Stop
  Raise:
    TROO ML 8
    TROO KJI 6
    Goto See+1
  }
}

What this should mean in DECORATE is that it should pull all of the stats from the original DoomImp actor, and apply them to this actor. And then afterward the added changes that this actor has will overwrite the DoomImp stats for this actor and NOT the original DoomImp actor.

 

The main DoomImp actor should remain unchanged, because I just pulled the stats from the DoomImp and didn't alter the DoomImp. Only the NewImp's actor attributes have been altered.

 

Would be the same for the DehackEd. It shouldn't change the speed of the DoomImp since the DehackEd info of the NewImp are taken from the CommanderKeen and not the imp in the DehackEd.

Edited February 17, 2022 by Arsinikk

[Gez]

19 minutes ago, Arsinikk said:

I do not understand how this would be happening if I haven't changed the normal DoomImp with DECORATE, and I haven't touched the normal Imp in DehackEd.

Your video compared two situation:

• DoomImp changed in DEHACKED to have speed 10, NewImp without a set speed value (and therefore having only speed 8)
• DoomImp changed in DEHACKED to have speed 10, NewImp with a set speed of 10

Now you're talking about another scenario in which you don't use DEHACKED anymore. If you don't use DEHACKED, then DoomImp has speed 8.

 

19 minutes ago, Arsinikk said:

Would be the same for the DehackEd. It shouldn't change the speed of the DoomImp since the DehackEd info of the NewImp are taken from the CommanderKeen and not the imp in the DehackEd.

What? No. NewImp inherits from DoomImp, not from CommanderKeen. It replaces CommanderKeen but isn't based on it. Also there's no DEHACKED info of the NewImp, because NewImp is not a vanilla actor and therefore cannot be changed with DEHACKED.

Edited February 17, 2022 by Gez

[Arsinikk]

8 minutes ago, Gez said:

•  DoomImp changed in DEHACKED to have speed 10, NewImp without a set speed value (and therefore having only speed 8)
•  DoomImp changed in DEHACKED to have speed 10, NewImp with a set speed of 10

Oh ok. I think I see the confusion... The DoomImp had never been changed in DEHACKED. The CommanderKeen had been changed in DEHACKED to be the new imp, so I can have the normal imp and the new imp.

 

10 minutes ago, Gez said:

 Now you're talking about another scenario in which you don't use DEHACKED anymore. If you don't use DEHACKED, then DoomImp has speed 8.

The scenario I'm using has been the same. I used both DEHACKED and DECORATE. The DEHACKED changes the CommanderKeen to be the new imp. The DECORATE NewImp replaces the CommanderKeen and takes the traits of the DoomImp and tweaks them.

 

11 minutes ago, Gez said:

What? No. NewImp inherits from DoomImp, not from CommanderKeen. It replaces CommanderKeen but isn't based on it. Also there's no DEHACKED info of the NewImp, because NewImp is not a vanilla actor and therefore cannot be changed with DEHACKED.

This was poorly worded on my part... I meant that somehow the NewImp takes some of the information from the CommanderKeen that has been tweaked to be the new imp in DEHACKED.

 

What I meant is that somehow it would have to get the speed of 10 from the CommanderKeen from the DEHACKED if it wasn't listed in the NewImp DECORATE declaration.

[Gez]

No, that's not possible. Actors do not inherit anything from what they replace. That's why when you want to make a tweak to a monster in DECORATE you need to both inherit from it and replace it, resulting in things like Actor MyImp : DoomImp replaces DoomImp.

 

You could do something like Actor Lulz : Cyberdemon replaces Stimpack {} if you want to check.

[Arsinikk]

24 minutes ago, Gez said:

No, that's not possible. Actors do not inherit anything from what they replace. That's why when you want to make a tweak to a monster in DECORATE you need to both inherit from it and replace it, resulting in things like Actor MyImp : DoomImp replaces DoomImp.

Ok, so I did do a test... I set my CommanderKeen Dehacked Imp to have a speed of 0.

 

And then in Decorate, did not specify any speed, but said "DoomImp replaces CommanderKeen".

 

In DSDA Doom, the new imps did not move cuz they had a speed of 0 in DEHACKED.

In GZDoom, the new imps did move... meaning that they pulled the speed of 8 from the parent DoomImp from DECORATE.

 

Another test (GZDoom), setting the speed of the DECORATE "Actor NewImp : DoomImp replaces CommanderKeen" to 40.

DoomImp stays at speed of 8.

NewImp now goes at the speed of 40.

 

So what we can infer here is that, Dehacked does not apply any information to DECORATE actors since, the actors have already replaced what Dehacked was going to tweak.

 

However, this also tells us in DECORATE that the attributes under "Actor NewImp : DoomImp replaces CommanderKeen" do not apply themselves to the parent DoomImp, but only to the NewImp.

 

43 minutes ago, Arsinikk said:

What I meant is that somehow it would have to get the speed of 10 from the CommanderKeen from the DEHACKED if it wasn't listed in the NewImp DECORATE declaration.

This means that the imp must've actually been going at the speed of 8 when I didn't include a speed in the DECORATE, since that's what the DoomImp actor class is set to.

Edited February 17, 2022 by Arsinikk

[Gez]

Yes, now you got it. :)

 

1 minute ago, Arsinikk said:

However, this also tells us that the attributes under "Actor NewImp : DoomImp replaces CommanderKeen" do not apply themselves to the parent DoomImp, but only to the NewImp.

Indeed. An actor declaration cannot change its parent actor, since after all DECORATE doesn't allow modifying existing actors.

[Arsinikk]

@Gez I guess my final question would be: is there any point to converting a DEHACKED monster into DECORATE in a Vanilla (complevel 2) megawad, besides the fact that you can add obituaries and maybe include the monster in the endcast sequence?

 

Because don't most (if not all) sourceports that support DECORATE also read DEHACKED?

[Gez]

21 minutes ago, Arsinikk said:

 I guess my final question would be: is there any point to converting a DEHACKED monster into DECORATE in a Vanilla (complevel 2) megawad, besides the fact that you can add obituaries and maybe include the monster in the endcast sequence?

Indeed, there isn't much point in general. Unless you want to provide an "enhanced version" for DECORATE-compatible ports, where the behavior is different on purpose (e.g. more frames of animation for a "Smooth Doom" effect, alternate death sequences, things like that). Or, indeed, a custom obituary string. Maybe GZDoom could have placeholder obits for all the things that DEHACKED can turn into monsters...

 

For the endcast sequence, note that you don't need to make a functional monster. You can make DECORATE code for a "dummy" monster that only serves to appear in the endcast sequence but will not be met during the game.

[Arsinikk]

12 minutes ago, Gez said:

For the endcast sequence, note that you don't need to make a functional monster. You can make DECORATE code for a "dummy" monster that only serves to appear in the endcast sequence but will not be met during the game.

This is good to know... Actually didn't think about that, but it makes sense.

 

Thanks @Gez, Hopefully I didn't annoy you too much. But your help is much appreciated! :)

[Gez]

No problem!