From Round 22 usability feedback (block-kuzushi tester, self-scored 4/10, 12 wasted polling round trips).
With the Editor unfocused, Play Mode advanced ~0.37s of game time over more than a minute of wall clock (ball at 9 units/s moved 3.1 units across 12 polls). runInBackground=True was set, so this is Editor update throttling, not a game setting, and not a uloop bug — but the tester burned 12 execute-dynamic-code polls before realizing nothing was progressing. One uloop focus-window immediately unblocked progress.
Requested: include Time.frameCount / Time.time in state-reading responses (execute-dynamic-code, control-play-mode --action Status), and/or emit a hint when Play Mode is running while the Editor window is not focused ("progress may be throttled; use focus-window or the pause-point --await/--trigger flow").
Note: the pause-point --await/--trigger/--resume-play flow structurally avoids this problem and never hit it.
From Round 22 usability feedback (block-kuzushi tester, self-scored 4/10, 12 wasted polling round trips).
With the Editor unfocused, Play Mode advanced ~0.37s of game time over more than a minute of wall clock (ball at 9 units/s moved 3.1 units across 12 polls).
runInBackground=Truewas set, so this is Editor update throttling, not a game setting, and not a uloop bug — but the tester burned 12execute-dynamic-codepolls before realizing nothing was progressing. Oneuloop focus-windowimmediately unblocked progress.Requested: include
Time.frameCount/Time.timein state-reading responses (execute-dynamic-code,control-play-mode --action Status), and/or emit a hint when Play Mode is running while the Editor window is not focused ("progress may be throttled; use focus-window or the pause-point --await/--trigger flow").Note: the pause-point
--await/--trigger/--resume-playflow structurally avoids this problem and never hit it.