Loops cause havoc when determining possible delays in code

[sovdeeth]

Skript/Server Version

2.10.0-pre1 and below

Bug Description

While loops (and any other looping section) do not accurately represent the possible delay to any syntax within them or in their condition[s]. This is effectively impossible to fix with current API as the first execution of a loop may be undelayed, and specifically need that undelayed state to work, but then the second execution is delayed. The parse-time delay api is not capable of representing this, and as such a runtime api for delays is required.

Expected Behavior

Conditions and syntaxes within while loops should behave accurately according the the delays encountered when running the script.

Steps to Reproduce

on player pressing of any input key:
    while player is pressing forward movement key:
        broadcast loop-counter
        wait 1 tick

This creates an infinite loop, since the CondIsPressingKey does not register that it has been delayed the second time, and as such continues to pull from the event-values.

Fixing this by parsing the condition after loading the loop section instead causes the loop to never run, since the condition will never pull from the event-values and instead gets the keys from before forward is pressed.

Errors or Screenshots

No response

Other

No response

Agreement

• I have read the guidelines above and affirm I am following them with this report.

[sovdeeth]

Discussion has pointed out Delay.isDelayed() as a possible help, but that has a bug of its own, since it's entirely event-based and doesn't consider different structures separately:

on jump:
  send isDelayed # sends false
  wait 1 tick # adds to DELAYED
  send isDelayed # sends true

on jump:
  send isDelayed # uh oh, this ran after the first event, so the event's already in DELAYED! returns TRUE
  wait 1 tick
  send isDelayed # sends true