Many subtle bugs come from using one identifier namespace as another. Name variables by identity and decide exactly how long each value remains valid.

Identifiers belong to different scopes

Choose the ID by asking what must survive

  • A setting for every instance of one tank type should use the vehicle type descriptor.
  • An action targeting the player's specific owned tank should use its inventory ID.
  • Temporary health or position data in one battle should use the live entity ID.
  • A result that must not be processed twice should use the arena's unique identity.
  • A button callback attached to one window should stay with that view instance only.

Common identity scopes

Identity Origin and scope Typical invalidation Do not confuse with
Account database ID DB_ID in account/avatar contracts; persistent account identity where the owning API exposes it Account change; availability can also change across login, lobby, battle, and replay contexts Avatar entity ID, contact-list index, or a display name
Arena unique ID ARENA_UNIQUE_ID; one battle/session identity used by arena and result contracts New arena; replay metadata may be available without live account context Arena type, arena bonus type, or battle mode tag
Avatar/player entity ID OBJECT_ID; the current player-controlled engine entity for that context Account/avatar replacement, disconnect, or entity destruction Account database ID
Vehicle entity ID OBJECT_ID; one live vehicle entity inside an arena and space Entity destruction, respawn, observer target change, or arena teardown Inventory vehicle ID or vehicle type compact descriptor
Vehicle type descriptor VEH_TYPE_CD; identifies a vehicle definition/type, not an owned instance Definition/catalog update Owned inventory vehicle ID
Inventory vehicle ID Lobby/items-cache identity for a particular owned vehicle instance Sale/removal, account change, or cache resynchronization Vehicle entity ID or compact descriptor
Team ID Arena roster relationship whose meaning is local to that battle contract New arena or mode-specific roster replacement Clan, platoon, prebattle, or account identity
View alias / route / instance Registration key, navigation destination, and concrete UI lifetime are three related but distinct identities Route change, view reload, browser recreation, or owner teardown Rendered DOM element ID or resource path
Resource identifier Virtual path, generated accessor, or framework resource key resolved by its owning loader Package/client update, native declaration or legacy resource-map change, or cache invalidation Physical archive filename or frontend route

Convert only at an owned boundary

Two integer fields are not convertible merely because both fit in Python's int or long. A valid conversion needs an owning mapping: an arena roster can relate a vehicle entity to participant data, the items cache can relate an owned vehicle to its compact descriptor, and a UI router can relate a route identifier to a view registration. Preserve both original IDs when the relationship may become stale.

  • Name variables by domain: account_db_id, vehicle_entity_id, inventory_vehicle_id, and vehicle_type_cd.
  • Record the arena, account, route, or generation that made a conversion valid.
  • Re-resolve after respawn, reconnect, cache synchronization, route replacement, or replay seek.
  • Reject a value whose domain is unknown; do not guess from magnitude or field name.

See also: Entity & Network Model, Arena Mode Identifiers, and Client Requests & State Synchronization.

Carry context through asynchronous work

request_context = {
    'account_id': current_account_id(),
    'arena_id': current_arena_id(),
    'vehicle_type_id': current_vehicle_type_id(),
    'generation': _context_token,
}

def apply_result(result, context):
    if context['generation'] != _context_token:
        return
    if context['account_id'] != current_account_id():
        return
    if context['arena_id'] != current_arena_id():
        return
    if context['vehicle_type_id'] != current_vehicle_type_id():
        return
    update_feature(result)

Battle data needs one source of truth

  • Live feedback is useful for responsive projections but can omit values only known in final results.
  • Summary packets may repeat cumulative values; keep monotonic totals or deduplicate by event identity.
  • Final results should update persistent progression when hidden or delayed values matter.
  • Respawn modes can require resetting entity state while preserving arena-level totals.
  • When combining categories, verify the game rule. Some metrics use the highest eligible assist category rather than their sum.

Stable keys beat presentation indexes

Save semantic identifiers such as a mode, preset, icon, or vehicle type. Derive dropdown indexes and list positions from the choices currently available.

Refresh on ownership changes

  • Cache synchronization and inventory updates
  • Selected vehicle or controlled entity changes
  • Arena and battle-period transitions
  • View reloads and route changes
  • Mode or seasonal controller activation changes

Mode identifier namespaces

Battle mode filters have their own ID families. Keep arenaGuiType, arenaBonusType, lobby queue types, and string mode tags separate, and use Arena Mode Identifiers when deciding which namespace answers your question.