Optionaloptions: AnimationSystemOptionsExecution order key (§39); default PRIORITY_ANIMATION_TARGETS.
Whether AnimationSystem.dispose has run. Disposal is terminal
(§83): a disposed system refuses its mutating entry points with
INVALID_APPLICATION_STATE (§89) rather than silently working.
Tracked players, in the order they will be advanced.
Number of tracked players.
Stops advancing everything. The system stays registered.
Drops every tracked player (§39 teardown).
Deliberately does not stop them: the system is a driver, not an owner, and disposing an application should not reach into animations that the application may still be scrubbing or serializing.
Advances every tracked player by one fixed step, in insertion order, then drops the ones that can never advance again (see the class documentation).
The delta is time.fixedDeltaTime — the scaled simulation delta. The
scheduler has already applied timeScale when filling its accumulator
(§10: accumulator += elapsedRealTime * timeScale), so a fixed step is
one fixedDeltaTime of scaled simulation time and the number of steps per
frame is what timeScale changes. Multiplying by time.timeScale here
would scale the same time twice, and animation would run at timeScale².
Allocates nothing.
No per-registration setup is needed (§39).
Starts advancing item and returns it, so a player can be built, played,
and tracked in one expression. Idempotent — tracking twice keeps the
original position in the iteration order.
The player need not be playing yet: an "idle" tween is advanced (a no-op)
until something calls play() on it.
Advances every tracked animation player once per fixed step (§39 step 3).
Which players it advances (decision, WP-4.6)
Explicit registration, exactly as
MotionSystemtracks nodes: a player is advanced because AnimationSystem.track was called with it. A tween does not attach itself to a system — it has no way to know which system, or which application, should own it — soplay()starts a tween andtrack()makes something move it.Auto-untracking (decision, WP-4.6)
After advancing a player the system drops it if it is
finishedor"stopped", because those are precisely the states from whichadvancecan never do anything again:"running""paused"resume()revives it"idle"play()revives it"finished""stopped"Keeping a finished tween would cost a call per step forever and hold its target alive; dropping a paused or idle one would silently break the two legitimate ways of resuming. A finished player is not stopped by the system: it keeps its values and can still be scrubbed with
seek, and a caller that wants its §16 property claims released callsstop()itself.Mutation during a step
The tracked set is a
Setiterated live, mirroringMotionSystem(a snapshot would allocate every step). The consequences, which areSetsemantics: a player untracked during the step — including by the system's own auto-untracking, and by anonCompletecallback — is not advanced again in that step, and one tracked during the step is advanced in the same step. Track and untrack outside the step if that distinction matters.