Severity: HIGH
Summary
Lore commits tagged [Automatic Backup] are landing mass-delete changesets on the project’s main branch without the user performing any deletions in the editor. Multiple documented occurrences on the same project:
- Rev 4371 — ~156 file mass-delete. Class Designers dropped from 28 → 8, 1 landscape gone, teleporters affected, class-selector cluster untouched (initial mis-diagnosis on my end — see Additional Notes).
- Rev 4388 —
[Automatic Backup] 157 changesat 21:23:52 UTC. Same profile: Class Designers again dropped 28 → 8, landscapes and teleporters affected. This occurred on top of a fresh manual revert we had just committed as rev 4387 to undo occurrence #1. - Rev 4395 —
[Automatic Backup] 158 changesat 01:31 UTC (2026-07-13). Same profile, this one on a snapshot branch that the CLI had silently left as current after alore branch create. Devices missing from map on next reopen. - Rev 4396 — Editor-committed corrupt state during publish flow. This one persisted through UEFN’s own Save All / Check In dialog, not
[Automatic Backup]— but the eviction that fed it is the same underlying bug.
Every event was committed by Lore as if the user made 150+ deletions in a single action. No such deletions were made. UEFN was, in every case, running with the project open — no crash, no ungraceful shutdown, no branch merge that would introduce the deltas.
Recovery each time requires lore revision revert <signature>, which is destructive to any legitimate work in the interim and requires the user to know the correct hash to revert to. There is no editor-side UI path to detect or undo an auto-backup mass-delete.
Please select what you are reporting on
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
Unreal Revision Control
Steps to Reproduce
UPDATE (2026-07-13): Where I previously stated that neither occurrence was reproducible on demand because the user was not performing destructive actions before either commit, further reproduction has since isolated the trigger. The mass-delete occurs during Memory Calculation or immediately after it starts, and continuing through the subsequent auto-launched Fortnite session that Publish spawns while Memory Calc is still calculating. Definitely after Memory Calc starts. The bug does NOT fire when the user attempts an Upload to Private Version whose upload fails before Memory Calc runs. So the trigger is the Memory Calc phase of the Publish flow — not the Publish action itself.
All occurrences shared:
- Project has World Partition + OFPA enabled
- UEFN’s Auto Save is enabled by default (
EditorLoadingSavingSettings.AutoSave=TrueinEditorPerProjectUserSettings.ini,AutoSaveMethod=BackupAndRestore,bAutoSaveOnLaunch=True) - UPDATE: Auto Save and “Auto Save during iteration” were both tested in the disabled state. Disabling them had no apparent effect on the bug either way — the mass-delete still fires. This rules out UEFN’s Auto Save as the trigger.
- Lore has connectivity to the remote branch at commit time
- Commit message on the mass-delete is the literal string
[Automatic Backup] 157 changes(or similar count) — indicating a scheduled Lore-side backup mechanism, not a user-driven commit
Expected Result: An automatic backup commit — if such a feature exists at all — should never delete actor files that the user did not delete in the editor. At minimum, an automatic commit that would delete more than N files should be blocked and surfaced to the user for confirmation. Better: no automatic backup should ever produce a destructive changeset without an explicit user save action that intended those deletions.
Observed Result: Lore silently commits 150+ file deletions attributed to the user, with no user gesture that caused them. The commits push to the remote branch on next connectivity. The corrupted state becomes the canonical project state until the user notices and manually reverts. Devices lost in-editor across occurrences include Class Designers, Class-and-Team Settings & Inventory devices, Accolades devices, Stat Powerup devices, and other configuration devices. Additionally the asteroid dome geometry (129 asteroids placed in a hemisphere) reverts to a prior unshaped scatter, though those specific mesh actors are not deleted — only their transforms are lost.
On Reproducibility: Willing to share full lore history output, revision signatures (4063c30744312c35af35aa6ca861511ce23d48ea0254ec46fdb1b196e3e55e7b for occurrence #1, 3f116a504d9b24973aa7fa281f55cb938f99602d011d10887565e83608f78c50 for occurrence #2, plus several since), pre/post actor manifests, and OBS video attempts of devices vanishing from the Outliner during Memory Calc, on request.
Discussion — I/O assessment
This is common sense to the level that you could not charge people money for this product in its current state and survive as a company. And you’re drowning because people can’t get to the point of success where the licensing fees activate — because the FIRST and MOST fundamental things don’t work in your editor, and what is brilliant in there, the UI dysfunction sabotages, as a rule.
Timeline of documented occurrences
| Time (UTC) | Revision | Event | Actor delta |
|---|---|---|---|
| 2026-07-12 ~afternoon | 4371 |
Auto-backup mass-delete #1 | ~156 files deleted, incl. 20 Class Designers, landscape, teleporter |
| 2026-07-12 ~20:00 | 4387 |
Manual revert of 4371 by user (via lore revision revert) |
+156 files restored |
| 2026-07-12 21:23:52 | 4388 |
Auto-backup mass-delete #2 — [Automatic Backup] 157 changes |
~157 files deleted, same actor classes as #1 |
| 2026-07-12 21:39:37 | 4389 |
Auto-backup — 1 change | — |
| 2026-07-12 21:39:37 | 4390 |
Auto-backup — 1 change | — |
| 2026-07-12 ~22:15 | 4391 |
Manual revert of 4388 by user | +157 files restored |
| 2026-07-12 22:10:31 | 4394 |
User manual commit — merge of the revert into main | — |
| 2026-07-13 01:31:07 | 4395 |
Auto-backup mass-delete #3 — [Automatic Backup] 158 changes, on an insurance snapshot branch that the CLI had silently left as current |
~158 files deleted |
| 2026-07-13 01:49:18 | 4396 |
User commit after devices vanished during publish flow, capturing corrupt in-memory state | 129 files (asteroid transforms — the user’s session work at the time) |
| 2026-07-13 02:02:57 | 4397 |
Manual revert of 4396 by user | +129 files reverted |
| 2026-07-13 03:45:39 | 4400 |
User manual commit — pre-emptive save before further reproduction attempts | — |
Platform(s)
PC (Windows 11)
Video
I tried to capture. Imagine somebody actually ripping all the wires out of your game and lighting it on fire, repeatedly — how colorful your language could get. Just imagine, there in the Outliner, all your ■■■■ that you worked for possibly days to place, arrange, and wire ISN’T any longer, by no action you took or permission you gave, or possibly having any coherent explanation.
Additional Notes
- UEFN was closed when the recovery revert was run for occurrence #2. No process contention on the
.uassetfiles during revert. - Post-revert MCP scan of the persistent level confirms restored counts:
Device_ClassDesigner_V2_Cback to ~28,Device_Teleporter_V2_Cback to 37,Device_ClassSelector_V2_Cunchanged at 27 (this class was never affected — an earlier preliminary note of “0 class selectors” was a diagnostic filter error searching for the wrong class name and is not evidence of loss). Loss of Class Designers, and of Class-and-Team Settings & Inventory devices, was confirmed in triplicate including in-editor and visually searching for the devices. Many other devices including Accolades, Stat Powerups, and several other categories were deleted as well. - The pattern was originally suspected to be: (a) UEFN evicts actors from the in-memory level manifest due to an unrelated bug (candidate: OFPA streaming for unloaded WP regions being treated as “no longer referenced”), and (b) an auto-save-triggered Lore commit then propagates that in-memory eviction as a persistent 150+ file delete. UPDATE: The auto-save half of this chain has been apparently ruled out by testing with Auto Save and Auto Save on iteration both disabled — the mass-delete still fires. So it is Lore’s own scheduled backup mechanism, not UEFN Auto Save, that is committing the corrupted state.
- The Save Content dialog on editor close was observed offering to save the packages of the missing devices as pending modifications. Clicking “Save Selected” in that state would have persisted the deletion to disk manually — same failure mode as auto-backup, triggered by the user unwittingly. Cancel / Don’t Save preserves the on-disk
.uassetfiles, and reopening the project surfaces the actors again because the in-memory eviction was never persisted.
Impact
- Data loss on production maps. Every occurrence wipes 150+ hand-placed actors including class designers (player class configuration), and has been observed less commonly deleting landscapes (world geometry), teleporters (spawn logic), etc. Total re-placement time per event: multiple hours if the user cannot identify the correct pre-corruption revision. The “Unreal standard” 10–100× as long as anything should take if programmed correctly or if it had a common-sense UI or professional-level testing or documentation (looking at management, not the actual talent).
- Blast radius unbounded. The changesets go to remote via
lore pushon next connectivity. If a collaborator syncs before the user notices, the corruption propagates. - Silent commit attribution. The commit is attributed to the user (
Creator: moonligh7er, Committer: moonligh7er) even though the user made no deletions. Blame trails are useless for diagnostics. Wrong attributions are substandard for a would-be “enterprise”-grade editor. - No editor-side warning or dialog when the delete happens during Memory Calc or during the auto-launched Fn session that Publish spawns during Memory Calc. UEFN only surfaces the missing-actor state after the fact — when the user goes to Commit Changes and finds the changelist gutted, or when they re-open the project and the Outliner is missing devices, or when they attempt to playtest and Class Selectors do nothing. The user only discovers the loss after (a) reopening the project and seeing missing actors, (b) inspecting
lore history, or (c) attempting to playtest and no class selectors work. - Trust erosion in source control. Users learn they cannot leave UEFN idle with revision control on — a regression on the fundamental “save-often” workflow every editor promotes. This is not professional, not sustainable, not worth anything when everything takes 100× longer than necessary to maybe-ever work, and then might be deleted without action / permission / notice even if it does.
- Recovery hostile to non-CLI users. Recovery requires the Lore CLI (
lore history,lore revision revert <hash>). There is no in-editor “restore previous revision” or “diff last commit” UI. A creator without CLI experience would lose the work permanently. A creator in Fortnite Creative (non-UEFN) — from my understanding — does lose the work permanently. Somebody owes a lot of people an apology for their time, to say the least.
Suggested root cause (informed guess)
Best-guess causal chain — flagged as speculation at best:
- An unrelated UEFN subsystem (candidates: World Partition streaming for regions unloaded due to memory pressure, GroupActor + OFPA eviction bug, or a background async load failure) drops actors from the level’s in-memory manifest while their
__ExternalActors__.uassetfiles remain untouched on disk. This is triggered specifically during the Publish flow’s Memory Calculation phase and the Fn session auto-launch that runs concurrent with it. UEFN’s Auto Save fires at its next interval and re-serializes the level manifest to disk.Ruled out by testing: Auto Save was disabled and the bug still fired. Something Lore-side (a scheduled backup timer or file-watcher) picks up the difference between the in-memory manifest and the disk manifest, or between the disk manifest and the last-known-clean commit, and stages the diff as a mass-delete.- Lore diffs the workspace, sees that ~157
__ExternalActors__/.../*.uassetfiles are no longer referenced by the level manifest, and treats them as user-intended deletions. It stages and commits them under the[Automatic Backup]label. - The commit is auto-pushed to remote on next connectivity, propagating the corruption.
Requested fixes (ordered by impact-to-effort)
- Bulk-delete safety valve on auto-backup commits. If an
[Automatic Backup]commit would delete more than N files (suggested N = 5), refuse to commit and surface a modal to the user: “UEFN is about to record a deletion of 157 actor files that you did not delete in the editor. Continue?” Default: no. - Never auto-push destructive auto-backup commits. Keep them local until the user has reviewed and confirmed. The current auto-push behavior means corruption ships to collaborators before the user notices.
- In-editor “restore previous revision” UI. UEFN should expose
lore history+lore revision revertequivalents in a dialog — one-click “roll back to previous auto-backup” without CLI. - Distinguish user-intended deletes from evicted actors. If an actor is missing from the manifest but its
__ExternalActors__file is untouched (noDeleteObjecttransaction in the editor’s undo history), treat it as a candidate eviction bug, not a delete. Do not stage its file for removal. - Fix the underlying eviction. Track down what is silently removing actors from the level manifest during Memory Calc + Fn session auto-launch. Likely candidates: World Partition streaming under memory pressure, GroupActor + OFPA writeback, async load failures triggered by the concurrent session launch.
- Correct commit attribution. Auto-backup commits should not be attributed to the user as
Creator/Committer. Useuefn-automatic-backupor similar so blame trails are meaningful.
Workaround (current)
Not a fix — closes the window and adds a manual insurance layer:
-
In UEFN, open Revision Control Login and set Provider to None (revision control disabled). This disconnects the editor from Lore so Lore’s own scheduled backup timer cannot commit anything. The Lore repository on disk and remote remains fully intact —
lore history,lore revision revert, andlore pushcontinue to work. -
Commit to Lore manually via the CLI after each meaningful save session:
lore stage . lore commit -m "your message" lore push -
Before each Lore commit, run
lore statusand visually confirm the changeset does not contain unexpected mass deletions. -
When the corruption fires anyway (it can still hit during publish attempts even with Provider = None), close UEFN without saving — if the Save Content dialog appears listing packages of missing devices, click Cancel or Don’t Save. The on-disk
.uassetfiles stay intact and the devices come back on next reopen.
Previously suggested and ruled out: Editing %LOCALAPPDATA%\UnrealEditorFortnite\Saved\Config\WindowsEditor\EditorPerProjectUserSettings.ini to set EditorLoadingSavingSettings.AutoSave=False, AutoSaveMethod=None, and bAutoSaveOnLaunch=False was tested and had no apparent effect. Auto Save is not the trigger — Lore’s own backup mechanism is.
None of this fixes the eviction — it only prevents the corrupted state from being committed without user review. The only durable fix is Epic addressing the eviction upstream.
Discussion (broader)
Between teleports not working for no reason (if there’s a dysfunctionally-petty limit, document it) and somebody’s worthless or half-done work wasting / literally deleting mine, this editor as-is is worthless to the future of my company, me, and most of the would-be creator community. I’d like to see an even slightly functional version, but general failure to correctly order priorities beyond the level of a remedial child (FIX, YOUR, EDITOR) doesn’t point that way. Fix, your, editor, starting with sync. There is nothing else you need to be working on until that is addressed. Or, good luck, really.
Get rid of Lore entirely until you can do it right. Idk if somebody’s not skilled enough to resolve timezone differences in their code lol or what the issue is, but it’s too stupid to sync one user let alone a team. Under no circumstances should an editor be overriding, undoing, or straight up MAKING UP the decisions of the owner and only developer on a project without action or permission — randomly, or on an incoherent trigger, and still without notice. This is an example of a long list of things that indefensibly-fish-tank-IQ management is not prioritizing as emergent, exactly on-brand with the famous schizo incoherence and half-function of the editor and UI at large — which has diverged entirely from modern standards or sensibility in any area other than the brilliant bits we can’t get to because the basics don’t work no matter how much gold you toss into a dumpster fire. This stuff — that users have been telling you is deleting their work, that for some reason is still broken — should have never been released as a finished product, or even mentioned yet. Like physics.
All my video evidences is that the devices in question exist and are spontaneously deleted without selection or user action, during or immediately after memory calc. I’ll gut my whole game for diagnostic purposes again later maybe.
