Ambiguous wording in Supported Property Types ReadMe section #131

Activity

1. sinbad commented on Oct 21, 2025

   

   sinbad

   on Oct 21, 2025

   Owner

   More actions

   I'm struggling to remember now, I haven't used SPUD myself for a couple of years due to our current game not needing world saves. I suggest you try it, that's all I will be doing to figure it out ;)

   👀React with 👀1Reacted by Chuck
2. iron-CK commented on Mar 9, 2026

   

   iron-CK

   on Mar 9, 2026

   More actions

   The SPUD documentation, after stating that Maps, Sets, and arrays of UObjects are not fully supported and must go through SPUD's CustomData methods, then claims:

   Arrays of custom UStructs should be ok though.

   Yet the actual source code contradicts this:

   bool SpudPropertyUtil::IsNativelySupportedArrayType(const FArrayProperty* AProp)
   {
       // We only natively support arrays of non-custom structs
       // This is because we're relying on iterating through the UObject's properties and looking up from the state data,
       // and to support this with all the issues of backwards compatibility would require such detailed offset data that
       // it would make the whole thing very unwieldy. Arrays can only be primitive types or builtin structs
   

   So TArray<F_CustomStruct> will fall through to the opaque binary serialization path. The opaque path serializes the entire TArray<F_CustomStruct> as a raw binary blob via Unreal's SerializeBinProperty. This binary format encodes the struct's fields sequentially with no versioning or name-matching. If this Custom Struct is then altered in any way, loading a save game file will cause a crash.