NoDelay can double up function calls

[edward850]

Likely an oversight, it appears that a NoDelay state can accidentally cause an actor to run a function twice in the same tic.

Code: Select all

actor foobar
{
   states
   {
   spawn:
      TNT1 A 0 nodelay
      BAL1 A 1 A_ChangeVelocity(1,0,0)
      wait
   }
}

When the actor tics and checks/sets the state in the state->GetNoDelay() block, it'll run both frames in the above actor and set the tics to 1. However, it then goes on to run the normal frame counter, and immediately tics back down to 0 and runs A_ChangeVelocity a second time in the same tic.
Something tells me that's not supposed to happen, and the block should return at the end, rather than continuing to the normal frame counter.

[Edward-san]

Knowing that this, if fixed, would cause some mod breakages (how many mods were released for zdoom 2.7.1, which use 'nodelay'?) ... maybe introduce a new word to use in place of 'nodelay'?

[Gez]

I really doubt it'd break that many mod. I'd wager it wouldn't actually break any. It might even fix some.

[Graf Zahl]

And even then, it's calling the same function twice which very rarely makes a difference that's noticable.
I doubt this has been exploited much.

[NeuralStunner]

I doubt this has been exploited much.

I don't think it's to harsh to say: Anyone exploiting this deserves to have their mod broken.

[Graf Zahl]

Exploitation would be mostly by accident so that's not quite true.

[NeuralStunner]

Exploitation would be mostly by accident so that's not quite true.

That would be simple error, not "this is doing something weird and I'm gonna use that". (Exploitation meaning deliberate abuse/misuse.)

[Matt]

Okay, so if that behaviour is actually a bug, then just what is nodelay supposed to do and why is it called "nodelay" and not "[whatever it is it's supposed to do]"?

[edward850]

Forces the action function associated to the state to be executed during the actor's first tic. This is only useful for the first state in an actor's spawn sequence.

Basically, remember the "spawn frame of an actor does not call a function on spawn" rule?

[Matt]

So is there actually supposed to be any functional difference between

Code: Select all

spawn:
TNT1 A 0
TNT1 A 0 A_FooBar

and

Code: Select all

spawn:
TNT1 A 0 nodelay A_FooBar

?

The way that wiki entry is written seems to imply there is not, but in situations where getting things done in the very first tic is crucial (e.g., a projectile spawning where it ought to instantly die) I have noticed that the latter does not actually "force the action function associated to the state to be executed during the actor's first tic" while the former does.

[edward850]

There shouldn't be a functional difference between the two, indeed. I would assume any behaviour where that is not the case would be a bug, as I cannot see anything else it should be doing in the code.

[FDARI]

Spawning does/did not call the state setting function (with its implicit countdown/next-state operation). It assigned a state directly, to avoid all the side effects.
A duration 0 state cannot normally be maintained, but on spawn it is maintained until the next time states advance naturally.

Foo the Bar as the actor is spawned:

Code: Select all

spawn:
TNT1 A 0 nodelay A_FooBar

Spawn the actor, and wait for the first state tick to Foo the Bar:

Code: Select all

spawn:
TNT1 A 0
TNT1 A 0 A_FooBar

Unless more was changed by the nodelay implementation than I would expect.

[randi]

Fixed.

[Gez]

Fixed.

Isn't this change leftover debugging?