Published UEFN Sessions Enter Server-Authority Ghost State After JIP Player Turnover

[Tommiislav]

Summary

In a published UEFN Creative island, sessions can enter a broken “ghost state” related to Join-In-Progress player lifecycle / player turnover. When the original non-JIP player leaves and only JIP players remain, or after enough JIP-related player turnover, server-authoritative gameplay can partially stop. We enabled Native JIP and removed our custom JIP benching/manual respawn-eliminate flow, which partially improved the issue, but the problem is not fully resolved.

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Stability

Steps to Reproduce

Start a published UEFN Creative session with Player A as the initial player.
2. Let Player B join the same session via Join-In-Progress.
3. Keep Player B in the session while Player A leaves.
4. Continue the session with only the JIP player remaining.
5. Start or continue the custom round flow until storm / HUD / gameplay systems should be active.
6. Observe server-authoritative gameplay and HUD behavior.

Expected Result

The JIP player should become a valid active player in the session. HUD, storm, building/editing, damage, devices, round state, and gameplay systems should continue working normally even after the original player leaves.

Observed Result

The session can enter a ghost/broken state. The player can still move and shoot locally, but server-authoritative gameplay breaks: HUD/timer elements disappear or stop updating, storm/zone can disappear or stop functioning, damage does not apply, building/editing stops working, and gameplay devices stop responding. The session does not recover and players may eventually be kicked/returned to lobby. No useful Creator Portal Verse error is generated for this failure.

Partial Mitigation Already Tried
We enabled Native Join-In-Progress and removed our custom JIP handling that manually respawned / eliminated JIP players. This improved the immediate JIP-only failure case, but the issue is still not fully resolved, so it appears connected to native JIP/player lifecycle or server state after player turnover.

Platform(s)

Platform(s)

Windows PC, iPadOS / mobile clients, published Creative sessions.

Island Code

0754-5312-8592 and 8894-5597-2034

Upload an image

Video

and

Additional Notes

If more information is needed, please contact me. I can explain the issue in more detail, provide additional reproduction context, or show what happens in-session.

Discord: tommiislav

[Tommiislav]

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:

1. Player A is in the session normally.

2. Player B joins mid-round via Join-In-Progress → everything works correctly.

3. Player A leaves the session → the session remains healthy.

4. Player A rejoins the running session, now also as JIP.

5. On this second entry, Player A’s persisted/restored player data does not load correctly.

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