UEFN 43.00: publishing memory jumps from 53% to 124% after update

General Issues and Bug Reporting
, , ,
1

Summary

Since v43.00, my existing RaidMap project has jumped from about 53% of the publishing memory budget to 124%, without content additions that would explain this increase. Before the update, full memory tests passed. After the update, repeated calculations complete but fail the budget check at about 373 MiB / 300 MiB. Streaming is enabled. I am reporting an unexplained change in memory accounting or loading, not claiming that streaming is completely disabled.

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Memory Calculation

Steps to Reproduce

  1. Open the existing RaidMap project in UEFN v43.00 with World Partition streaming enabled.
  2. Cook the project and run the publishing memory calculation.
  3. Compare the result with the saved full memory-test results from October 28 and October 30, before v43.00.
  4. Repeat the calculation: the current result remains approximately 373 MiB / 300 MiB.

Expected Result

Comparable publishing memory usage for the existing island, or a documented explanation of the increase. The change from thermometer units to MiB should not by itself cause a previously passing island to exceed the budget.

Observed Result

Saved results for the same main RaidMap project:

  • October 28, 2026: 53,029 / 100,000, PASSED, 25 sampled locations.
  • October 30, 2026: 53,331 / 100,000, PASSED, 25 sampled locations.
  • November 1, 2026, after v43.00: approximately 373 MiB / 300 MiB, FAILED, 242 sampled locations.

Current calculation log: peak=391119633 threshold=314572800 sampled=242 success=false.
The report shows about 319 MiB always loaded, 373 MiB at the worst location, and 548.5 MiB for the entire map. Separate RaidMap_MainPartition cells are listed with different sizes.

Budget usage has increased from 53.33% to 124.33%. The sampling count changed too; I do not know whether that explains the increase.

Platform(s)

Windows PC, Unreal Editor for Fortnite v43.00

Island Code

6795-3600-4059

Additional Notes

Could Epic investigate whether v43.00 changed memory accounting, sampling, or which resources are treated as always loaded? The documentation states that switching to MiB does not change the calculation method.

The old exported resource lists only contain the top resources and hide many Epic asset names as generic Fortnite resources, so they do not allow a reliable full asset-by-asset comparison.

This report concerns a completed calculation that exceeds the budget, rather than the separate issue where a passing result is not reported to Creator Portal. No full logs are attached to avoid exposing personal information or identifiers.

2

Additional test: disabling streaming barely changes the reported peak memory.

For the same project, I obtained:

Configuration Peak memory Sampled locations
Streaming enabled, original loading range: 82,519 cm 373.00 MiB 242
Streaming enabled, reduced loading range 372.99 MiB 258
Streaming disabled 380.78 MiB 1

Disabling streaming increases the reported peak by only 7.78 MiB, approximately 2%. Reducing the loading range also makes almost no difference.

With streaming enabled, the report identifies approximately 319 MiB as always loaded. World Partition cells are listed separately, so the calculation does distinguish between streaming enabled and disabled.

I cannot determine whether the small difference is caused by resources being kept permanently loaded or by a memory-accounting regression after v43.00.

The original 128 m cell size and 825.19 m loading range were already present before the update, when the project passed its memory calculation at approximately 53% of the budget.

Could you investigate why streaming now provides so little reduction in peak publishing memory, and why the reported budget usage increased so significantly after the update?

6

Hi @Stax69 ,

Thanks for your bug report. As part of 43.00 improvements, we discovered and fixed some issues with the memory calculation process. Previously, spatially loaded content in data layers didn’t count fully toward an island’s memory estimate. On islands that keep most of their content in data layers, like yours, the old estimate was lower than the memory the island uses in play.

The 43.00 calculation measures the whole island. Your island didn’t get bigger in 43.00. The new number is closer to what players’ devices load at the island’s busiest point.

We also found a smaller issue in the new calculation that overstates islands with a lot of content in data layers. A fix is on the way, and it will lower your reported number a little. On its own it won’t bring your island under budget, so we recommend the change below.

What you can do

The biggest factor for your island is its World Partition Loading Range. Your island’s range is very large, so a player in the middle of the map loads most of the island at once. Lowering it should make the biggest difference:

  1. Open World Settings, then World Partition, and find your runtime partition (MainPartition).
  2. Reduce the Loading Range. Content then streams in closer to the player, so less of the map is loaded at the same time.
  3. If distant areas look empty after the change, generate HLODs. They keep a low-cost version of faraway content visible.
  4. Run the memory calculation again to check the new result.

For more detail, open the Memory Calculation panel. It lists the heaviest content, so you can see where most of the memory goes.

Thanks again for the report.

Nick

7

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

8

Hi Nick,

Thank you for the explanation. I understand that v43.00 fixes an earlier underestimate of spatially loaded content in Data Layers, and that the upcoming fix will only address a smaller overestimate.

However, I have tested the Loading Range recommendation and obtained these results:

Configuration Peak publishing memory
Streaming enabled, Loading Range 82,519 cm 373.00 MiB
Streaming enabled, Loading Range reduced to 70,000 cm 372.99 MiB
Streaming disabled 380.78 MiB

Reducing the Loading Range from approximately 825 m to 700 m barely changes the result. Disabling streaming entirely increases the peak by only 7.78 MiB.

With streaming enabled, the report also shows approximately 319 MiB as always loaded, which already exceeds the 300 MiB budget.

Could you clarify:

  • What Loading Range would you recommend testing for this island?
  • Is the 319 MiB always-loaded figure expected for content organized in Data Layers, or could it be affected by the remaining calculation issue?
  • Is there anything in the island’s Data Layer configuration that could explain why streaming has so little effect on the reported peak?

I would like to identify the cause before removing content or making changes that significantly affect the island’s appearance.

Also, does FORT-1185768 being “Ready for QA” refer to the smaller overestimation issue you mentioned?