On a large modded character class derived from SCR_ChimeraCharacter, with many modded class extensions contributing instance fields, adding 6 additional instance member fields made every character spawn crash natively.
Access Violation, illegal write in VCRUNTIME memcpy at address 0x40, during SpawnEntityPrefab of the character prefab.
The crash log ends inside the engine's spawn handling with no script frames of the newly added code. The script log before the crash is clean.
Script validation passes. The crash only occurs at world start when characters spawn.
Empirically it is the instance layout that matters. Declaring the exact same 6 fields as static instead of instance members made spawns work again. Method count and RPC count were ruled out as the cause by separate testing.
This looks like a hard limit or an allocation defect in the script VM for the combined instance size of a heavily extended entity class. There is no compile time or load time diagnostic, just a deterministic native crash with no actionable information.
Steps To Reproduce
Create a SCR_ChimeraCharacter-derived class and extend it via many modded class blocks, accumulating a large number of instance member fields (several hundred).
Keep adding plain instance fields. The type does not appear to matter.
At some point spawning the character prefab crashes the process natively as described.
Change the newly added fields to static and spawns work again.
Additional Information
Expected behavior:
Either no practical limit on instance members, or a clear compiler or loader error such as "class X exceeds maximum instance size" instead of a native Access Violation at runtime.
Why this matters:
Total-conversion frameworks carry a lot of per-player state on the character class. The current behavior turns an ordinary "add a field" edit into a potential full-server crash that passes validation and cannot be diagnosed from the crash dump. A documented limit plus a proper error would already solve the worst part.