public static class BuildPlannerTurns an imported project into the list a ContentBuilder packs.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
The step between "every asset has been imported" and "there is a build". Imports produce chunks and know nothing about addresses; ContentBuilder takes addresses and knows nothing about imports. This reads the addressable: block out of each sidecar, resolves what it leaves unsaid, and finds the mistakes that would otherwise surface as a load failure on a device.
Group is inherited from the nearest folder that names one. Doc 08 puts a group in a folder's own sidecar and says descendants inherit it, which is what makes "everything under Assets/UI ships together" one line rather than one line per file. The walk stops at the first ancestor that names a group, so a subfolder can override its parent.
Labels are not inherited. Making a folder's labels apply to its descendants would also make them impossible to remove from one of them, and a label is a query — the thing you most want to be able to say "all of these except that one" about.
An asset with no address gets its path. Assets/Textures/Crate.png is unique, stable within a checkout and already what the author sees in the Project panel, so it is an address every asset can have without anybody typing one. This reverses doc 08's original "an unaddressed asset is not shipped by name", and the reason is what that cost: a texture a game wanted to load by name and a scene in the build list were each a build error whose remedy was to go and fill in a field. Excluded is how something is now kept out.
⚠ What a build says about a broken asset therefore depends on who chose its address. An author who typed one meant it to ship, so anything that stops it being packed is an error; a path-derived address is a convenience over every file in the project, and a convenience that turns an unimported scratch file into a failed build is worse than none. The same conditions are warnings there, and the asset is simply not shipped.
An addressable asset depending on one that is not shipped is an error, and this is the check worth having. The catalog records dependencies as addresses, so a dependency in no bundle — excluded, or refused for one of the reasons above — makes a build that succeeds, ships, and fails at load on a chunk that was never packed. That is exactly the class of mistake that is expensive to find later and free to find here.
An asset's sub-assets are addressed under it, at characters/hero#Hero_Mesh — see SubAssetAddress. They have to be in the catalog rather than merely in a bundle, because a chunk is only reachable once the bundle holding it is mounted, and what mounts a bundle is an address in the load closure.
Fields and properties (2)
public const string DefaultGroupNameWhat a group is called when nothing names one.
public const char SubAssetSeparatorWhat separates an asset's address from the sub-asset it names inside it.
Methods (2)
public static BuildPlan Plan(IEnumerable<AssetEntry> assets, ImportCache cache, Func<AssetEntry, AssetMeta?> readMeta, IEnumerable<AddressableGroup> groups)Works out what to pack.
public static string SubAssetAddress(string address, string name)What a sub-asset is addressed as.
Used by (4)
- BuildPlannerTestsVixen.Editor.Assets.Tests
- ContentPipelineVixen.Editor.Assets
- PlannedProjectVixen.Editor.Assets.Tests
- VideoImporterVixen.Editor.Assets