Thank You @RianeN and @OverRated_AU especially for your help in this thread!
And Thank You @rdeforest for sharing your research and code with us!
I am still investigating the World Partition issue, as @OverRated_AU mentioned.
I am hoping 5.3 opened something up in this regard.
@Tonakien @sparkness1179 @s54780478
Saving Actors and UObjects
Regarding questions about saving actors / uobjects,
I made a Feature Design Choice to not serialize entire actors/objects with all their data (which often does not need to be saved as most of it never changes).
The focus here is on maximizing File Size Reduction <~~~ by not saving data that will never change during runtime.
Instead, you have the ability to save individual properties of any actor or ubject being used by a main actor who has the Rama Save Component, and then reload this runtime state after a load has occurred.
Conceptually, you can ask yourself “What data really ever changes during runtime and thus has to be saved/reloaded ?”
You can then organize this data into a UStruct like a SubActorSaveState or SubObjectSaveState for each actor or object that a main actor is managing.
You can recreate the actor (Spawn Actor) or uobject from its class using construct object (in the ActorFullyLoaded event in Rama Save Component).
This is where the fast majority (usually upwards of 98%) of the data that does not really have to be saved, gets recreated, and continues to never change during runtime (Ever).
Then, 15 actors or objects managed by a main actor with the Rama Save Component simply store an array of the SaveState UStructs, and for each save state, you recreate the appropriate Actor/Object, and apply the save state data, to recreate Your World!
Some amount of Blueprint coding logic and planning is required here, all toward the goal of having:
The Smallest Possible Save Files Ever
in The Gaming Industry
<~~~ Storing Entire Worlds in less than 1kb
Rama