It is currently not possible to create a save game object that contains a FSoftObjectPtr. In my case the object ptr indicates a checkpoint actor to respawn at.
Save games are serialized via
UGameplayStatics::SaveGameToSlot which in turn uses
FSoftObjectPtr can basically be expressed as strings but the archive does not support serializing it.
Is this intended behaviour?
FSoftObjectPtr.: Pointer to UObject asset, keeps extra information so that it is works even if the asset is not in memory
FSoftObjectPtr is a type of weak pointer to a UObject , that also keeps track of the path to the object on disk. It will change back and forth between being Valid and Pending as the referenced object loads or unloads. It has no impact on if the object is garbage collected or not.
FObjectAndNameAsStringProxyArchive: Implements a proxy archive that serializes UObjects and FNames as string data.
Serializing the address won’t work. You can’t just write down the exact memory address, because there’s no way to guarantee that objects on the next run will be able or not.
Serializing the pointed object in each place where we have a pointer wont work:
This would be a lot more data that we’d need to serialize
If we had weak pointers creating a circular dependency we wouldn’t be able to stop and retrieve that connection later.
There is no way to merge the same objects into one when deserializing.
So i suppose that it would be an intended behaviour.
I understand that the memory address to the UObjects and any UObjects that are not part of an asset but created at run-time cannot be restored via FSoftObjectPtr.
For the above case I am referencing an AActor in a ULevel. When the level is loaded, the actor will be instantiated and the FSoftObjectPtr can be resolved returning the new, correct memory address to the instance in question.
If the ULevel asset was changed and the actor question be removed, then the FSoftObjectPtr will never get resolved (which is to correct and expected).
The FSoftObjectPtr basically uses the Asset Path Name and Sub Object Path as a unique identifier instead of the object’s memory address. Considering this it would make sense that they can be serialized via FObjectAndNameAsStringProxyArchive since they reference the object in question in a soft manner via strings and names to begin with.
Kind Regards, Jacomi
I understand the point that you are trying to make and you are right about “Considering this it would make sense that they can be serialized via FObjectAndNameAsStringProxyArchive since they reference the object in question in a soft manner via strings and names to begin with” and you can do absolutely do that i.e you can serialize the “Path” of the FSoftObjectPtr by converting.So in short you can serialize the objects(FName) and the path’s(FName) used by the FSoftObjectPtr but no the pointer itself, here come the reasons i had listed above : Serializing the pointed object in each place where we have a pointer wont work: This would be a lot more data that we’d need to serialize If we had weak pointers creating a circular dependency we wouldn’t be able to stop and retrieve that connection later. There is no way to merge the same objects into one when deserializing.
The reason to not serialize pointers is because tracking where pointers are pointing and whether we need to serialize their data is a non-trivial problem. Consider a really simple example where you have an std::vector and some T * pointing to some items in that vector. We as humans can easily understand that the vector is managing this memory, but ue has no easy way of inferring this. With pointers a lot of machinery is necessary to prevent duplicate serialization this may add a completely unwanted amount of bloat to the library and the API.
PS : All of this is just a educated guess,for the actual reason i think it would be better if someone who’s actually worked on the UE4 Architecture with the source code can give a better explanation on the same.Hope you get the answer you’re looking for ^ ^.
Ok it seems that this feature is scheduled for release in the next version.
See Unreal Engine 4.21 Preview, the Core Improvements section.