Problem

As described in #8203, when a section has a statement that cause a delay, that delay is propagates beyond the section even if the section is guaranteed to terminate execution (e.g. with a stop statement). This creates unexpected behavior as noted in the issue.

Solution

I've adjusted Section's loadCode method to consider the execution intent of the loaded section. If the loaded section results in execution terminating, then the delay state is set back to what it was before the section was loaded (i.e. the section has no effects on the delay state).

There were also a few issues with SecConditional I've resolved:

• then blocks could be repeated multiple times
• Two utility methods intending to look at the preceding conditionals in the chain incorrectly did so. They modeled the logic of the original method, but the circumstances are different so the logic is different. When these methods are called, the correctness of the chain has been verified, so they simply need to terminate when encountering the root IF conditional.

This problem is not fully resolved (for other cases). It does not consider exiting a number of sections. However, this is a more complex problem that may not be possible to solve given Skript's current design. The delay of the section would apply to upper sections, but not the immediate parent (or parents if exiting multiple). Skript does not currently have a way to handle this.

Testing Completed

Added a test for the expected delay behavior.
Added a test to SecConditional for then behavior.

Supporting Information

Completes:

• Can't change the damage anymore after the event has already passed #8203

Related: none
AI assistance: none