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.
The renderer draws nothing at all while simulation::is_ready is false, and that
flag only goes up once the local player's cab is built.
The previous commit made walking into a cab a crew request, so the cab of a
claimed vehicle is created by Crews::reconcile() rather than by the command
itself. reconcile() runs from the network housekeeping, which was gated on
simulation::is_ready - so a host started with -v had its entervehicle turned
into a claim, and then the cab waited for is_ready while is_ready waited for
the cab. Black screen on both ends, since a client whose server never gets
going has nothing to show either.
- the housekeeping now waits for Global.simulation_loaded, which says the world
exists, instead of simulation::is_ready, which says the player has a cab
- in a session, a player with no cab counts as ready: they are an observer in
the lobby, not a game still loading, and the world has to be drawn for them
- entervehicle is only taken as a crew request when the session actually lists
that vehicle; anything else stays an ordinary command, so a scenario that
starts its host in something the roster does not cover still works
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.
Two things were still missing once a session ran for a while: a peer that had
drifted apart from the authority had no way back short of restarting, and a
connection that blinked cost the player their seat and handed their vehicle to
the AI while the other driver was still sitting in it.
- a client that disagrees with the authoritative digest for 120 steps in a row
asks to be put back in line, and the server answers with a fresh snapshot.
There is a cooldown between requests, so a correction that needs a moment to
take hold does not turn into a stream of them
- the server hands out a session token with its hello and remembers it. Present
it again on the next connection and you come back as the same peer, with the
same id
- a lost connection no longer removes the peer from its crews: the seat is held
for a minute. Come back in time and nothing changed; stay away and the seat
is given up properly, handing the vehicle back to the AI only when that
leaves the crew empty and the AI was driving it in the first place
- after applying a snapshot a peer that finds itself on a crew walks into that
cab, which is what makes a reconnect land the player back where they were
- the vehicle roster is sent to a joining peer right before its snapshot, so
the crew section resolves to names instead of waiting for the next broadcast
Joining meant replaying backbuffer.bin from the very first frame of the
session, so the longer a session ran, the longer it took to get in - and the
whole history had to be kept for it.
- network/snapshot: a chunked container with a version of its own. Every
section carries its length, so a peer built before a section existed reads
a newer snapshot and simply walks past what it does not know. Version 1
carries the session (tick, clock, weather, the state of the random engine),
the vehicles (position on the track, speed, direction, controls, brake
pressures, whether the AI is driving) and the crew roster. Switches,
memcells, signals and the event queue are the next sections
- joining is now: handshake -> load the scenario -> CLIENT_READY -> the server
takes a snapshot on the spot and sends it -> the peer goes live. Because the
snapshot is taken at the moment the peer becomes active there is no backlog
to replay at all; the frame by frame catch-up is gone
- the server refuses a peer that loaded a different scenario, with a readable
reason instead of a silent desync
- reconnecting into a session that is already loaded asks for a fresh snapshot
straight away rather than waiting for a loader that will not run again
- a vehicle is only put back on the rails when it really is somewhere else; the
arithmetic that turns the recorded bogie offset back into the nose distance
place_on_track() expects mirrors what that function itself does
- the session log is still written out - it is useful when picking a desync
apart - but nothing depends on replaying it any more
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.
A vehicle is not owned by one player: two people share a cab, so the session
needs a crew relation rather than an owner field. The server keeps it and is
the only one allowed to change it.
- network/session: vehicle_crew { entity_id, crew, ai_before_claim } and a
crew_registry holding the roster. the host goes through exactly the same
path as a remote peer (claim -> crew -> grant), only without transport
- CLAIM_VEHICLE / CLAIM_GRANTED / CLAIM_DENIED / LEAVE_VEHICLE / CREW_UPDATE;
the server validates the vehicle exists, is present in the scenario and has
room in the crew, and answers a refusal with a reason the lobby shows
- the cab of a claimed vehicle is created by the authority posting the
ordinary replicated entervehicle, so every peer builds it and the vehicle is
never moved. the claiming peer only walks in once the cab appears locally
- AI transitions follow the crew size: 0 -> 1 remembers whether an AI was
really driving and takes the vehicle over, 1 -> 2 and 2 -> 1 change nothing,
1 -> 0 hands the vehicle back but only if there was an AI driver to begin
with. driver mode no longer fires aidriverdisable of its own in multiplayer
- losing a connection removes that peer from every crew it was on; a vehicle
with somebody still on board carries on untouched
- the lobby lists who is on board, offers "join crew" for a vehicle another
player already occupies, and lets a player step off
The AI and cab handling runs as a reconciliation pass rather than as edge
triggered actions, so a request that has not taken effect yet (the cab needs a
frame to appear) is simply repeated, with a cooldown to keep it off the wire.
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.
