"What hotload does (and doesn't) for a new project"
- You changed a
.sceneorInput.configand Play still behaves like the old version. - New assets don't appear until you kick the editor.
- After a bad edit, Play looks "fine" but runs ancient code.
Hotload replaces the C# assembly quickly. It is not a full project reload. Scene files, input action tables, and some asset compiles follow different refresh rules. A failed compile leaves the editor on the last-good assembly — see stale-assembly-hotload for the multi-symptom failure mode.
| Change | What to do |
|---|---|
| C# / Razor code | Alt-tab / focus editor — applies in ~ms |
.scene file | Restart Play |
New Input.config actions | Restart editor (action list reload) |
| New / fixed assets (vmdl, etc.) | Often need an editor kick; first load after regen is slower (normal) |
| Network session | Resets on hotload |
| Compile failed mid-edit | Fix compile + restart Play — don't debug fake regressions |
Setup implication: prefer the 4-object scene + Bootstrap pattern (four-object-scene-bootstrap) so most iteration is C# (hotload-friendly) instead of giant scene JSON.
If "everything broke at once," check compile failure / wedge before rewriting systems (stale-assembly-hotload).
Hotload is an assembly swap optimized for code iteration. Config and scene graphs are loaded on session/Play boundaries; assets go through a separate compile watcher. Knowing which bucket your edit landed in stops cargo-cult "restart everything" — and stops trusting Play while the assembly is stale.