[2.9pre-30-g1101546] ACS_NamedExecuteWithResult Crash

[AFADoomer]

Decorate actors with ACS_NamedExecuteWithResult that use comparison operators cause an engine crash when the frame is reached.

This actor crashes MAP01 of Doom 2 after 35 tics (A_TestScript is a dummy library-based script that returns a value of 1).

Code: Select all

ACTOR Test replaces ZombieMan
{
	States
	{
	Spawn:
		UNKN A 35
		TNT1 A 0 A_JumpIf(ACS_NamedExecuteWithResult("A_TestScript") > 0, "Done")
		Loop
	Done:
		TNT1 A 0
		Stop
	}
}

If I leave out the comparison operation or change it to "== 1", it doesn't crash, but also fails to make the jump. If I change it to some other < or > operation, it crashes, regardless of what the output should be (true or false).

Occasionally, the crash happens as the game is loading, with a "Script error, "Test.pk7:decorate.txt" line 7: Numeric type expected" notation in the log file.

Another oddity: If I replace the call with CallACS instead of ACS_NamedExecuteWithResult, the crashes (and jump errors) go away in all instances that I've checked.

Example here. Just load a map with a ZombieMan actor and wait for the crash.

EDIT: I was running the 64-bit build and not getting crash dumps. Trying with the 32-bit build actually gave me crash reports (one is attached).

[hfc2x]

Damn, I was about to post about this exact same thing.

I made a (perhaps too complicated) WAD file that would have worked before, but simply crashes now.

[Major Cooke]

Try storing the variable in the mean time in a user var while waiting for this to be fixed.

[AFADoomer]

Damn, I was about to post about this exact same thing.

I made a (perhaps too complicated) WAD file that would have worked before, but simply crashes now.

Interestingly enough, I don't get a crash with your .wad, but the jump states aren't doing anything!

[Graf Zahl]

Actually, it looks that the reason why this crashes is that this is not implemented.

In short: ACS_NamedExecuteWithResult is an action special and has no return type defined.
Randi needs to fix this.

[Graf Zahl]

If I'm not mistaken, this is the last remaining open scripting bug. Unfortunately it's also the only one where I don't have an idea how to fix it.
Will continue trying...

[Graf Zahl]

Yay, fixed this too. Actually it was harder to understand what needed to be done than to fix it.

[Major Cooke]

Man, graf, you are on a ROLL!

[Graf Zahl]

This was the last one. For now the scripting stuff is clean. BTW, only one of the bugs was VM related (the one with the bad code generation.)

[Nash]

This was the last one. For now the scripting stuff is clean.

Good to know! Can't wait to catch up to the latest stuff.

[Fishytza]

For now the scripting stuff is clean

Awesome! Hopefully now I can start properly messing around with this stuff without encountering several bugs.
But that's probably a naive statement, isn't it.

Thanks for all your efforts, Graf and Major Cooke. You guys are awesome.

[Major Cooke]

Heh, all I did was find them. Thank the dev team for being on top and so quick to respond.

That's the nice thing about me, I do such weird shit with my mods that they are most likely to be broken by new changes of engines like the scripting branch. But that's also good -- the sooner they're found, the sooner they're fixed.

[AFADoomer]

Thanks, Graf!

Confirmed that this fixed my Wolf3D TC in ZDoom, just waiting for the updated GZDoom build so I can confirm it works there (but assuming it will, because, same code...).