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 keys the build does not have fall back to this one on every platform the editor plays on.
Where both know a key, the project wins - that is the point of the source - with one exception: a key a
mod directory also contributes stays the mod's, because the mod is the newer word on it. GrindFest ▸ Content ▸ Play Against Built Content flips the whole thing around and makes a play session resolve from the built
directory only, which is how to test release behaviour in the editor (prefab edits since the last content
build will not show up there, which is exactly what a build does). The preference is an EditorPrefs value,
so it survives the domain reload that entering play mode may cost.
[InitializeOnLoad]
public static class ContentAuthoringSource- Inheritance
-
objectContentAuthoringSource