ReconciliationSystem.hpp File Reference

Replay client-stored inputs to recover prediction after a server snapshot apply. More...

#include "InputRingBuffer.hpp"
#include "ecs/components/InputSnapshot.hpp"
#include "ecs/components/LocalPlayer.hpp"
#include "ecs/physics/SweptCollision.hpp"
#include "ecs/registry/Registry.hpp"
#include "ecs/systems/CollisionSystem.hpp"
#include "ecs/systems/MovementSystem.hpp"
#include "systems/PredictionSystem.hpp"
#include <SDL3/SDL_log.h>
#include <cstdint>
#include <entt/entt.hpp>

Include dependency graph for ReconciliationSystem.hpp:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Namespaces
namespace	systems
	Client-only input sampling system — split into two halves so mouse look can run every iterate() (smooth camera at any FPS) while movement keys run once per physics tick group (server-consistent).

Functions
void	systems::runReconciliation (Registry &registry, const InputRingBuffer &ring, uint32_t ackedTick, uint32_t currentTick, float dt, const physics::WorldGeometry &world)
	Replay stored inputs from ackedTick + 1 through currentTick on the local player, restoring its predicted state after a snapshot apply rewrote it to the server-authoritative value.

Detailed Description

Replay client-stored inputs to recover prediction after a server snapshot apply.

Phase 5b: when an UPDATE_REGISTRY snapshot arrives, the local player's Position/Velocity/PlayerVisState/etc. get rewritten from the server's authoritative values. Those values represent the state at some past client tick T (the most-recently-server-acked input tick), not the current client predict tick. To get back to "where the client thinks we should be right now" we replay every input the client stored after T using the same MovementSystem + CollisionSystem the server runs — yielding a state consistent with the current input, just with any server-side correction (knockback, hit-stop, etc.) folded in along the way.

We always replay (no "compare-and-skip" fast path). The cost is ~RTT-in-ticks of runMovement calls per snapshot apply. At 50 ms RTT and 128 Hz physics that's ~6 ticks of work, and runMovement for just the local player on the client is microseconds. Cheap.

Note

PlayerSimState is not replicated (server-only by design), so the replay's starting PlayerSimState is whatever the client had accumulated locally. This means subtle timer fields (coyote time, jump cooldown, slide fatigue) can drift slightly between client and server. Position/velocity stay correct via reconciliation; the drift only matters for "feel" cases like edge-of-coyote-window jumps. Phase 4b's owner-only stream would replicate PlayerSimState to the local player and fix this.