Kill runaway Decorate scripts

[argv]

Decorate, being an assembly-like labels-and-jumps language, makes it very easy to inadvertently create an infinite loop. When one happens, the engine simply freezes. There is no hint as to what happened, let alone which actor state is responsible.

When an actor spends too long thinking, it would be helpful if the engine instead deleted the offending actor, and logged a warning to the console with its class and current state, like it does with runaway ACS scripts.

[Major Cooke]

_mental_ already tried something like this but it was shut down.

[Gez]

I still think you could have it done relatively easily by having a "statechange" counter for each mobj. Every time the actor enters a new state, increase it by one. Let the Tick() function reset it to zero. This way you can set an arbitrary high value (like two millions) after which state changes are aborted with an error message. The impact on the codebase would be minimal I think.

[_mental_]

_mental_ already tried something like this but it was shut down.

My attempt to fix it was inconsistent because I was unable to find all cases when infinite loop may occur.

[argv]

My attempt to fix it was inconsistent because I was unable to find all cases when infinite loop may occur.

Finding all cases where an infinite loop may occur is impossible. But you should be able to observe that an actor is taking too long, or has changed state too many times this tic, or something like that.

[Gez]

Hence my suggestion to count state changes during one tic. It doesn't matter if the two billion state jumps in one tic are an infinite loop or somehow just going through two billion separate, unique states -- there's a problem in either case, so abort.

[NeuralStunner]

I like Gez's approach. Clean, and also a sane upper limit. (Even though anything over a few thousand is probably bad practice. Still...)

[arookas]

Wouldn't instructions executed during anonymous functions also need to be counted (e.g. infinite for-loops)? If so, I hope this gets added as an option, maybe sort of a debug mode. This seems pretty great as a debugging feature.

[Graf Zahl]

Let's make this very quick. One single VM instruction requires 10-20 assembly instructions. Adding a runtime check for runaway functions requires adding a check for a global counter in here somewhere, at least in 64 bit that cannot be done with less than 6 assembly instructions. Conclusion: It would add a considerable slowdown and limit the VM's usability severely.