Class ContentAuthoringSource
The editor's content source: it answers content keys from the project itself, so no content-directory build is needed to press Play.
Why this exists. A content directory is build output, and for a player it is the right answer: one file set,
target-specific, shipped. In the editor it is a tax. ContentDeclaration already declares every key from the
folder rules and Key is the asset path, yet a prefab added a minute ago stayed invisible until someone
ran Generate Content Roots and Build Content Directories — measured 2026-09-20 at 4.3 minutes for the base
scope, warm. That is the wait this removes, and it was the reason an author could not iterate on a new variant
without a coffee break.
How it answers. Two delegates, both registered into ContentDirectoryStore:
- Resolve(string) — address to asset in one AssetDatabase lookup. It answers both "do you know this key" and "give me this key" for a single address, and needs no index at all, which is why adding a prefab costs nothing.
- GrindFest.Content.Editor.ContentAuthoringSource.BuildKeys() — the whole declared set, built **lazily**, because only name→address resolution (`InkWorldGenerator.AddressForName`) and diagnostics actually enumerate.
Keeping up. GrindFest.Content.Editor.ContentAuthoringPostprocessor sees every import, delete and move and updates the set one path at a time through the same rule the build scan uses (WouldDeclare(string, List<string>, out string)), so a new variant prefab is visible to the next lookup — and the two cannot drift, because there is one copy of the rules.
What it is not. It does not touch the build path. Players still read the built directory, and both sources may be registered at once: the built directory wins where it knows a key (it is the authority on what ships) and this fills in what the build does not have yet.
[InitializeOnLoad]
public static class ContentAuthoringSource- Inheritance
-
objectContentAuthoringSource