Ownership describes which subsystem is responsible for a piece of state. The owner determines when the state is meaningful, which events can update it, and which transitions invalidate it.
Ownership table
| Owner | Owns | Invalidated by | Typical mistake |
|---|---|---|---|
| Process-owned | Module globals, installed monkey patches, long-lived diagnostics, process-wide caches. | Client shutdown, mod unload, explicit fini(). |
Letting process state silently outlive account, battle, or view state. |
| Login/session-owned | Authenticated account session, realm-dependent availability, session-scoped services. | Logout, disconnect, account switch, realm change. | Assuming a service resolved in one session is valid after reconnect. |
| Account-owned | Inventory, selected vehicle, account attributes, missions, notifications, cache-backed lobby data. | Disconnect, account switch, cache resync, client shutdown. | Reading it during import or battle-only context. |
| Lobby/hangar-owned | Hangar route state, selected vehicle presentation, lobby panels, hangar scene controllers. | Battle entry, route change, hangar reload, logout. | Using hangar-only owners while the avatar or battle page is active. |
| Avatar-owned | Battle player object, arena access, battle controllers, player battle context. | Battle exit, replay close, disconnect, avatar replacement. | Keeping avatar references after returning to the lobby. |
| Arena-owned | Arena period, roster, vehicle IDs, participant records, arena settings. | Battle end, reconnect, replay seek, arena replacement. | Assuming arena creation means all entities exist. |
| Entity-owned | Live world objects, position, health, replicated entity properties. | Entity destruction, unload, respawn, replay seek. | Using an entity object as a stable identifier. |
| Controller-owned | Mode, feature, request, or UI controller state resolved through a service or package owner. | Controller destruction, package unload, mode switch, owner context replacement. | Caching a controller without checking whether its feature is still active. |
| Service-owned | Controller and repository state exposed through dependency interfaces. | Service shutdown, optional package unload, context changes. | Resolving a service during import and caching it forever. |
| Callback-owned | Delayed work scheduled through callback handles and the state captured for that future execution. | Callback execution, cancellation, owner generation change, teardown. | Scheduling retries without storing the handle or rejecting stale generations. |
| View-owned | Window objects, models, DOM, layout, visibility, local UI state. | Close, route change, context transition, reload. | Updating a model after the view was destroyed. |
| Gameface app/window/model-owned | Browser app readiness, Wulf window surface, Gameface DOM, generated or handwritten model state. | Window close, route reload, browser reload, model disposal, replay rewind. | Updating DOM or model state after only the Python side appears ready. |
| Scaleform application/view-owned | DAAPI application state, view aliases, Flash objects, Scaleform components. | Application shutdown, alias destruction, route change, battle/replay recovery. | Destroying only the top-level alias while retaining child callbacks or flags. |
| Route-owned | Which lobby, hangar, battle, or overlay surface is active. | Navigation, loading screens, battle/lobby transition. | Showing UI on unsupported routes. |
| Cache-owned | Synchronized account or configuration data. | Resync, invalidation event, account switch. | Treating absence during sync as final absence. |
| Replay-owned | Playback state, recorded entities, time-warped arena state. | Seek, pause/resume, replay close. | Assuming live battle services and timings apply. |
Match the owner to the question
Do not automatically choose the deepest value or the highest abstraction. Choose the owner that is responsible for the fact you need. Use entities for current world state, arena records for battle participation, cache owners for synchronized account data, and GUI models only for presentation state.
Ownership logging
Diagnostics are more useful when they log the owner and lifecycle context together. Include account/avatar type, arena ID where relevant, route or view alias for UI issues, and whether the client is in live battle or replay mode.