ILoadout.LiveStateChanged event

Raised on the game tick AFTER the framework re-read the local player’s LIVE build state and the re-read actually CHANGED what this service serves — equipped gear/module slots, class, talent stage/nodes, the equipped Battle Imagine pair, or the Deep-Slumber Psychoscope state (GetState). An identical re-read raises nothing.

ONE event for the whole build. Deep-Slumber joined this event 2026-08-23 (owner staging run sea/dXkw1PSyOG: a psychoscope factor was unequipped between two archives and re-equipped after; the framework re-read it correctly but told nobody, so the consumer kept one stale snapshot for two materially different builds). Subscribers therefore never need a second subscription — or a poll — to notice a psychoscope edit; re-read whatever build surfaces they snapshot, IDeepSlumber included, whenever this fires. Both compares are STRUCTURAL and order-insensitive, and a not-yet-read surface is treated as no-signal (it never raises on its own).

Why this and not SelfGearChanged: that event fires on the network thread the instant a container delta ARRIVES, which is BEFORE the framework has re-read the game’s live containers — a consumer that snapshots the build from that handler’s tick races the refresh and records the PRE-change setup. This event is the post-parse counterpart: by the time it fires, GetSlots, LiveState and Installed already describe the new setup, so a consumer can flag here and snapshot on its next update tick.

That promise is structural, not incidental (2026-08-23). The framework re-reads the live slot→item line and RESOLVES those items into served gear/modules in two separate steps; the event is published from the SECOND one, so it can never fire while GetSlots still describes the previous setup. If the resolve cannot complete (item container not synced yet), the change is held and delivered on the tick the data lands — LATE, never STALE. A consumer may therefore treat this event as “the setup I can read right now is the new one”.

Threading: raised on the game Update thread (unlike SelfGearChanged), so a handler may read game-backed services directly. Keep handlers short — this runs inside the framework service tick.

public event Action? LiveStateChanged;

ILoadout.LiveStateChanged event

See Also