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.
Every peer used to evaluate event conditions for itself and put the results
straight into its own queue, so the same event could fire twice, or on one
machine only. Worse, the launchers were polled around Global.pCamera, which in
a session means "wherever one particular player happens to be looking".
Condition evaluation is now separated from execution:
authority: evaluate -> queueevent -> execute -> replicate
client: receive queueevent -> execute
- AddToQuery() takes the origin of the request. A locally evaluated launch on a
client is dropped, on the host it is handed to the session as the ordinary
queueevent command and comes back to be carried out by everybody, itself
included, so it happens exactly once per peer. Scenario init (onstart,
negative delay) and the children of an already replicated event are marked as
authority decisions and run in place, since they are identical everywhere.
With no session running, both branches collapse to the old behaviour
- queueevent now carries the delay as well
- event launchers are polled around every crewed vehicle instead of around the
local camera, and a cell is polled at most once per frame no matter how many
players stand near it - launcher activation counters are stateful
- Events.update() still services the queue on a client, with its delays and its
execution; only the condition checking is skipped there
An event whose request is still travelling is not requested again, with a
timeout so that a lost request cannot silence it for good. Instant (AddValues)
events are exempt from that guard, because every one of their additions has to
get through.
Three things stood in the way of two people sharing a cab and of a client not
being able to reach past its own vehicle.
Vehicle commands were addressed by TTrain::id(), which every peer hands out
locally from its own counter, so the same number means a different vehicle on
a different peer. Commands now travel with the session wide NetworkEntityId
and are translated back to the local cab on arrival; outside of multiplayer
the registry is empty and both directions are a no-op, so singleplayer is
untouched.
A client could send any command it liked, including setweather, queueevent or
spawntrainset. The server now validates every incoming command: a player may
work the controls of the vehicle whose crew they are on and nothing else, and
world wide commands stay with the host until dispatcher roles exist. The
source is stamped by the server, never taken from what the peer sent, and
rejections are logged once per peer/command instead of every frame. Host input
runs through the very same validation, just without the transport.
Continuous commands were tracked per command and recipient only, so with two
people in one cab the release sent by one of them cancelled the other one's
hold. command_data now carries the source peer and the active set is keyed by
{source, recipient, command}.
Also: a client asking to quit no longer replicates quitsimulation, which would
have shut down everybody else's session.
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.
Networking used to be reachable only through the eu07.ini network.server /
network.client entries, and init_modes() refused to start at all unless a
scenery file was already known. That made it impossible to join a session
without knowing (and typing) the host's scenario up front, even though
SERVER_HELLO already carries the scenario name.
- add --host [address:port] and --connect address:port to the command line
(default port 7420, --host defaults to 0.0.0.0), plus --scenario/--vehicle
aliases and -h/--help; the existing ini settings keep working
- drop the init_modes() restriction: a client goes straight to the scenario
loader and waits there for the handshake, a host without -s still gets the
launcher and simply refuses joins until a scenario is up
- the loader screen reports the network state instead of sitting on a blank
progress bar
- a client that did not ask for a vehicle with -v starts as an observer
rather than failing to find the default EU07-424; the lobby of stage 2 will
take over the choice
- handshake carries build identification and the server answers an
impossible join with SERVER_REJECT and a readable reason instead of
dropping the socket silently; protocol version bumped to 3
- deserialize_message() no longer dereferences a null message on an unknown
message type
Three additions, all driven from the simulator debug panel.
DEVICE_LOG lets a controller send text lines; they reach the simulator log
and a per connection view in the panel which keeps the last 64 of them.
Diagnostic routines: a controller lists the procedures it offers, the
operator picks one from a drop down and starts it, and the controller
reports progress and the result. While a routine runs the controller can
ask the simulator to show a message box with its own text and buttons and
gets back which one was pressed, which is what a valve or gauge
calibration needs. The message box appears whether the debug panel is
open or not.
Links can now be disconnected and reconnected by hand: disconnecting
closes the serial port so the controller can be reprogrammed, and the
session is rebuilt from scratch on reconnect. Ports which appear while
the simulation runs can be picked from a refreshed list, given a baud
rate and added as a new controller, so the manager now starts even with
no uart2 entries in eu07.ini.
The zmq interface kept its own copy of the state field list, its own name
table and its own packer. All three are now the shared registry, which
resolves the same channel names and returns the same values, so the wire
format is unchanged. New state exposed to external interfaces is added in
one place from now on.
The registry reports the raw velocity rather than zeroing it while the
simulation is paused, and a symbol which doesn't apply to the current
vehicle keeps its measurement and says so through its quality flag.
The snapshot sent right after SUBSCRIBE was taken from the previous
frame, which on the first frame of a session meant every value came back
as UNAVAILABLE. The link now publishes the state of the current frame
before the received frames are processed.
Adds the WITH_HARDWARE_PROTOCOL_V2 build option and the eu07.ini entries
which configure it: uart2 declares a serial link and may be repeated for
several controllers, the remaining uart2* entries tune frame size,
heartbeat, rate limits and logging. UART v1 is untouched and both may be
active at the same time on different ports.
The driver mode starts the manager when at least one link is configured
and pumps it from the input polling loop, and the debug panel gains a
Hardware Protocol v2 section reporting link and session condition,
packet rates, round trip time, protocol and transport error counters and
whatever diagnostics the device itself reports, with switches for
protocol and frame logging.
Adds the logical protocol layer on top of the frame codec: session
handshake with negotiated frame size, session scoped symbol handles,
state subscriptions with periodic, on change and deadband filtering,
command events with duplicate protection and continuous controls with
stale update rejection, plus per connection rate limits and diagnostics.
A single worker thread owns all of the blocking transport work and
exchanges finished frames with the simulation thread through short locked
queues, so a stalled, flooding or unplugged controller cannot hold up the
simulation.
Adds the transport-independent core of the MaSzyna Hardware Protocol v2:
COBS framing with a CRC32C protected 24 byte header, bounds checked
payload readers and writers, and a resynchronising stream decoder.
The shared TrainState registry describes simulator state in engineering
units with per-value quality, the command registry generates the command
namespace from Commands_descriptions, and the symbol registry merges both
into the public, name-addressed hardware api.
make_event() lowercased the event name twice: cParser::getToken() already
folds ASCII via toLowerChar() (which intentionally leaves bytes >= 0x80
alone), then ToLower() ran std::tolower() over every byte on top of that.
With a non-"C" global locale, that second pass remaps cp1250 uppercase
accented letters (e.g. 0xAF -> 0xBF). Every lookup path - TTrack::AssignEvents(),
child-event resolution in multi_event, event-launcher name resolution -
normalizes only through the parser, so a registered name containing such a
letter can no longer be found: the track logs "can't find assigned event"
and the binding is silently dropped.
Removing the extra ToLower() makes the registration key match every lookup
site (ASCII-only folding, non-ASCII bytes compared verbatim), and matches
the direction toLowerChar()'s own comment already points at for UTF-8.
A whois with no triggering vehicle previously just wrote nothing to
the target cell with no trace in the log, which is a real pain to
diagnose from the scenery side (this is exactly the kind of thing that
cost real debugging time on a station script recently).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
whois_event::run_() dereferenced m_activator unconditionally in every
branch (this predates this PR). getvalues_event::run_() and
putvalues_event::run_() already guard the same way elsewhere in this
file; whois_event was missing it. Single early return covers every
branch, old and new.
The +8/+16/+24/+32/+40 (and the new +48) modes all pick the reporting
vehicle the same way: the activator's own Mechanik if it's the primary
driver, otherwise the consist's controlling vehicle (ctOwner) - so the
event still resolves correctly if a wagon happens to trigger it ahead
of its locomotive.
+0 (train name / stations left / stop flag) predates that pattern and
never got it: it required m_activator->Mechanik directly and silently
wrote nothing otherwise. A whois hook placed where the loco doesn't
necessarily lead (e.g. a train that reverses direction, or one being
propelled) can have a wagon trigger the event first and the memcell
stays empty, with no error - hard to diagnose from scenery side.
Same owner-selection, same guard semantics (still nothing written if
neither the activator nor its consist has a controller), only the
source of the vehicle it reads from is widened.
When the Autorewident function is enabled, the EP fuse switch will no longer automatically engage or disengage if the player is controlling the train. This would happen for example when approaching a station.
