Explore Game Behavior & Mechanics for explanations of vehicle stats, reload cycles, visibility, mode rules, progression and replay behavior, with links to the supporting game files.

A map of the major client systems a mod can observe or extend. Use these pages to answer three questions before writing code: who owns the state, when is it ready, and which identifier remains valid?

How to use this section

Start with Client Architecture, then read the page for the system your feature touches. Exact private names can change; ownership and lifecycle boundaries are the durable part.

System map

Vehicles & Items

Separate configuration, inventory, roster, entity, and result representations.

Battle & Arena

Follow periods, participants, live entities, and final results.

Account & Lobby

Work safely with synchronization, inventory, hangar, and prebattle state.

GUI Frameworks

Identify which UI generation owns a screen before modifying it.

Spatial Coordinates & ProjectionKeep world, arena, minimap, camera, and UI spaces separate.

Universal questions

  1. Purpose: what does the system own, and what does it merely display?
  2. Lifecycle: which event proves readiness, and which transition ends the context?
  3. Identity: is the key an account, arena, vehicle type, vehicle entity, item, or view instance?
  4. Authority: is the value local presentation state or server-authoritative state?
  5. Delivery: does change arrive through an event, replicated property, cache sync, controller, or view model?
  6. Cleanup: which owner removes listeners, callbacks, windows, hooks, and temporary state?

Representation chain

The same gameplay concept often appears as several unrelated objects. Convert deliberately instead of passing whichever object is convenient.

Representation Typical owner Useful for
Configuration descriptor Static game data Nation, class, tier, modules and tags
Inventory item Account and items cache Ownership, equipment, progression and selection
Arena record Current arena Participant metadata and vehicle identifiers
Live entity Battle space Position, health, appearance and world state
View model row Current UI view Rendered and interaction-ready presentation data
Battle result record Result payload Final server-confirmed outcome and statistics

Single-file discipline

System knowledge does not require feature folders. Keep one module-level state object, one initialization path, and small helpers grouped by system responsibility.

_state = {
    'account_id': None,
    'arena_id': None,
    'callbacks': set(),
    'subscriptions': [],
}

def _enter_account(account_id):
    _state['account_id'] = account_id

def _enter_arena(arena_id):
    _state['arena_id'] = arena_id

def _leave_arena():
    _cancel_arena_callbacks()
    _state['arena_id'] = None

def fini():
    _leave_arena()
    _unsubscribe_all()
    _state['account_id'] = None

Detailed system guides

Dossier & Baseline Validity

Validated vehicle history, empty-cache handling, reconnects, and final reconciliation.

Graphics, hangar, display, and chat systems

These system guides cover cross-cutting areas that many mods touch indirectly:

  • Graphics & Display State explains renderer settings, resolution changes, space readiness, world drawing, and visibility-mask ownership.
  • Hangar & Garage Runtime explains hangar-space and selected-vehicle readiness, native scene groups, routes, cameras, CGF systems, replacement spaces, cleanup, and diagnostics.
  • Messenger & Chat explains lobby/battle chat layers, channel readiness, outgoing message boundaries, and display and diagnostic behavior.

Deeper system contracts

Follow Battle State, Components and Feedback for health, crew, observations and timers; Vehicle Calculation Contracts for setup authority, copying and units; Battle Results and Accounting for revisions and aggregate records; and Native Async Lifetimes for continuations, scopes and cancellation. These references explain ownership and evidence limits alongside the API names.