Three things that turn out to be one thing: a session with people in it needs
to be able to say who they are, and a machine that only referees one should not
have to open a window to do it.
Names. A peer id is what the protocol addresses; "player 4" is no use to anybody
reading a lobby. CLIENT_HELLO carries a requested nickname now, and the server
decides what it actually is: trimmed of control characters and runs of spaces,
capped at 24, and made unique - two people called Marcin are two people and the
lobby has to say which is which. The result goes out as PEER_ROSTER whenever
somebody joins or leaves, and to a joining peer just before its snapshot, so the
crew section resolves to names rather than numbers. The name comes from
multiplayer.nickname in the ini or --nick on the command line, falling back to
the account name and, failing that, to the old numbering. The host is a peer
like any other here too, and registers its own name at startup.
Chat, on the key left of 1. Going up a line carries only its text: who said it
is decided by the connection it arrived on, never by the field in the packet,
which is what stops anybody putting words in anybody's mouth. The server tidies
and caps it, says it, and passes it on - a client waits to hear itself back, so
that everybody sees the conversation in the same order. While the box has the
keyboard imgui swallows the input before the driver mode sees it, so typing "d"
types "d" instead of opening the doors of whatever you are driving; that also
means the key that opened the panel cannot close it, hence escape.
And --nogui. No glfw, no window, no imgui, the null renderer, sound off, log to
the console it was started from, and nobody in a cab - the scenario is left to
its own drivers and this process is a referee rather than a participant. Every
window-dependent path is guarded on an empty window list rather than on a flag
scattered through the code, and the loop is paced at fifty steps a second
because nothing is waiting on a swapchain to slow it down. Chat lines go to the
log, which is what a machine with no window has instead of a chat panel.
eu07.exe -s scenario.scn --host 0.0.0.0:7420 --nogui --nick Dispatcher
Two hardcoded constants decided how far a train could drift before it was put
back, and there was no way to change them short of a rebuild. They are settings
now:
multiplayer.sync.running 1.5 // margin while the train is rolling
multiplayer.sync.stop 0.2 // one precise correction once it stands
The split is what the two numbers are for. A moving train is left to its own
physics unless it is well out, because nudging it several times a second is
worse than the error; a standing one is worth getting right to the centimetre,
and it is done once and then left alone until it moves again - a consist that
has had its correction is marked settled, and clears that mark the moment it
rolls. Both travel in SERVER_HELLO: whatever a player has in their own ini, a
session runs to the host's margins, which is the only way the peers agree on
what "out of place" means.
And the trainsets. Every peer loads its own copy of the scenery - that is the
only reason joining takes seconds instead of minutes - but the copy on disk is
not the session: the host may have shunted a set apart, put one together, or be
running a scenery whose consists were edited since. So the composition travels
in a full snapshot, ahead of the positions: which coupler of which vehicle is
joined to which coupler of which other, and with what hoses and cables. A
joining peer breaks what should not be coupled, makes what should, and only
then gets told where everything is - so the per-consist repositioning works on
the session's trains rather than on the ones its own scenery file described.
The vehicles themselves do not travel, and cannot: a peer missing one gets a
line in the log saying so, not a model over the wire.
Uncoupling has to be forced here. TDynamicObject::Dettach() leaves the
mechanical coupler alone unless the buffers are pressed together, which is
right for a player pulling a lever and wrong for putting a peer's world in
order.
Protocol version 5, snapshot version 6.
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.
