Summary
Build: ++Fortnite+Release-42.20-CL-58011042 (Engine 6.0.0-58011042), Lore 0.8.6-nightly+331_3664, Windows 11
Summary
Editing one Blueprint that has many placed instances makes UEFN check out and resave every instance’s One File Per Actor package, then run a “hard source control status refresh”. The refresh handles the files one at a time at about 50 per second. With ~100k instances the editor is blocked on revision control for about 40 minutes. CPU (about 0.07 of a core) and disk (about 0.2 MB/s) stay near idle the whole time, so the refresh is not limited by hardware.
Impact
Any Blueprint change on a heavily placed prop (keys, tiles, collectables) locks the team out of revision control for most of an hour and produces a 100k-file check-in.
Logs available on request: UnrealEditorFortnite.log and Lore.log excerpts (request id of the status call: 86ca9e49-4490-d909-e54f-8db867faefac).
Please select what you are reporting on:
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
Lore
Steps to Reproduce
Steps to reproduce
- Open a project with a prop Blueprint placed many times (ours: ~102,000 instances across 5 Blueprints, OFPA / World Partition).
- Change a property on the Blueprint’s component template (we added a Verse tag on the VerseTagMarkup component) and save the Blueprint. No compile.
- Watch the editor log and Lore.log.
Expected Result
Expected
- A status refresh of 100k small files should run in parallel or in batches, finishing in seconds to a couple of minutes, not 40 minutes of mostly waiting.
- Debug-level per-file logging should be off by default, or at least not written out one line per file.
- Ideally, a template change that doesn’t change what instances serialise should not check out and resave every instance package.
Observed Result
What happens (timestamps UTC)
- 20:00:39: the Blueprint saves.
- 20:02:27: SourceControl: Checked out 101,927 files on ‘main’. / Waited +01.21:401 on Revision Control.
- 20:03–20:06: all 101,928 instance packages are rewritten on disk. Their content is unchanged apart from reserialisation, and the instances don’t store the edited property.
- 20:10:55: LogSourceControl: Warning: Excessive I/O encountered - hard source control status refresh requested. This can affect performance.
- 20:10:54 to ~20:52: one lore::repository::status call (scan: 1, staged: 1) logs Calculating deltas against filesystem path: / Scan found 1 file system changes in 0.000s for each file, one after another, at 2,400–3,200 files per minute. Almost every file reports 0.000–0.002 s of scan time, so nearly all the time goes to overhead between files.
- Revision control in the editor is unusable for the whole ~40 minutes. The process stays “Responding” while CPU sits at ~0%.
- Lore.log grew to 1.65 GB of Debug-level lines during the refresh.
Platform(s)
ALL