ZDoom

[quote="randi"][git=5aba252b873ae6885b2fc056c9ede5105213ef59]Fixed.[/git][/quote]
Isn't [url=http://zdoom.org/gitdiff/5aba252/src/thingdef/thingdef_codeptr.cpp#0]this change[/url] leftover debugging?

[git=5aba252b873ae6885b2fc056c9ede5105213ef59]Fixed.[/git]

spawn:
TNT1 A 0 nodelay A_FooBar

spawn:
TNT1 A 0
TNT1 A 0 A_FooBar

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]spawn:
TNT1 A 0 nodelay A_FooBar[/code]
Spawn the actor, and wait for the first state tick to Foo the Bar:[code]spawn:
TNT1 A 0
TNT1 A 0 A_FooBar[/code]
Unless more was changed by the nodelay implementation than I would expect.

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.

spawn:
TNT1 A 0
TNT1 A 0 A_FooBar

spawn:
TNT1 A 0 nodelay A_FooBar

So is there actually supposed to be any functional difference between

[code]spawn:
TNT1 A 0
TNT1 A 0 A_FooBar[/code]and[code]spawn:
TNT1 A 0 nodelay A_FooBar[/code]?

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.

[quote="[url=http://zdoom.org/wiki/Actor_states#NoDelay]Actor_states[/url]"]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.[/quote]
Basically, remember the "spawn frame of an actor does not call a function on spawn" rule?

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

[quote="Graf Zahl"]Exploitation would be mostly by accident so that's not quite true.[/quote]That would be simple error, not "this is doing something weird and I'm gonna use that". (Exploitation meaning deliberate abuse/misuse.)

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

[quote="Graf Zahl"]I doubt this has been exploited much.[/quote]I don't think it's to harsh to say: Anyone exploiting this [i]deserves[/i] to have their mod broken.

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.

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

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'?

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

Likely an oversight, it appears that a NoDelay state can accidentally cause an actor to run a function twice in the same tic.
[code]actor foobar
{
states
{
spawn:
TNT1 A 0 nodelay
BAL1 A 1 A_ChangeVelocity(1,0,0)
wait
}
}[/code]
When the actor tics and checks/sets the state in the [url=https://github.com/rheit/zdoom/blob/519ff8b7d114b6d38ba0813b8d7f509ef6e6329c/src/p_mobj.cpp#L3639]state->GetNoDelay()[/url] block, it'll run both frames in the above actor and set the tics to 1. However, [url=https://github.com/rheit/zdoom/blob/519ff8b7d114b6d38ba0813b8d7f509ef6e6329c/src/p_mobj.cpp#L3660]it then goes on to run the normal frame counte[/url]r, 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.