Oops, good job you’re on the case 
Yes, I’m using UE 4.25.3
That looks perfect, thanks!
Sorry, I have another question. I’ve noticed that USavior3::WriteSlotToFile empties the content of the slot instance data (it calls e.g. SlotData->Complex.Empty()). So it seems I can’t hold a slot instance in memory after I’ve written it to a file, I’d have to re-load it using ReadSlotFromFile if I want to continue to add to it. This makes it a bit more difficult to build up a combined save state in memory - although the Copy node would allow me to copy it out I guess.
What’s the reason for WriteSlotToFile deleting all the data in the slot instance? I’d prefer to have the choice of keeping that instance in memory if I wanted, or destroying it if I wanted the memory back.
[Edit]This is complicated by the fact that some things automatically call WriteSlotToFile so I have to be careful about what order I try to update the slot instance, because rather unintuitively it’ll lose all its data after certain calls I think?
Slots are UObjects, but they are not registered as property.
Which means eventually they are going to be garbage collected.
If you keep an instance to use the whole runtime session, there’s a point where Unreal will destroy the object and leave you with a dead pointer.
So you should treat slots as temporary objects and not a database.
The data is erased to prevent memory leaks after save.
I could make slots persistent and not collectible by GC, but that’s not the default behavior for any save system.
I don’t need you to make slot instances persistent, if I keep a pointer to a slot instance in a UPROPERTY UE won’t garbage collect it, and there’s a property chain from the slot (USavior) via SlotData to the TMaps, so all the references would stay alive. Similarly if nothing holds a UPROPERTY on the slot it should GC just fine, no memory leaks, so I don’t see why you need to forcibly empty it. After all if the user might never call WriteSlotToFile. It’s only if something holds on to a slot by accident that you’d get a leak? I’d just like the choice, deleting the data on write just seems too aggressive, especially as I can’t call SaveLevel without that happening even if I wanted right now.
It’s all tied up with streaming levels. If you only ever have one level it doesn’t matter, and switching persistent maps is a big enough load point that you can take the hit of reading / updating / writing without much impact. But when streaming you really don’t want to do more work than you have to during unload / load of a streaming section. I would like the choice of keeping data in memory so that I can save streaming levels that unload, and populate levels that reload, without hitting the disk.
A minimal solution to this might be not to change the WriteSlotToFile but to just give the option of whether SaveLevel etc call WriteSlotToFile or not. If I could turn that off it would solve my problem.
I can add a bool to the node to choose whether write to file or not, will do tonight when I get back to PC with plugin source.
Thank you again!
I submitted an update with changes to the save/load level nodes, and Epic already reviewed and pushed new version to Marketplace.
Thanks! I see the new Shadow Copy node, but the Save Level node doesn’t have any new options yet, perhaps there were 2 updates and the second hasn’t come through yet?
Hmm…
I have to check it with Epic.
There should be a boolean checkbox there, seems like I sent them the earlier package instead of latest change :s
I resubmitted latest changes, better than waiting for them to see what went wrong there…
Marketplace should have the latest update now.
There should be a checkbox on “Save Level” nodes to write file to disk or not on save.
Yep, boolean is there now. Thanks!
Hello,
Just have a strange behaviour.
For my game, I save and load data using save level and load level function. Everything is ok.
For a specific reason, I need to save separate variable to be “independent” from the level saved and loaded. These are variables that must not be saved in the user slot, because contains variable that has to be valid whichever slot I decide to load (i.e. overall game time)
To do this, I put this variable in the custom game instance of the game. I tried to create a specific slot and trying to save with the save game instance function, but no file is created. The function is run from the game instance itself.
In the specific savior 3 slot, I added as the object scope the custom game instance. Only this, but it doesn’t save anything.
Any idea in regards to what I did it wrong?
UE4 version is 4.25.4.
Make sure you are running nodes on a slot instance, and you call “New Slot Instance” based on a slot asset and not another instance.
A “failed” pin may return if you are mixing those things above.
I tried…
Here below how I’ve done it (both with async and with callback function)
Both of them will not save the requested file.
If I use the call back version, the print string linked to the “Began Save Callback” is fired with the print string showed. The print string linked to the “Finished Save Callback” is NOT called.
If I use the async version, the print string linked to the On Success and On Fail are both NOT called.
In both case the New Slot Instance node is firing via the Success pin to the save game Instance nodes…
Oh… If you see the description of Async nodes, you will see that the they marked (Async) already create their own instance.
This was requested by a few users… So you actually do not pass in an instance to Async nodes. You just pick an asset from it’s drop-down list.
Anything not Async needs a slot instance.
To clean up what you did there, you will probably have to restart the editor, since delegates got stuck.
Thanks for the clearification. I restarted the editor, and run only the callback version with the new slot instance node feeding it.
No changes. No save file. the began callback is fired, while the finished callback not… And obviously no file is saved.
It is really strange…
PS This morning I’ve updated your plugin to the last version, just for your information. But also updating was not helpful…