Replicated component deltas can cover off-render state

In some mode-specific observer contexts, a replicated arena component contains nested vehicle health and player-stat records even when a combatant has no rendered entity. This can fill a gap left by render-dependent vehicle hooks, but only after the current component registration, replication scope, nested setters, and mode availability are verified.

When attributing damage from two replicated streams, initialize baselines before consuming changes, pair only source-backed matching deltas inside a short window, require opposing teams, expire unmatched changes without guessing, and deduplicate against native rendered events. Equal deltas are evidence for the verified context; aggregate-health or nearest-event matching is inference and must not be silently substituted.

External requirements and interpolation

When a feature loads percentile requirements or thresholds from an external source, validate the shape before use.

  • Accept only numeric, positive values from recognized records.
  • Tolerate missing percentiles.
  • Sort points by percentile or requirement before interpolation.
  • Clamp the resulting display to the valid rating range.
  • Describe values below the first point and above the last point as estimates.
  • Do not replace official dossier averages with an independently reconstructed history.
def interpolate_rating(value, points):
    points = sorted((rating, requirement) for rating, requirement in points
                    if rating >= 0 and requirement > 0)
    if not points:
        return None
    # Edge extrapolation is still an estimate and should be labelled as such.
    for index in range(1, len(points)):
        left_rating, left_value = points[index - 1]
        right_rating, right_value = points[index]
        if value <= right_value:
            span = float(right_value - left_value) or 1.0
            ratio = (value - left_value) / span
            return max(0.0, min(100.0, left_rating + ratio * (right_rating - left_rating)))
    return min(100.0, points[-1][0])

Respawn and controlled-vehicle changes

Respawn modes split arena-owned and entity-owned state.

  • Preserve arena-wide deduplication and participant data.
  • Reset health, reload, attachment, and feedback state tied to the old entity.
  • Re-resolve the controlled vehicle and descriptor after the active vehicle changes.
  • Reject callbacks carrying the old vehicle ID or generation.
  • Remove obsolete remote-vehicle entries instead of accumulating one record per spawn.

Shared battle hooks

Battle feedback and result services are common hook targets. A wrapper should capture the method installed at patch time, call it exactly once, preserve the result, and restore only while the class slot still contains that wrapper.

Do not copy an entire decompiled event handler merely to read one value. Preserve unknown events and add the narrowest possible observation.

Single-file ledger pattern

_BATTLE = {
    'arena_id': None,
    'vehicle_generation': 0,
    'direct_damage': 0,
    'assist': {},
    'processed_result': False,
}


def begin_arena(arena_id):
    _BATTLE.update({
        'arena_id': arena_id,
        'vehicle_generation': 0,
        'direct_damage': 0,
        'assist': {},
        'processed_result': False,
    })


def replace_vehicle():
    _BATTLE['vehicle_generation'] += 1
    # Clear only entity-owned state here.

Verification matrix

  • Normal battle from lobby.
  • Direct reconnect into an active battle.
  • Death, spectator state, and postmortem UI.
  • Respawn or controlled-vehicle replacement.
  • Replay playback and repeated rewind.
  • Result received through more than one callback.
  • Missing dossier, late dossier, and empty early record.
  • External requirement service unavailable or malformed.
  • Account or season change while a session baseline exists.

Battle data correctness matrix

Do not ask only where a number can be read. Ask which owner is responsible for that number at this moment.

Source Good for Bad for Timing
Arena roster Participants, teams, vehicle IDs, setup metadata. Live combat totals. Around arena setup and updates.
Vehicle entity Current world state such as position, health, and replicated properties. Final result truth or long-term identity. Only while the entity exists and is loaded.
Battle feedback Immediate combat events and UI reactions. Complete historical reconstruction. During battle delivery.
Battle controllers Processed live state owned by a subsystem. Raw authoritative data outside that subsystem. Depends on controller lifecycle.
Dossier cache Historical/account statistics and before-after comparison. Current battle truth. Can be stale or require a baseline.
Initial baseline Comparisons captured before a change. Live event details. Must be captured before the relevant mutation.
Replay data Recorded playback state. Live account services and real-time assumptions. Replay-specific and seek-sensitive.
Final battle result Final totals and settlement. Immediate in-battle UI response. Arrives late and may be delivered more than once.
GUI model What a specific view currently displays. Source-of-truth calculations. View-owned and derived.

Current state does not reconstruct event history

A recreated overlay can seed current state without establishing when it changed. An initialized partly used component, rebuilt health cache or refreshed postmortem display need not represent a new use, damage or death event. Presentation cleanup can also promote queued cues without new gameplay publication.

Keep a current-state projection separate from recorded observations. For each metric, retain owner identity, clock domain, snapshot/delta/transition shape and source authority. Check whether queries return borrowed mutable state or consume/advance state before polling them. Reconcile supported totals with final results without counting live and final contributions twice.

Final aggregates can repair totals but cannot recover absent chronology or invent a projectile identity missing from the contract. Preserve unknown values and inferred associations explicitly. This distinction applies equally to local telemetry, UI recovery and persistent analytics.