[saltyeg]

What

An iterative OpMode's init() may now wait under forTeamClass. A Thread.sleep (or TimeUnit.sleep, SystemClock.sleep) there holds init() for ceil(ms / tick) ticks of sim time, so Thread.sleep(500) takes exactly 25 ticks of 20 ms. Before, any wait in an iterative OpMode was refused and failed the run. Waits in init_loop(), start(), loop() and stop() are still refused, and so are waits on threads the OpMode starts.

No public API changes. Only the SimClockScheduler javadoc changed, to describe the new case. This is a behaviour change: code that used to fail the run with a refusal now runs.

Why

The SDK lets init() block: OpMode.internalRunOpMode() calls it on the OpMode's own thread and starts init_loop() only once it returns. Libraries rely on that. Pedro Pathing's Pinpoint localizer sleeps 500 ms in its constructor while the device calibrates, and teams build the follower in init(). Such an OpMode works on the robot but could not run in SimLoop.

While init() waits, the sim matches the SDK:

• Sim time moves, and devices and plants keep updating, so a motor started in init() keeps turning. No other OpMode method runs.
• init_loop() starts on the tick after init() returns.
• If PLAY came during the wait, init_loop() is skipped and start() and the first loop() run on the tick after init() returns.
• If STOP came during the wait, the wait returns normally, not interrupted, because the SDK does not interrupt an iterative OpMode at STOP. Sim time ends at STOP, so the rest of the wait takes none. Then init() finishes, start() runs if PLAY had come, and stop() runs.
• Gamepads and time are not updated during the wait, as the SDK updates them only before a call. getRuntime() follows the sim clock, including across a resetRuntime() made just before the wait.

How I tested it

• New IterativeInitWaitTest (9 tests) pins each rule above. It covers the wait length and the tick init_loop() starts on, PLAY and STOP during the wait, a Pedro-style localizer that sleeps in its constructor (with SimClockLoader.PEDRO_PATHING in the team packages), the same telemetry on two runs, getRuntime() after resetRuntime() and then a sleep, and refusals in init_loop() and on a helper thread started in init().

• ./gradlew test, ./gradlew :SimLoop:docsSite and bash tools/leak-gate/leak-gate.sh all pass.

• ./gradlew test passes on my machine

• New or changed behaviour has a test

• If I touched docs or public javadoc: ./gradlew :SimLoop:docsSite passes

Checklist

• No robot-specific or season-specific code (SimLoop stays season-agnostic)
• Every new number says its unit, and its frame if it is a pose
• Any public API change is called out above
• If an AI agent wrote some of this, a human has read the change and run the tests

[saltyeg]

Needed because we build PinpointLocalizer in init() which sleeps 500ms