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
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.
