Class ContentRootAssetGenerator
Generates the ContentRootAsset set — the content declaration — from the generated content manifest.
Why this exists. Today the declaration of "what is content" lives in Addressables state:
ContentScanner reads AddressableAssetSettingsDefaultObject.Settings, takes each entry's labels,
and derives a kind. Two problems with that, both observed: forgetting to mark an asset is silent
(Rock.prefab sat on disk with a MiningResourceNodeBehaviour and was never registered, so
@asset:GameObject/Rock could not resolve and shipped unreachable), and it welds "what is content" to "who
packages it", which is exactly what the content-directories migration retires.
A root asset is where a name becomes a loadable reference — the job the Addressables address table does today — so generating the roots from the manifest moves the declaration into the repository, as assets, in git, reviewable and diffable, while Addressables still does the building.
Scope == the existing group, for this first cut. The migration plan calls those groups "artifacts of one-off registration tools, not designed boundaries", and that is right — but re-cutting the grouping at the same time as changing the mechanism would confound two variables, and a wrong cut is a build-time mistake (100 prefabs measured 741 s / 341 MB when the grouping was wrong). So the first cut is deliberately behaviour-preserving: every address the manifest carries ends up in exactly one root, under a name derived from the group it is in today. Re-cut the scopes afterwards, with real build numbers.
public static class ContentRootAssetGenerator- Inheritance
-
objectContentRootAssetGenerator
Methods
- Generate()
One root asset per scope. Idempotent: a root whose key set has not changed is left untouched, so a clean working tree stays clean and the generator is safe to run in CI.
- GenerateFromBatchMode()
Batch entry so CI can regenerate the declaration without a human (
-executeMethod).