Reversing on the host turned the whole set around on the client, and the
locomotive ended up looking like something derailed making its way across the
scenery. Both come from the same place: a routine correction was calling
place_on_track(), which sets the axles from scratch and works from the
vehicle's own idea of which way it faces. That is right for a peer joining with
nothing to go on, and wrong for a train that is already running - the placement
reorients it.
A correction now slides the vehicle along the track it is already on, by the
difference between the two bogie offsets, which is the same operation the
physics performs on every step. When the two sides disagree about which piece
of track the vehicle is on, it is left alone until they agree; guessing there
is what put a locomotive beside the rails. place_on_track() is kept for the one
case it suits, a peer joining the session.
Also:
- taking a seat works with the game paused. The whole thing sat inside the
"has any time passed" branch, so with the world stopped the lobby button
changed the roster and nothing else happened
- the debug panel gets a Network section, shown only in a session: role, peer,
tick, bytes and messages each way with a running rate, two charts of kB/s so
the cost of a session can be read off, how far the worst vehicle is out of
place, and whether the state digest agrees. The separate "network" overlay
window is gone - everything it said lives there now, together with the lobby
and refusal messages that had nowhere to be seen
Until now the server ran the physics of everything and a client re-ran it from
the server's frame times, corrected a few times a second. That is the worst of
both: the client's own train never moved smoothly, its controls answered a
round trip late, and the two copies still sat metres apart between corrections.
Simulation authority now follows the train:
- the first person aboard a train runs its physics on their own machine, and
what they produce is what the rest of the session is told about it. A train
with nobody in it belongs to the host. Every peer works the owner out the
same way, from the crew of its lowest numbered car, so nobody has to be told
- a peer never applies corrections to a train it runs itself. Its own physics
is the authority on it, and overwriting that is precisely what made the
owner's ride stutter
- a client publishes the state of its own trains upstream, ten times a second.
The server takes it, filtered so a peer can only move the trains it is
entitled to move, and passes it on to everybody else in its own stream
- so the picture is: your train is smooth for you and may stutter for the
others; their trains may stutter for you and are smooth for them
Two things follow from it:
- commands for the train you run take effect the moment you press the key
instead of after a trip to the server and back. They are still sent, so
everybody else sees them, and the echo is dropped when it returns
- the client no longer replays the server's frame times out of a jitter buffer.
It runs on its own clock, like the host does, and simply carries out the
commands as they arrive. Playing back somebody else's frame times meant the
world ran at the wrong speed whenever the two machines drew at different
rates, and every buffered frame sat between the player and their controls
Also: the server only sends a frame when it has commands in it, or every tenth
one to carry the tick, instead of one per rendered frame.
First live test showed three things wrong at once.
A client could not take a vehicle. Walking up to a locomotive and pressing the
enter-vehicle key posts entervehicle, which stage 4 classed as a world-wide
command and refused outright ("reserved for the session host"), so the client
never got a cab and every later control command died locally for want of one.
Walking into a cab is a request for a seat, not a world command: the authority
now turns it into a crew claim, for the host through the same path as for a
remote peer, and answers it the way the lobby button is answered.
Nothing but commands was ever replicated. The server sent dt and the commands
it ran, and the client simulated the rest for itself - so a pantograph the host
raised before the client joined, the contents of the memory cells the signalling
reads, brake pressures and switch positions simply never crossed the wire. The
server now streams the authoritative state a few times a second: whatever has
changed since the last one, and the whole of it every so often so a peer heals
from anything it missed. The snapshot carries the vehicle's inputs - line
breaker, battery, converter and compressor permits, pantograph valves, cab,
lights, doors - and lets the receiving peer derive the rest, plus the memory
cells and the switches.
Desync detection demanded that two state digests be equal, on a design where
the client deliberately runs its own physics. They never can be, so it reported
a desync permanently and asked for a resync every five seconds forever, which
fixed nothing because the next step disagreed again. The digest is a log line
now; what is measured instead is how far out of place the routine correction
found us, and a full resync is only asked for when even that is not catching up.
Also: a consist is put back on the rails as a whole or not at all. Correcting
one vehicle while its neighbour stayed put is what was stretching couplers
until they tore - the last test moved six vehicles out of eight, every time.
And the lobby window collapsed to nothing, because its size_max was left at the
-1 default while size_min was set, so imgui was handed a maximum smaller than
the minimum.
The protocol hung off whatever frame the renderer happened to be drawing, and
the only thing standing in for synchronisation was the sum of every vehicle's
coordinates with a random number added on top - a value that cannot be equal on
two machines and therefore reported a desync on every single step.
- Global.simulation_tick: the authority counts the steps, a client takes the
number from the authoritative frame it is executing. FRAME_INFO and the
command requests carry it, so the network timeline has one unambiguous order
independent of frame rates
- network/statehash: a versioned FNV digest of the gameplay critical state -
vehicle position, speed, direction, brake pipe and cylinder pressure, plus the
clock. Values are quantized so that float noise is not mistaken for drift, and
vehicles are folded in under their own identity and summed, so the digest does
not depend on the order the scenario created them in. Switches, memcells and
the event queue are the next candidates; they go in when stage 7 pins down
what a snapshot contains
- a client compares its own digest against the authoritative one and reports the
drift when it starts and then only now and then, rather than every step; the
overlay says how long it has been out of step and at which tick
- refusing to compare at all when the two builds disagree on the digest layout
EU07_NETWORK_VERSION is now 4.
TTrain::id() numbers cabs with a local counter, in the order each peer happens
to create them, so it cannot address a vehicle across the session. Neither was
there any way for a player to see what is available to drive.
- network/entities: PeerId (the host is peer 1, remote peers are numbered from
2, so it is a participant rather than a special case) and NetworkEntityId,
plus a registry that numbers the drivable vehicles of the loaded scenario in
name order and resolves ids back to TDynamicObject
- the server owns the numbering and publishes it as VEHICLE_LIST - name, crew
occupancy, crew capacity, AI state, availability - on every change and at
least every 120 frames, out of band so it stays out of the replay backbuffer;
a client binds the received ids to its own copy of the scenario by name
- SERVER_HELLO hands the joining peer its PeerId
- a multiplayer lobby listing that roster, with vehicles taken by other players
shown as such rather than hidden; entering one goes through the existing
entervehicle command, the vehicle is never moved
The lobby lives inside the driver mode instead of a mode of its own: the world
has to keep running while somebody is choosing (a client stops consuming the
server's frames the moment its mode is not a command processor), and the same
screen is what a player needs to change vehicles later on.
Crew occupancy is still derived from the presence of a cab instance; the real
crew model, claim handshake and AI takeover follow in stage 3.
