You realy want that to work in editor when back from game!!!
Yes that’s not needed, but you’ll understand better doing it yourself and see a little option in elementSetting that can be used as a trick for getObject.
– Change his baseClass to Actor_DTAe.
– In viewport, change the ElementID as following :
– ArchiveID identifier : willbevirtual_b4
– identifier : lever.
– Uncheck Edition Mode.
– Open settings and set No Remote to true.
Look at what this does looking tooltip.
That will have the following effect :
Because it will never be serialized in our case, and because even if you save instance an empty archive will not create file, then this archive will be virtual, never have data, just weak reference to our lever.
But the fact is now you can use GetObject on this element. You won’t be able to get it while not loaded because it is never saved but in our case it’s just what we want.
– Open the function SetLeverPosition and remake it using GetObject,
– Set your ElementHash (or other var type that will create the ElementID) instanceEditable and savegame because it’s objectSpecific and we want our generated object be able to access the lever.
– Remove the softObjectReference.
You can see how it’s done in SetLeverPosition_Done if needed, only the ElementID is missing, two version avalaible.
Now all is working fine.
In this exemple, we serialize each time the state change (door), but we only write to file at endPlay. Our save node is in BP_Master_B4.
In fact datas are cached, that use memory but give very fast serialization because there is no file access during gameplay.
Cached data are stored in a DtArchive, there is two situations where cached data are cleaned:
– If you call UnloadArchive. (UnloadInstance or changeInstance will unload all archives in current dynamic instance)
– If the archive is Destroyed.
You cannot manually destroy an archive but if autoDestroy (ArchiveSetting) is true, the archive will selfDestroy when there is no more valid elements registered in it.
When an archive is not loaded, it take very low memory.
Autodestroy In our exemple :
– Autodestroy to false : When the door’s level is unloaded, datas are still there, when the door is back and deserialize, there is no file access.
– Autodestroy to true, archive is destroyed when the door goes out because it is the only Element in this archive and when it is back, the archive is created again and file is loaded again for deserialization.
When you will make your savegame system, you’ll need to correctly think how you want to handle cached datas. There is a infinity of choices, it is project specific.
– If you want no cached data, prefere little archives.
– For games using levels step by step, a cached archive by level is not a bad idea, will depend of the size.
– For rpg like, you will certainely mix up archive’s type but keeping data that are often use together in the same archive is better, using box trigger for load/unload can be nice.
Some options in archive Settings :
– “Never cached” wich will access file each (de)serialization.
– “AutoUnload” wich will be a timer setting, the archive will stay in memory until this time is ended if not waked up (no (de)serialization).