SkriptLang
Loops cause havoc when determining possible delays in code
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
- [X] I have read the guidelines above and affirm I am following them with this report.
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
This issue does not have a pr fixing it yet. #7777 is a stepping stone to fixing it, but not a fix. Do not mark as PR Available.