v0.4.4: "Mid-run join" false positive crashes the client on a normal simultaneous NewGame start
Both players press Start at the same time (fresh NewGame, nobody is "joining mid-run" on purpose), yet the client always crashes. Reproduced 3 times, host/client roles swapped both ways (two different PCs, same result).
Timeline (host side, 22:56 session):
22:56:28 [RunLaunch] Host committed ... seed=277525 kind=dc.LaunchMode+NewGame
22:56:28 [RunLaunch] Host execute ... -> host enters the run immediately (local)
22:56:31 [RunLaunch] Client acknowledged session ... seq=2
22:56:32 [RunLaunch] Launch beacon complete seq=2: friend confirmed the launch
Client side:
22:56:30 [RunLaunch] Remote level ready role="Client" ... level=PrisonStart
22:56:30 [Session] Mid-run join detected (host already playing level=PrisonStart); a host-approved spawn will be applied
22:56:44 FTL Fatal Error: Null access .manualLock
at Haxe!libs.._dispose(libs/Process.hx:33)
Second crash variant with roles swapped (host = PC-A, client = PC-B):
22:58:03 [Session] Mid-run join detected (host already playing level=PrisonStart); a host-approved spawn will be applied
22:58:04 [RunLaunch] Client auto-started the authoritative run (titleScreen=true)
22:58:04 [NetMod] Failed to process level reload for PrisonStart: Uncaught hashlink exception.Null access .curCine
22:58:04 FTL Fatal Error
Root cause: the host always executes its NewGame locally a few seconds before the client can (client needs the network confirm + load), so on a normal simultaneous start the host is already "playing" when the client's launch lands — the new mid-run-join detection has no grace window and wrongly takes the SPAWNANCHOR path, which crashes the client (.manualLock in Process._dispose, or .curCine on level reload).
Suggestions: don't treat a join as mid-run within a grace window after host execution (e.g. host entered <10s ago), and/or have the host wait for the "Launch beacon complete" (client confirmed) before executing, so a normal simultaneous start never trips the mid-run path. This makes v0.4.4 effectively unable to start a co-op run at all, so it's high priority.
v0.4.4: "Mid-run join" false positive crashes the client on a normal simultaneous NewGame start
Both players press Start at the same time (fresh NewGame, nobody is "joining mid-run" on purpose), yet the client always crashes. Reproduced 3 times, host/client roles swapped both ways (two different PCs, same result).
Timeline (host side, 22:56 session):
Client side:
Second crash variant with roles swapped (host = PC-A, client = PC-B):
Root cause: the host always executes its NewGame locally a few seconds before the client can (client needs the network confirm + load), so on a normal simultaneous start the host is already "playing" when the client's launch lands — the new mid-run-join detection has no grace window and wrongly takes the SPAWNANCHOR path, which crashes the client (
.manualLockinProcess._dispose, or.curCineon level reload).Suggestions: don't treat a join as mid-run within a grace window after host execution (e.g. host entered <10s ago), and/or have the host wait for the "Launch beacon complete" (client confirmed) before executing, so a normal simultaneous start never trips the mid-run path. This makes v0.4.4 effectively unable to start a co-op run at all, so it's high priority.