Mob sync breaks on large levels (registry_mismatch -> missing_sync_id); reconnect cannot resume current run

[luan-a2]

Environment

• Dead Cells: v35 (2026-05-19 build, non-Steam/Goldberg)
• DCCM core: 35.12.8
• Mod: DeadCellsMultiplayerMod 0.8.91 (release v0.4.3, commit 52f383d)
• Network: LAN + VPN-like tunnel (Hamachi-like tunnel), TCP 1234
• Two players, one host / one client

Bug 1 (main): mob sync breaks on large levels — registry_mismatch → missing_sync_id flood

On the client side, right after entering a large level (SewerShort, 140 tracked mobs) the log floods with paired stale-mapping warnings:

[18:19:00 WRN] [MobSync] stale tracked sync mapping syncId=44 localIndex=142 reason=registry_mismatch:45
[18:19:00 WRN] [MobSync] stale tracked sync mapping syncId=45 localIndex=142 reason=registry_mismatch:44
[18:19:00 WRN] [MobSync] stale tracked sync mapping syncId=40 localIndex=141 reason=registry_mismatch:41
[18:19:00 WRN] [MobSync] stale tracked sync mapping syncId=41 localIndex=141 reason=registry_mismatch:40
[18:19:00 WRN] [MobSync] stale tracked sync mapping syncId=142 localIndex=180 reason=registry_mismatch:143
... (142↔143, 151↔152, 158↔159 too)

Every pair has the same localIndex, i.e. the same mob is reachable under two adjacent syncIds: IdToMob[44] = mobX while MobToId[mobX] = 45. Right after that, hits on those mobs fail:

[18:19:06 WRN] [MobSync] mapping mismatch context=hit syncId=46 expectedType=Zombie|Zombie actualType= reason=missing_sync_id
[18:19:09 WRN] [MobSync] mapping mismatch context=hit syncId=38 expectedType=Scorpio|Scorpio actualType= reason=missing_sync_id
... 130+ more across the level (syncIds in host's allocated range)

Observed effect: the client sees mobs that don't take damage / desync. Leaving to the next level (rebuild resets everything) fully heals it. Small levels (PrisonStart, 35 mobs) show only a handful of benign missing_sync_id; the paired registry_mismatch only appears on big levels.

Host side (trace enabled) shows the allocator is now monotonic (35 → 175 → 263 → 313, the nextRuntimeSyncId=0 reset from the old build is gone — good), so this is a remaining bug in the bind path: during multi-round MOBREG/MOBSTATE binding on a 140-mob level, one mob ends up bound to two adjacent syncIds. Suspect TryBindUnboundMobByTypeAndSpawnLocked — it skips mobs that are already bound (MobToId check) but never checks whether the target syncId is already occupied, and the one-shot state bind (state_oneshot_bind) plus MOBREG re-broadcast can race on nearby same-type mobs.

Bug 2: client reconnect cannot resume the current run (falls back to its own stale save)

Client is non-authoritative, so SaveGuard blocks every client world save during the run:

[18:44:59] [NetMod][SaveGuard] skipped non-authoritative client world write before host-disconnect auto-exit (host_disconnect)

After a disconnect and reconnect, the client auto-starts from its own local save ([NetMod] Auto-started new game after seed, [MobSync] ... role=client), which is always an older level than the host's current one (host was in BeholderPit, client landed in PrisonCourtyard, plus [NetMod] Remote level graph not applied for PrisonCourtyard: remote graph not received). The host's Coop ghost runtime bootstrapped for continue/level hero=880 level=BeholderPit only restores the host itself — it does not steer the client to the host's level. So reconnecting mid-run cannot continue the same progress; the only reliable path is to start a brand-new run.

Also, when the host is already inside a run and the client reconnects (host did not restart), the client just sits in the lobby and never enters the run.

It would be great to have the host re-send the current level/seed state on reconnect so the client can rejoin the host's current level.

Bug 3 (minor): host opening the main menu mid-run crashes the client

[18:43:03] [NetMod] Main menu opened during run; stopping network → client goes through host-disconnect auto-exit → level dispose → game re-init → Fatal Error:

[18:45:13 FTL][GameStartup] Fatal Error
Hashlink.Marshaling.HashlinkError: Uncaught hashlink exception.Null access .isEnable
   at Haxe!hxd.App.mainLoop ...
   at ModCore.Modules.GameStartup.StartGame()

Crash happens at GameStartup.StartGame() right after the forced exit/continue bootstrap — probably a null UI/game object after the non-authoritative save was skipped.

Logs

Full trace logs (host 7.9 MB, client 96 KB) available on request — happy to share the exact files.

[luan-a2]

Additional evidence: client crashes from the same mob-sync bug during regular (non-boss) combat

With v0.4.3 on the latest build, a client crash occurred during a normal PrisonStart run, not a boss fight:

[23:46:43 WRN] [MobSync] mapping mismatch context=hit syncId=155 expectedType=Runner|Runner actualType= reason=missing_sync_id
[23:46:46 WRN] [MobSync] mapping mismatch context=hit syncId=133 expectedType=Grenader|Grenader actualType= reason=missing_sync_id
[23:46:52 FTL] [GameStartup] Fatal Error
Hashlink.Marshaling.HashlinkError: Uncaught hashlink exception.Null access .baseFps
   at Haxe!en.mob.Runner.fixedUpdate(en/mob/Runner.hx:18()

Same pattern as the BeholderPit boss crash: when the client has lost the syncId mapping for a mob (missing_sync_id flood right before the crash), the client later updates that mob and dereferences a null field -> hashlink fatal. The boss crash was BeholderTtcl.fixedUpdate (.cd), this one is a regular mob Runner.fixedUpdate (.baseFps). So the bug is not boss-specific — it is the general runtime-mob binding gap (the registry_mismatch / missing_sync_id issue from the report) that can fatal the client whenever the client renders a mob it never managed to bind.

Also worth noting: this happened on a fresh NewGame run ~14 minutes in, over a stable direct VPN connection (no network errors before the crash) — the "disconnect" the host sees is just the client process dying.

[luan-a2]

Quick environment clarification: both players run the exact same game build — same v35 (2026-05-19) build hash 8199c6519f2ebddcba282c5419b8e7d717f0f07f, same DCCM 35.12.8.0, same mod build (0.8.91 / release v0.4.3). Both are the same non-Steam (Goldberg) repack, confirmed identical from both machines' logs. So the crashes are not caused by a version mismatch between the two players.

[luan-a2]

New issue found (separate from the mob-sync one): game hangs (not crashes) during level transitions — T_ transitional level -> main level*

We also hit a hard freeze (process unresponsive, no crash dialog, no Fatal) during level transitions, reproduced 4 times (Aug 1, Aug 6, Aug 7, Aug 8) always at the same spot: leaving a transitional level (T_Courtyard etc.) through the exit door into the main level (PrisonCourtyard).

Log always ends identically right after the mod's managed steps complete:

[20:34:26] LevelGen.generateGraph hook role="Host" level=PrisonCourtyard
[20:34:26] Sent level seed for PrisonCourtyard
[20:34:26] Sent level graph (28234 bytes)
[20:34:30] [MobSync] rebuild commit trackedAfter=99 level=PrisonCourtyard ... generation=5
[20:34:30] [MobSync] entitiesPostCreate duplicate ignored ... level=PrisonCourtyard
        <- log stops here; game frozen (main loop dead)

Dump analysis (two full memory dumps, (2).DMP 3.3GB and (3).DMP 3.7GB):

• Main thread: stuck inside cs_to_hl+(void (Boot,f64)) -> the hashlink native layer, never returning. Full stack: StartFromShell -> StartGame -> Hook_Boot_mainLoop -> Hook_Boot_update1 -> cs_to_hl(Boot.update).
• No managed deadlock: syncblk shows 4125 sync blocks all free; no thread waiting on Monitor/IO.
• No real exception record in either dump (both are hang, not crash).
• All other threads are idle thread-pool/IO pollers.

So the boundary is clear: all mod managed code finishes (logs are complete), then the game's native level-activation (activateSubLevel / Level.onActivation) hangs inside the hashlink VM. The mod's level-transition hooks steer the game into a state where native activation never returns.

We have GamePseudocodeAssembly enabled now (GamePseudocode.dll generated in cache) — happy to share it or re-run on request. Full logs and the dumps are available on request.

[luan-a2]

Patch we applied (in case you want to merge or review) — fixing the mob double-bind behind registry_mismatch:

Small patch on top of the v0.4.3 source, all in MonsterSynchronization.Registry.cs:

1. AssignHostNetIdsForRebuildLocked: skip mobs that already own a NetId (MobToId check) and dedupe trackedMobs.Add via FindTrackedMobIndexLocked — stops the host handing a second NetId to runtime-spawned mobs (boss parts, elite replacements).
2. TryBindUnboundMobByTypeAndSpawnLocked: bail early if the target NetId is already owned by a live local mob (TryGetTrackedMobBySyncIdLocked) — stops the client double-binding.
3. ConsumeIncomingMobRegistry replica path: skip replica creation if the NetId is already owned — stops overwriting an existing binding.

Result after 3 play sessions: registry_mismatch went from dozens-per-level to 0, missing_sync_id from 130+ floods to 3-51 (benign). Happy to share the exact diff or a compiled DLL.

New evidence: hard hang (not crash) on level transition (T_xxx -> main level)

Reproduced 4 times (8/1, 8/6, 8/7, 8/8), always the same spot. Example (host, v0.4.3 + above patch):

[20:34:26] LevelGen PrisonCourtyard ... Sent level seed/graph (28234 bytes)
[20:34:30] [MobSync] rebuild commit trackedAfter=99 ... level=PrisonCourtyard generation=5
[20:34:30] [MobSync] entitiesPostCreate duplicate ignored ... level=PrisonCourtyard
<--- log stops here; process becomes unresponsive (task-manager dump)

Minidump analysis (two separate dumps, same result):

• Main thread stuck inside cs_to_hl(Boot.update) — executing hashlink native code (game main-loop update) and never returning
• syncblk clean (4125 SyncBlocks, none held) — no .NET monitor deadlock
• All other threads idle (thread pool / IO completion), no recv/send waits
• No exception record (a genuine hang, not a crash)

So all mod (managed) transition steps complete fine in the log; the hang is inside the native level activation after the transition hooks (SubLevelGuard / activateSubLevel path). We enabled GeneratePseudocodeAssembly so GamePseudocode.dll exists here if you want to dig in.

Is this hang known? Any workaround besides avoiding T_xxx -> main level transitions?

[luan-a2]

More on the hang (important scope detail):

Single-player is fine; the hang only happens in co-op. The same route/level transitions in single-player (with the mod loaded, _netRole=None) never hang.

Where exactly the hang sits (source + dump): hook_boot_update calls orig(self, dt) first and only runs mod logic afterwards. The dump's main thread is inside cs_to_hl(Boot.update) — i.e. stuck in the native (hashlink) update call, before the mod's own post-update code runs. All the mod's level-loading hooks that DID run (_LevelStruct.get, LevelGen.generateGraph, entitiesPostCreate/rebuild) completed and logged fine; the hang is in the native level-activation update after that, before Game.activateSubLevel is reached (no ActivateSubLevelGuard pre-native log line appears).

So it is a co-op-specific native hang triggered by state the mod installs during co-op level load (host side in all 4 reproductions). Since single-player is clean, something the mod does on the host during a T_xxx -> main-level transition leaves native loading in a state where Boot.update never returns.

Host-side hooks in that window are read-only + send (SendLevel/SendLevelSeed/SendLevelGraph/NetId assignment), so the trigger is subtle. Happy to capture the client-side log of the same transition for comparison.

[luan-a2]

Crucial detail: in the same transition, the client completes the level activation normally while the host hangs before it

Same door (BgDoor:142:29), same destination level (PrisonCourtyard, 339 entities / 99 tracked mobs), same seed/graph. Timeline (host 20:34:23-30 vs client 20:34:21-28):

• Client: dispose -> LevelGen -> Applied remote level graph+rand -> entitiesPostCreate -> rebuild 99 -> full activateSubLevel chain: ActivateSubLevelGuard pre-native -> activation inside native guard -> SubLevelGuard completed -> normal entry (GhostKing created). Client only notices the disconnect 44s later (read error when the host process is unresponsive).
• Host: same steps up to rebuild commit + duplicate ignored, then no ActivateSubLevelGuard pre-native log at all — the main thread hangs inside native Boot.update before the mod's activateSubLevel hook runs (confirmed by minidump: cs_to_hl(Boot.update), managed post-update code never reached).

So the level graph/seed data is fine (client loads it fine); the hang is specific to the host-side native level-activation path during co-op (all 4 reproductions were host-side). If useful we can test swapping host/client roles to see whether it follows the host role or the machine.

[luan-a2]

Separate crash: client using the Flint weapon crashes the host (ghost rendering)

Repro: client equips Flint (火石枪), attacks normally -> host process crashes with Null access .stopPoweredFeedback inside hxd.App.mainLoop. Client is fine; the crash is in the host rendering the remote player's Flint powered-feedback (FlintGuard mode=local-vanilla-no-remote-runtime-preflight-powered-feedback-scan — i.e. remote powered-feedback is explicitly not preflighted). First occurrence, independent of the mob-sync/hang issues. Workaround for us: don't use Flint in co-op.

[vaiserYT]

Hello, thanks for you help! We'll try to fix it as soon as possible

[luan-a2]

Bug 2 (reconnect cannot resume host's current run) — full reproduction with logs, plus a new mob-sync crash

Live repro today (host role swapped to the other machine; T_Greenhouse -> Greenhouse transition did NOT hang with the other host, so the hang follows the host role/machine, not universal):

1. Client crashes in Greenhouse: Fatal Error: Null access .startLaunch at en.mob.Pitcher ~initSkills (Pitcher was attacking the client, low HP) — a new member of the mob-sync null-access family (previous: .cd boss, .baseFps Runner, now .startLaunch Pitcher).
2. Client tries to reconnect while the host is still in the run → no response / stuck (log: Client connected 21:14:45 -> Disconnecting client from host... 21:14:55, then reconnect 21:15:01).
3. Host has to return to the main menu (stopping network), then re-enters and Continues the same Greenhouse run (host progress preserved).
4. Client re-enters → Auto-started new game after seed -> LevelGen level=PrisonCourtyard (first level) — not the host's current Greenhouse. Both players end up in different levels.

So the reconnect path is: client has no way to restore the host's current level (client never writes during co-op due to SaveGuard), reconnecting while the host is mid-run hangs, and after the host restarts, the client Auto-starts a new game instead of joining the host's level. This is exactly issue #50's Bug 2. A minimal fix direction: on rejoin, have the host send its current level identity (+ graph) and have the client load that instead of Auto-starting a new game.

Also: the .startLaunch Pitcher crash seems unrelated to the double-bind patch (registry_mismatch is 0); it's another mob-sync null-access path. Happy to provide the full log excerpts.

[luan-a2]

Reconnect/hang update (2026-08-09): the level-transition hang is host-role-independent and random

New live repro with the other machine as host (host role was swapped back to the second PC):

• Same run: T_Courtyard -> PrisonCourtyard transition succeeded (14:08:10), then T_Roof -> PrisonRoof transition hung (14:14:28).
• Host log stops immediately after the mob-sync rebuild commits for PrisonRoof (entitiesPostCreate duplicate ignored ... level=PrisonRoof is the last line, 116 mobs tracked, registry built).
• The client enters PrisonRoof normally (14:14:27) and only notices the dead host ~3 min later (TCP timeout).
• This is the 5th occurrence of the same signature: transition level -> main level, hang right after the host's mob rebuild commits, only when both players are in the run, host role irrelevant (previous 4: host=PC-A; this one: host=PC-B).
• A full memory dump was attempted during the hang but came out empty (1 byte, dotnet-dump failed on the unresponsive process); earlier dump analysis showed the main thread stuck inside the hashlink native layer (cs_to_hl Boot.update) with no managed lock held.

So the hang looks like a race between the host's mob-sync rebuild/registry commit and the native level activation, triggered randomly on transition-level -> main-level switches. It is not about which machine hosts, and not about level identity (PrisonCourtyard succeeded, PrisonRoof hung). Happy to provide the exact log excerpts.

[luan-a2]

Dump evidence (3.37 GB full dump from the 2026-08-09 hang, host = PC-B): same native-layer hang signature as PC-A

We captured a full memory dump 25 min into the 14:14:28 hang (host was PC-B this time). dotnet-dump analysis:

• Main thread is inside the hashlink native layer: DynamicClass.cs_to_hl+(void (Boot,f64)) -> ModCore.Modules.Game.Hook_Boot_update1 -> DeadCellsMultiplayerMod.ModEntry.hook_boot_update -> ...Hook_Boot_mainLoop. The C# -> hashlink native call cs_to_hl never returned.
• The managed stack is clean (pure hook chain, no wait/lock frames). Earlier dumps (PC-A as host) showed the same cs_to_hl Boot.update signature with zero held managed locks (syncblk all free).

So across 3 dumps and 2 different host machines the hang signature is identical: main thread stuck inside the hashlink native layer right after the host's mob-sync rebuild commits on a transition-level -> main-level switch. This is a native-level race, not a managed deadlock, and it is host-role independent. Dump is available if the maintainer wants it (3.37 GB).