**An asset with no referencers is not necessarily unused. An asset with referencers is not

necessarily used.**

Two assets that reference each other and nothing else have a referencer apiece and are both dead. A

GameMode named only in `DefaultEngine.ini` has no referencer at all and is the thing your game

cannot start without. Any tool that answers "is this used?" by counting referencers gets both cases

wrong, and one of those mistakes is unrecoverable.

### How reachability works

The sweep starts from a root set — the things that are loaded because they ship, not because

something points at them:

- Every map in the content root.

- Asset Manager primary assets. These are loaded by id at runtime and routinely have no

referencer at all. Without them, every item definition in a data-driven project reads as garbage.

- **Anything named in `Config/*.ini`.** Your GameMode, default pawn, startup map, input mappings.

This is the step that stops the tool reporting the assets your game depends on most.

- Anything referenced from outside the content root. For plugin content this is the entire

point: a plugin asset used by `/Game` has no referencer inside the plugin.

From there it follows dependencies — hard and soft. Restricting the walk to hard references

drops every `TSoftObjectPtr`, every class picked in a Blueprint default, every entry in a

soft-referenced array. Those are precisely the references a careless cleaner misses right before it

deletes something the game loads at runtime.

It also walks through redirectors. A rename leaves a redirector behind and does not rewrite the

referencing assets — that is why "Fix Up Redirectors in Folder" exists as a separate action — so a

referencer routinely points at an old path that now holds a redirector. A sweep that stops there

reports the live asset behind it as unused. On any project carrying un-fixed redirectors, which is

most of them, that means real content offered for deletion.

### Findings come with a confidence, and a refusal

Whatever the sweep never reached is reported as Certain, Probable, or Suspect —

Suspect meaning its name occurs in your C++ or build scripts, so something may load it by a path

built at runtime. If config or source could not be read in full, nothing in that report is allowed

to claim certainty, and the summary line says so.

Deleting is never offered as a one-click action. Which assets a project can afford to lose is a

judgement about the project, not a mechanical repair. AssetMedic shows you the list, the sizes and

the evidence.

### The other four checks

Duplicate assets. A `.uasset` cannot be compared whole — its header carries the package name and

a per-save GUID, so two genuinely identical assets never match byte for byte across the full file,

and a tool that compares whole files finds nothing while looking like it works. AssetMedic compares

everything after the header, plus the `.ubulk` sidecar.

Broken references. Dependencies that no longer resolve to a package on disk. These fail a cook

and, in the editor, load silently as null. Grouped by the missing package, each finding naming it

directly.

Redirectors. Reported and repairable in place — one click rewrites every referencer through the

engine's own fixup path. Handled per package, because renaming a Blueprint leaves three redirector

objects in one file, not one.

Missing LODs. Static meshes above a triangle threshold with only LOD 0. Read from the asset

registry's own tags, falling back to opening the mesh only when those are absent.

Naming convention. Epic's published prefixes — `SM_`, `MI_`, `T_`, `WBP_`. Off by default,

because a project built from marketplace content will report hundreds of violations that are not

defects. An asset already carrying an unrecognised prefix is reported but never renamed: prepending

would produce `BP_BPL_Library`, and stripping would discard whatever the author meant.

### Restructuring, without breaking anything

The second tab proposes a whole new folder tree. Two rules govern it.

Planning and applying are separate, and planning touches nothing. A plan is a list of From → To

pairs you can read, sort, deselect and export to CSV before a single asset moves. You should not

have to trust this tool; you should be able to check it.

Moves go through `IAssetTools::RenameAssets` and nothing else. A move is never a file operation:

the engine has to rewrite every referencing package, patch Blueprint pin defaults and level actor

references, and leave a redirector behind. Moving `.uasset` files on disk gets you a project that

opens with every reference null.

Three tree shapes — by type, by feature, or by feature then type. Feature is inferred from the

asset's own path, and where the path says nothing, from a majority vote among the assets that

reference it. An asset used by three different features has no home among them and is left shared

rather than filed under whichever one references it twice.

### Work in batches you can actually review

A real project produces well over a thousand naming violations and nearly two thousand moves. Nobody

audits that as a flat list — they trust it wholesale or ignore it entirely.

So the plan is a tree, grouped by type and then by asset class, with two scoped actions: **fix the

prefixes in this category**, or reorder this category. Every row shows both counts, because "12

to move" and "300 to rename" are different jobs on the same folder. One category at a time keeps

each change small enough to review and small enough to undo.

### What it will never do

- Delete an asset.

- Move a map, or a map's generated build data — the engine resolves that by path convention, not by

a reference a rename would fix.

- Move anything into or out of `__ExternalActors__` / `__ExternalObjects__`, in either direction.

- Rename an asset whose existing prefix it does not recognise.

- Resolve a name collision by picking a winner. Both are refused, each naming the other.

- Run while anything in the target has unsaved changes.