Summary
As soon as a custom Verse Scene Graph component is added to an entity, live in-game memory usage (the “Current Memory Usage” HUD) scales with the total size of the project’s compiled Verse binary, not with the code that component, or anything else placed in the level, actually references. This holds even when all of the additional Verse code is dead: never instantiated, never called, never reachable from anything in the level. Removing the custom component drops memory back to a flat baseline regardless of how large the compiled Verse binary is; re-adding it reintroduces a cost proportional to the current binary size. Publishing an island requires memory to stay under 100,000 in every game region, so this defect means unreferenced Verse code alone, with no gameplay effect whatsoever, can push a project past the publish-blocking threshold. Controlled testing further found that different kinds of unreferenced Verse content cost very different amounts (public struct fields costing far more per-declaration than methods, distinct type and class declarations carrying overhead beyond their contents, and large repeated string literals costing much more in memory than their compressed size on disk would suggest), but all of it costs something, and none of it needs to be reachable to do so.
Please select what you are reporting on:
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
Verse
Steps to Reproduce
- Create a new UEFN project from the blank template. The blank template does not include any entity or component.
- Create one entity in the level and attach a single trivial custom Verse Scene Graph component to it:
using { /Verse.org/SceneGraph }
memory_probe_component := class<final_super>(component) {}
- Build Verse, cook/upload the project, start a session, and record the “Current Memory Usage” value shown in the HUD.
- Add a large number of additional
.versefiles underContent/that declare plain structs and classes not referenced anywhere, for example (repeated across many files with unique names, to reach several hundred thousand total method/field declarations):
vz_gen_struct_1 := struct {
Field1: int = 0
Field2: string = "placeholder"
}
vz_gen_class_1 := class {
MethodEmpty1() : void = {}
MethodNonEmpty1() : string = {
"sample text"
}
}
- Build/cook, start a session again, and record “Current Memory Usage.”
- Remove the component created in step 2 from the level (leave the bulk generated files in place), build/cook, start a session, and record memory again.
- Re-add the same component and repeat.
Expected Result
Live memory usage should reflect only the Verse code that is actually reachable from what is placed in the level. Adding large amounts of unreferenced, uninstantiated Verse code elsewhere in the project should not change the memory cost of an unrelated component, and removing or re-adding that component should not toggle a memory cost that tracks the size of code it never touches. More specifically: adding a custom Scene Graph component to a level should not, by itself, cause memory to spike based on the total size of the project’s compiled Verse binary.
Observed Result
Memory scales with the total compiled Verse binary size as soon as a custom Verse Scene Graph component exists in the level, regardless of whether that component (or anything else placed) references the extra code. The tables below summarize the numeric data gathered across our test runs (the custom component from step 2 is present unless noted).
Binary size ramp (same single custom component present throughout):
| Total unreferenced declarations | Verse Download Size (compiled) | In-game memory |
|---|---|---|
| 5,760 | 0.46 MB | 5,537 |
| 14,400 | 0.90 MB | 8,843 |
| 43,200 | 2.48 MB | 19,986 |
| 92,400 | 5.13 MB | 38,722 |
| 183,400 | 8.53 MB | 66,789 |
| 490,000 | 22.17 MB | 169,369 |
Memory grows in step with the compiled Verse binary size across this whole range, even though every one of these declarations is dead code, never instantiated or called.
Component present vs. absent, same binary:
| Verse Download Size | Memory, component absent | Memory, component present |
|---|---|---|
| 0.46 MB | 2,859 | 5,537 |
| 5.13 MB | 2,859 | 38,722 |
With the component removed, memory stays at the same flat baseline (2,859) regardless of how large the unrelated compiled Verse binary is. With the component present, memory scales with that same binary size. The component’s own source code never changed between these measurements.
Declaration type matters (same total declaration count, same file and class layout):
| Declaration type | Total declarations | Verse Download Size | In-game memory |
|---|---|---|---|
| Methods (trivial body) | 490,000 | 17.41 MB | 120,836 |
| Struct fields | 490,000 | 49.21 MB | 183,216 |
Moving the same number of declarations from methods into struct fields, with total declaration count held fixed, more than doubled the compiled Verse Download Size and produced a higher memory reading, showing the cost is not uniform per declaration.
Platform(s)
PC (Windows)
Additional Notes
Reproduced in UEFN 6.0.0-57819926 (Fortnite Release 42.10). Also found during this investigation, likely a distinct defect worth its own report: a hard cap on total staged Verse file count in a cook. A project with 1,311 total .verse files failed to cook with FlowStep_ResolveSessionCandidates(): ... [candidate_handler_too_many_staged_files], while 771 files cooked fine, independent of total byte size. Internal bug database reference, for matching any follow-up to our records: A2RV2O.
