I’ve found that occasionally, game-breaking edge cases can occur in my game during brief periods of low frame rate (lag spikes or particularly system-taxing moments) if delay nodes are hit.
The reason for this is that, during these moments, it’s possible for the frame time to climb so high that the delay is shorter than the frame time itself, so the “latent action” is performed in the same frame as the delay is called in, producing unexpected results
Obviously, this is more or less never the DESIRED behavior (I suppose in some cases the delay might have a reason to be tied to real-world time, but I would hazard that in MOST cases, a delay node would always be expected to fire its output in a frame OTHER than the one it was triggered in), so I’d request a simple Int variable on delays which, when set forces the delay to wait at least [X] Ticks before firing its output, regardless of whether or not its timer is up.
This way, delay-based behaviors which need to allow a complete tick pulse before running their finish (for example, opening a gate and hitting a delay which will then close the gate shortly thereafter, which needs AT LEAST one Tick execution pulse to make it THROUGH the gate in that interim to work properly) can be guaranteed to work even when the framerate is below the target.