s&box/field-guide
the symptom, in your words

"Everything broke at once — check for a stale assembly first"

✓ verified on engine 26.07lane: Tooling & environmentposted
▸ SYMPTOM

During a burst of edits (especially parallel agents):

  • Audio dead, features missing, old bugs back — everything looks broken at once.
  • Console may show Compile of … Failed / Broken Reference.
  • Or worse: compiler wedgedsuccess=False, 0 errors / 0 warnings, needsBuild=False — editor keeps the stale assembly forever with nothing to "fix."
▸ CAUSE

When the package compile fails (mid-edit, broken reference, internal compiler crash), the s&box editor silently keeps running the last good hotloaded assembly. Playtests then exhibit "regressions" from code that predates hours of committed work.

A related wedge: internal NullReferenceException / "One or more errors occurred" leaves compile status failed with no diagnostics and needsBuild=False — it thinks nothing needs rebuilding.

Also: Steam can update the engine under a running editor (mixed DLLs, stripped components on deserialize — do not save the scene in that state). First check sbox/.version mtime vs session start / appmanifest_590830.acf StateFlags.

▸ FIX

Before debugging multi-symptom chaos

  1. Grep the session log for Compile of / Failed / Broken Reference.
  2. If present → finish or revert the broken edit, get a clean compile, restart Play. Do not chase the symptoms.
  3. Wedge signature (success=False + 0 diagnostics + needsBuild=False): bump any watched .cs mtime to dirty the compile:
snippet
(Get-Item Code\SomeFile.cs).LastWriteTime = Get-Date

Then rebuild / alt-tab hotload; confirm clean.

Normal hotload expectations

  • C# edits apply in ~ms on alt-tab.
  • Network sessions reset on hotload.
  • Scene-file changes need a Play restart.
  • New assets sometimes need an editor kick.

After engine update underfoot

Relaunch editor, discard scene changes if components were stripped, verify dotnet build --no-incremental against the new assemblies before trusting anything.

▸ WHY IT WORKS

Hotload prefers "keep playing" over "hard fail closed." That masks compile failure as gameplay regression. Checking compile health first collapses a dozen fake bugs into one real fix: restore a current, successful assembly.

Verified on engine 26.07 — seen in a real project.
s&box moves fast; an undated fix is a liability. Spot a stale detail?