Additional / More Precise Reproduction and Triage Data
I have narrowed the issue down further and observed that the failure threshold differs depending on the player-initialization path used.
In our currently published version of both islands, player initialization is driven from the native PlayerAddedEvent. In that version, the ghost/broken session state can already be triggered on the first Join-In-Progress entry.
In an internal test build, we moved character-dependent initialization to the player-spawner spawn event instead. With this setup, the first JIP entry is healthy, but the failure appears on the second entry of a player - specifically after leaving and rejoining the same running session.
The more precise reproduction in the internal test build is:
-
Player A is in the session normally.
-
Player B joins mid-round via Join-In-Progress → everything works correctly.
-
Player A leaves the session → the session remains healthy.
-
Player A rejoins the running session, now also as JIP.
-
On this second entry, Player A’s persisted/restored player data does not load correctly.
-
Shortly after one of the players leaves the game, the session enters the ghost/broken state described above, where server-authoritative gameplay appears to stop functioning correctly.
Summary of the internal test-build behavior:
-
First JIP entry = healthy.
-
Leave + rejoin into the same running session = broken.
-
The returning player’s restored state is incorrect first, and shortly after that the server-authoritative gameplay state breaks.
Additional Observation — Shared HUD / Timer Not Restored on Second Entry
On the broken second entry, the rejoining player does not see the standard shared HUD elements. Specifically, the game-start timer and the pre-game/countdown timer that every player is supposed to see are missing. The minimap still renders, but the global timers do not.
On the first JIP entry, those same timers display correctly. (not in the public version tho with the “PlayerAddedEvent”.)
This suggests that the native JIP/reconnect path is not fully restoring the player’s session/HUD state on a second entry, independent of our custom logic.
Behavior Differs by Player-Init Approach
We can currently observe two different failure thresholds depending on which native event is used for player initialization:
-
Published version of both islands: initialization is driven by
PlayerAddedEvent, and the ghost state can trigger already on the first JIP entry. -
Internal test build: character-dependent initialization was moved to the player-spawner spawn event, and the first JIP entry is healthy, but the failure appears on the second JIP entry after leaving and rejoining.
So while the exact trigger threshold shifts depending on the JIP/lifecycle initialization path, the underlying ghost/VM-death behavior on player turnover persists in both cases.
This points more strongly toward an issue in the native JIP/reconnect lifecycle and stale server-side player state after player turnover, rather than a single isolated piece of custom logic.
Working Hypothesis
The issue appears related to reconnect/player-object identity and stale server-side player state after turnover. A rejoining player may not be treated as a clean new lifecycle by the server, which can result in partially restored player/session state.
I am also investigating whether a burst of normal per-player initialization immediately after re-entry may be stressing the engine’s reconnect handling, but the fact that the issue persists across different native initialization paths suggests the root cause is likely deeper in the native JIP/reconnect lifecycle.