Realtime Bootstrap Manifest And Snapshot Service
The realtime bootstrap manifest is the first authoritative state bundle a client receives after session activation. It packages player stats, combat state, inventory, currencies, equipment, quest state, gameplay conditions, world-state buckets, combat events, and farming deltas into descriptor-backed sections with stable priorities and compression policy.
Purpose
Use this page when adding an activation snapshot, changing bootstrap ordering, debugging missing state after login or transfer, or deciding whether a new server snapshot belongs in the initial manifest or in normal AOI replication.
The bootstrap manifest is not a duplicate of continuous replication. It is the ordered activation baseline. AOI and later realtime packets keep the client fresh after the manifest has established the starting state.
Activation Inputs And State Owners
session_activation owns activation. It consumes a pending realtime session, loads the player projection, persists activation/resume state where needed, imports dungeon memory if applicable, writes presence, builds visible-player buckets, and passes the activated session to the stream bootstrap path.
The snapshot service and shared bootstrap assembler own packaging. Runtime state owners provide their snapshots; the bootstrap layer decides section presence, priority, envelope encoding, compression, and final manifest order.
Manifest Envelope Contract
RealtimeBootstrapManifestAssembler creates a single ServerBootstrapManifest packet. Each section is encoded through RealtimeBootstrapSectionDescriptor metadata. The descriptor maps section kind to packet encoder, default priority, presence rule, and reducer expectations.
The manifest carries a replay id. Clients use it to associate bootstrap sections with the activation/reconnect baseline rather than treating each section as an unrelated live update.
Bootstrap Sections And Presence Rules
Always-present sections include the core player and gameplay state needed to render and accept commands. Conditional sections, such as combat events or farming tile deltas, appear only when their input collections are non-empty.
Do not add ad hoc "empty section means absent" behavior. Put presence behavior in descriptor metadata and keep reducers compatible with both old clients and clients that receive the new section.
Priority And Compression
Critical and high-priority state must arrive before cosmetic or deferred data. World-state priority can be overridden by runtime profile settings. Compression is section-level: the compression strategy checks payload size and selected mode before wrapping the envelope.
If a section grows, adjust packet budgets, compression strategy, fixtures, and client reducer tests together.
Authoritative Inventory Session Mutation
Inventory, currency, and equipment snapshots are part of the bootstrap baseline, but authority remains on the server. The client may render and predict UI from these sections, yet durable mutations still go through gameplay authority, economy authority, equipment persistence, or combat reward persistence.
Failure Modes And Tests
If login succeeds but UI state is empty, inspect session activation output first, then the manifest section list. If only a section is missing, verify its presence rule and source snapshot. If all sections are absent, inspect activation and reliable stream bootstrap. If compression fails, compare negotiated runtime profile compression with the manifest section compression mode.