Player Relocating / Black Screen on Spawn in Cooperative Mode (Live Sessions Only)

[TheSandsquad]

Summary

On a Cooperative mode island with up to 8 players, players experience a “Relocating…” black screen on first spawn in live sessions. The player briefly appears at the correct spawn pad position, then after approximately 1 second the screen goes black, shows “Relocating…”, and the player is moved to the sky before being dropped back to the correct location. The delay lasts 5–15+ seconds. This does NOT happen in UEFN editor test sessions — only in live/published sessions.

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Matchmaking

Steps to Reproduce

1.	Open island 0564-0723-6518 or our playtest 9533-7899-3194 in a live private session
2.	Join as the first player
3.	Observe: player spawns correctly at spawn pad, then after ~1 second black screen + “Relocating…” appears
4.	Player ends up in the sky and falls back to the ground
5.	Second player joining the same session does NOT experience the issue

Expected Result

Player spawns immediately at the player spawner device location with no black screen or relocation.

Observed Result

Player spawns correctly for ~1 second, then “Relocating…” black screen triggers, player is sent to the sky and falls back to spawn position. Delay of 5–15 seconds before gameplay starts.

I have tested with 2 players in the playtest session and face the issue for 1st player in the session (Relocation). The 2nd player was joining and had no relocation issue BUT I saw how he was redirected from one spawner to another - he 1st appeared on one spawner and as the game really started for him he was redirected to another one (but without relocation screen) - see here on the video few spawn events - from 3-4 spawn events he was redirected 3 times: https://youtu.be/OZqzswDTZlc

Platform(s)

All

Island Code

0564-0723-6518

Additional Notes

•	Issue started approximately 1 month ago after an Epic update — was working correctly before
•	Only affects the FIRST player in an instance. Second player and beyond spawn correctly
•	Issue is intermittent — sometimes works correctly, sometimes triggers
•	Does NOT reproduce in UEFN editor test sessions

What has been tested and ruled out:

• Replaced all player spawner devices with fresh ones — issue persists
• Added flat collision platforms under all spawners — issue persists
• Verified spawners are placed on solid ground with correct Z position
• Island Settings Spawn Location is set correctly
• No FortCharacter.TeleportTo calls firing on game start
• No barriers or volumes near spawners that could push players
• Disabled mutation zone — partial improvement but issue persists
• Tested with Custom team mode, Team Index mode, Cooperative mode — all have the issue
• Verified Default Class Identifier is not causing class assignment on spawn
• World Partition Loading Range increased — no improvement
• Assets near spawn marked as Is Spatially Loaded = false — no improvement
• Verse coop_team_manager script forcing Team 1 assignment on join — helped second player but first player still affected
• Tested with reduced number of spawners (3 instead of 8) — issue persists
• Issue is intermittent — same spawners work fine one session, fail the next with no changes made

[Bug-Reporter]

FORT-1109730 has been created and its status is ‘Unconfirmed’. This is now in a queue to be reproduced and confirmed.

[TheSandsquad]

I have spent 2 days trying to fix it on my side. Completely recreated all spawners, put static flat mesh below them, removed all possible colliders around, made all elements around to pre load before player spawns and tried many other things. In the end I reached the state that on the test on live client it worked without any relocation between 1 pm and 3 pm… but later as I retested the same build around 8-9 pm and later I got the relocation again on some spawners .

here is the playtest: 9533-7899-3194

The issue is critical - I see that the number of players who left in 1st minute has grown rapidly. Players think we are redirecting them to another game or just don’t wait and leave.

[TheSandsquad]

Update — new diagnostic findings

Since filing, I ran controlled tests that reveal a strong correlation between the relocation and player profile persistence.

14/14 correlation with persistence loading:

I tested 14 spawns as the first player, tracking whether my persisted player stats (Level/XP/MaxHealth/MaxShield, stored in a persistable weak_map) loaded on that spawn:

• 7 spawns where persisted values loaded (correct stats from the start) → relocation occurred in all 7.

• 7 spawns where persisted values did NOT load (player kept default values) → no relocation in any of the 7.

So relocation happens exactly when the returning player’s saved profile is resolved/applied at spawn, and never when it isn’t. This lines up with the original observation that the second player (no resolved profile yet that frame) doesn’t get the relocation screen.

Timing detail that rules out my own code:

I apply stats on SpawnedEvent. I tested moving that write into a delayed async task (spawn { Sleep(2.0) ... } with an IsActive[] guard). The relocation still occurs, and it occurs before the 2.0s delayed write executes — so my stat-application code is not the trigger. The relocation is happening during the engine’s own spawn/profile-resolution phase, prior to any Verse stat write.

Related secondary symptoms on the no-load spawns:

On 3 of the 7 no-relocation (persistence-not-resolved) spawns, two extra glitches appeared that do NOT occur on the relocation spawns: (1) a shield UI element that is disabled in settings briefly appeared, and (2) a popup-linked voice/audio file played twice. This suggests the “persistence not yet resolved” path is a distinct spawn code path with its own issues.

Hypothesis:

This appears consistent with a returning-player profile-reconciliation / pawn re-resolve step in the engine that, for the first player in a live instance, races the spawn-location validation and triggers the relocation failsafe. It only reproduces in live/published sessions, never in UEFN editor — consistent with persistence behaving differently live vs. editor.

[TheSandsquad]

Update:
I just tested in Playtest my old versions - rolled back till 26th of February and the issue is still there… so its not something I created recently, it should be something on server side.