eu07/maszyna
17
0
Fork 0
mirror of https://github.com/MaSzyna-EU07/maszyna.git synced 2026-10-18 18:29:40 +02:00
Code Issues 151 Wiki Activity

multiplayer: a cab belongs to the peer it is on, and the first one aboard drives

Browse Source 
Joining a crew did nothing. The cab was being built by a replicated entervehicle
that the authority posted only when it had no cab of its own - which is exactly
the case that never happens for the second person to board. The host claims a
vehicle, the server builds a cab, and from then on every further claim finds one
already standing over there, posts nothing, and the joining peer waits forever
for a command that is not coming.

A cab is not a shared object. Each participant has their own, with their own
camera and their own view of it, and nothing about it needs to travel. So it is
built locally by whoever needs one: the driver mode does it for the player when
their claim is granted, and the authority does it for itself, because it needs a
cab to address the AI handover commands to. That also stops a cab being created
on every peer for every claimed vehicle, which is what the entervehicle
broadcast was doing.

Who runs a shared train is no longer decided by car numbering. It is whoever
boarded first, and it stays with them: every crew member is stamped with a
session-wide counter when they sit down, and the smallest stamp on the whole
consist owns the physics. Coupling, uncoupling and renumbering do not move it,
and neither does somebody else joining - each handover is a stutter in the ride
of the person who has been driving, and they are the one who would notice it.
The stamps travel with CREW_UPDATE and in the snapshot, because a client works
out ownership for itself and has to arrive at the same answer.

Chat: the key that opens it is now read before imgui gets a look at the input.
Any window holding the keyboard - the lobby, most likely, which is precisely
where a client sits - would swallow it, so on that side the panel could not be
opened at all. The exception is text actually being typed, which is the chat box
itself; escape closes that. A client also logs what it says, so if a line goes
missing it is clear which half of the trip lost it.

Protocol version 6, snapshot version 7.
This commit is contained in:
Hirek
2026-09-07 16:00:41 +00:00
parent 0112d81b77
commit 1bfa1644c9
14 changed files with 168 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
application/application.cpp
View File

@@ -894,6 +894,17 @@ eu07_application::get_input_hint( user_command const Command ) const {
void eu07_application::on_key(int const Key, int const Scancode, int const Action, int const Mods)
{
// the session chat opens on the key left of 1, and it is checked before imgui gets a
// look at the input: a lobby or any other window that happens to have the keyboard
// would otherwise swallow the key and the chat could never be opened at all. the one
// case where imgui does get it is when something is already taking typed text - the
// chat box itself, most of the time, which closes on escape instead
if ((Key == GLFW_KEY_GRAVE_ACCENT) && (Action == GLFW_PRESS) && (Mods == 0) && !m_modestack.empty() && network::is_multiplayer() &&
!ui_layer::wants_keyboard())
{
if (m_modes[m_modestack.top()]->toggle_chat())
return;
}
if (ui_layer::key_callback(Key, Scancode, Action, Mods))
return;