Data Layers set to unloaded show even when unloaded

General Issues and Bug Reporting
, , ,
1

Summary

Data Layers set to unloaded show even when unloaded

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Other

Steps to Reproduce

play a maps live version that has data layers set to unloaded

Expected Result

data layers set to unloaded might show

Observed Result

data layers set to unloaded might show

Platform(s)

all I think

Island Code

5253-8468-3364, 7048-8422-2298

3

This is affecting Island Code: 2878-0542-7931

Initial Runtime State is set to Unloaded.
Since the v36.00 update data layers now start initially loaded in a published game.
The issue appears to only happen in a published island as testing in an editor session did not reproduce the issue.

Screenshot 2025-06-08 132622
Screenshot 2025-06-08 132622496×807 31.8 KB

1 Like
4

It appears the issue is that the initial runtime state setting was somehow changed in the published island.
I managed to fix the issue by just republishing the island with no modifications.

5

Hi.

I’ll take a look at this issue on my side.

Can you explain what you meant exactly by “It appears the issue is that the initial runtime state setting was somehow changed in the published island.”?

Thanks!

6

To elaborate:

  • All my data layers are set with Initial Runtime State = Unloaded.
  • In v35.20 this was working fine - only data layers that were manually loaded is visible.
  • After the v36.00 update - multiple data layers appear intially loaded as seen in the video.
  • Republishing the same island version fixed the issue.

So the statement was an assumption I made from what I observed, where it appears the update may have causes the Initial Runtime State = Loaded in the published island.

7

I have same problem on my map (3359-2522-4686), I’m going to republish it as it is to see what happened, I will let you know.

8

Yeah so I can confirm that just republish fixes it!

9

FORT-920639’s status has changed to ‘Ready for QA’. A member of the QA department is investigating the issue.

10

Hello everyone,

Adding our findings to this thread as we believe we’ve managed to isolate a more specific and consistently reproducible version of this data layer bug, which started happening for us after the recent updates.

The core issue seems to be that data layers break after the first successful push. Any subsequent changes to a data layer’s contents (like moving a prop or adding a new one) cause those props to permanently disconnect from the data layer’s loading state in a live session.

Exact Steps to Reproduce the Bug

  1. Create a new Data Layer (e.g., DL_Test_01).
  2. Place a few props from the Content Browser into your level and assign them to DL_Test_01.
  3. Launch a session by clicking Push Changes.
  4. Result: Everything works correctly. The props in DL_Test_01 are properly unloaded by default as expected.
  5. End the session. Now, back in the editor, make a small change. Either move one of the props already in DL_Test_01 or add a new prop from the level to that same data layer.
  6. Launch a new session by clicking Push Changes again.
  7. Result: The bug now appears. The props you modified or added will now be visible in the game, completely ignoring the fact that their data layer is unloaded. They seem to be permanently “stuck” on.

Temporary Solution / Workaround

Through testing, we found a temporary (but cumbersome) workaround:

Instead of modifying an existing Data Layer, you must create a completely new Data Layer to replace the existing one for any new prop you want to add or modify.

For example, if you need to add more props after your first push, do not add them to DL_Test_01. You must create DL_Test_02, add the new props to it (optionally pass the props from DL_Test_01 and remove it), and then push the changes. This seems to work correctly, but it is not a sustainable solution for large projects.

Hoping this helps.

11

In a live session, all modified actors will be always loaded regardless of their location or data layers. You will need to publish a new version to test changes that affects streaming for now.

I don’t think this is the same issue as the original post, which was that an already published project in 35.20 stopped working in 36.00 and required a republish to fix.

1 Like
12

I’m confused does this mean data layers and streaming (with actors that are placed after 36.00) are meant to not despawn when in a Live-Edit Session?

Or does this just mean that if we modify a prop (move it etc) it will always stay loaded and not work with streaming and data layers, till a new module version is made by etc pushing changes?

13

Exactly this. Live edit sessions works by first generating the streaming and then any further changes that affects streaming will not take effect until you start a new live edit session, or when you publish your changes.

1 Like
14

Thank you for the clarification, that helps a lot.

You are right, our issue seems different. I have one follow-up question to be sure before we possibly submit a different bug report.

When you say a user needs to “start a new live edit session” or “publish your changes” for streaming to be regenerated, could you clarify exactly what action that refers to?

  1. Pushing changes using the “Push Changes” button during an active session?
  2. Closing the UEFN session and starting a completely new one from the editor?
  3. Publishing a new private version with a new island code?

We have tested those 3 options but the bug persists for any future live edit/game session and even newly generated private codes. We even waited over 16 hours to rule out any server caching. The modified/added props remain broken (not streamed with the DL).

If the expected behavior is that #1 or #2 should fix/regenerate the streaming, then the behavior we are experiencing is different, and we will happily open a new, dedicated bug report for this.

Thanks again for your help!