the symptom, in your words

"A green compile status does not prove the new assembly loaded"

✓ verified on 26.07.22
lane Tooling & environmentposted

▸ SYMPTOM

  • The editor reports a clean compile for both compilers: Success: true, NeedsBuild: false, for the game compiler and the editor compiler.
  • The compilers are demonstrably live. A deliberate syntax error flips both to red with the correct file and line within about 10 seconds, and reverting the error flips them back green.
  • Yet the project's own tools do not show up, a component type from the project does not resolve, and both edit mode and play mode report a missing component.

▸ CAUSE

A green compile status is necessary but not sufficient evidence that the running assembly is the one you just built. This is a third failure mode, separate from two others already on record. It is not an outright compile rejection, where the compile fails and reports the error. It is not the internal compiler crash, where the status reports failure with zero diagnostics. Here the compilers report clean success and are live, but the loaded assembly is stale.

The case was measured live after a project folder rename. The usual file mtime bump recovery did not help, because the compiler itself was not stuck. The stale state came from leftovers of the old name: the old project's save-data folder, old files under the engine's .vs/output/, and old compiled asset variants.

▸ FIX

Recovery from the rename case needed a full editor relaunch, plus clearing the stale leftovers before relaunching.

  1. Close the editor.
  2. Delete the old project's save-data folder.
  3. Delete old files under the engine's .vs/output/.
  4. Delete old compiled asset variants left under the previous name.
  5. Relaunch the editor.

The recipe generalizes to every stale-assembly case, including a plain post-merge build. After any merge, rename, or editor reopen, do not trust the compile status alone. Confirm the load with a symbol that is new this session, never one that existed before the change.

▸ WHY IT WORKS

An old symbol resolving proves nothing about whether the new code loaded, because that symbol is present in both the stale assembly and the current one. Only a brand-new symbol resolving is evidence that the running assembly is current.

So query the editor for a component type you added this session. If it resolves, the new assembly is live. If it does not resolve, the assembly is stale whatever the compile status says.

Verified on engine 26.07.22: seen in a real project.
s&box moves fast; an undated fix is a liability. Spot a stale detail?
changelog
  • Published

Want to know when new guides or fixes drop? Join the community to help build this out. Report gotchas, flag outdated fixes, or just lurk.

Join the Discord