Battle information reaches the client through several layers. Correct mods choose one source of truth for each metric, preserve the right baseline, and treat live projections differently from final server results.

Source layers

Raw avatar events, adaptors, summaries, entity state, dossiers, and final results answer different questions.

Baselines

Vehicle, season, account, arena, and session baselines have different lifetimes.

Estimates

Interpolation and live projection must remain visibly distinct from server values.

See also: Battle & Arena for lifecycle stages, State & IDs for identity domains, and Client Requests & State Synchronization for authority and stale responses.

Battle data source layers

Layer Best used for Limitations
Raw avatar events Immediate low-level events tied to the current avatar. May be noisy, version-sensitive, or require reconciliation.
Battle feedback adaptor Processed combat events and summaries. Several mods may share the hook; event coverage differs by mode.
Health and entity updates Current visible entity state. Entity IDs can change on respawn and do not represent final results.
Arena roster and records Participant identity, team, vehicle metadata, and arena scope. Not all live combat state belongs here.
Dossier and account caches Persisted account statistics and vehicle baselines. May be unavailable or temporarily empty during rapid battle entry.
Final battle results Authoritative final values, including data unavailable live. Arrive later and use a separate schema.

Pick one authoritative layer per metric. Use another layer only as a projection, readiness fallback, or reconciliation source, and document that relationship explicitly.

Identifier domains

Names such as “vehicle ID” are dangerously ambiguous. Use variable names that include the domain.

  • arenaUniqueID: persistent key for one battle and the safest basis for deduplicating exports, messages, and post-battle work.
  • vehicleID: one arena entity; it may change when the player respawns or controls another vehicle.
  • Vehicle type compact descriptor: stable vehicle-type identity suitable for persistent per-tank data.
  • Inventory ID: the owned lobby item instance used for selection and inventory actions.
  • Account database ID: server-side account identity, subject to the exact connection/periphery model.

Never use a list index, row position, or presentation order as a stable identity.

Read by topic

Choose a focused chapter. Complete examples and reference details are preserved on their topic pages.