SeniorDebuggingRareNot answered yet
What reflection traps make Live Coding / hot-reload unreliable for UObject changes?
A developer adds a new UPROPERTY to a UCLASS, applies the change through Live Coding (Ctrl+Alt+F11) without restarting the editor, and the patch succeeds — but moments later the editor asserts. The log reads:
LiveCoding: Patch applied successfully (1 module).
...
LogUObjectGlobals: New UPROPERTY 'AmmoReserve' added to AWeapon
Assertion failed: !Object->IsUnreachable() [GarbageCollection.cpp]
Fatal error: object referenced but not visible to the reference graphDiagnose the cause.
Live Coding patches machine code in place but cannot rebuild reflection: a new or renamed UPROPERTY, a changed UCLASS layout, or an altered vtable need a fresh .generated.h from UHT, which only a full editor restart applies. Patching anyway leaves stale vtables, properties the GC and serializer cannot see, and often a GC assert. Header and CDO changes always require a restart.
- ✗Adding a
UPROPERTYduring a Live Coding session and expecting it to be GC-visible - ✗Assuming Live Coding reruns UHT, so reflection metadata stays in sync with the patch
- ✗Treating a hot-reload GC assert as random instead of a stale layout symptom
- →Which kinds of edit are genuinely safe to apply through Live Coding?
- →Why can a stale vtable survive a patch and cause a wrong virtual call?
