Alright, then next question - I already have Savior 2. Why would I want to use USQLite Database instead of Savior 2 ? (let’s say in the game I am working on I will have some RPG elements like quests and stats, but nothing even close to the scale of Skyrim)
Savior system is better for offline games.
uSQLite plugin was built to be expandable and safe for dedicated servers (where you own the server hardware) and online games, but can also be used on offline games as well.
When you build a C++ project in dedicated server mode, the uSQLite plugin is configured to generate DLLs, but when you package a build in Client mode then all its functions will not be generated to the Client, so online games have the security measure of making sure that all the save system is not present on any released Client binaries, while Server have a save system that works pretty close to what Savior plugin does.
Hi [USER=“434”]BrUnO XaVIeR[/USER] ,
Getting my feet wet with Savior 2 and I have a question related to the MarkDestroyed functionality. I have an actor in Level 1 (placed via the editor) that has the ‘Destroyed’ variable set and SaveGame tag. When it gets picked up it is flagged Destroyed = True. My player character can then overlap a trigger volume in the level blueprint, which calls the Save Level function and goes on to load Level 2:
In Level 2 I have another trigger volume that send the player back to Level 1. This triggers the ‘Event BeginPlay’ for Level 1, which looks like this:
What I’m seeing is the following:
Player picks up item in Level 1 (marking it as destroyed).
Player transitions to Level 2 (after level is saved to slot).
Player transitions back to Level 1 (level is loaded from slot).
Item that player picked up is NOT in the level (all good here).
Player transitions to Level 2 again (level is saved to slot again, overwriting previous).
Player transitions back to Level 1 (level is loaded from slot).
Item that player picked up IS back in the level.
I would expect the item, since it is destroyed, to never appear again. But what I’m assuming to happen in this scenario is that since the item is not in the level the second save to slot writes no information about it being destroyed (and the previous save information is overwitten). Thus on the next load it will reappear.
Is this expected behaviour (bug?) or am I doing something wrong with how I destroy an actor/save/load level?
I will check plugin code to see if there’s a bug.
But when you overwrite save data, the pickup from Level 1 is no longer saved into the plugin’s list of destroyed instances in the slot… This is why you see it come back.
I think if you have to overwrite slot data often maybe you should create a pickup list and force them delete after load, since auto destroy information is lost by the slot.
Certainly seems that way. I wonder if the SGUID ‘create once’ function could be enhanced (or a derivation created) to keep it the same no matter how many times a level is loaded. This could then be used as a pickup list, as you mentioned. However, right now, the SGUID that is created is different for an actor every time a level loads, understandably. Just a thought, it would save a bunch of time over keying actor references by hand.
That said, I cannot see how useful the MarkDestroyed functionality is. We’re saying that it will only destroy items you flagged as destroyed on the previous play of the level as long as you never save the level in the same slot again. I hope it can be improved! 
A new Sguid value is only generated if the actual guid value is invalid.
If you apply manually a fixed Guid value to it then the node in constructor should never replace that Sguid value you already have.
If you spawn an Actor with a 0000-0000 etc, invalid guid value, then the node triggers generating a new one in constructor.
This is mentioned in a previous post and I totally forgot about it! Just tried it and it works, this will save me a bunch of time. What a great little utility. Thank you!
What is the difference between the standard GUID and these plugins SGUID?
Several internal C++ systems in the plugin use code reflection to lurk into your blueprints and see if a “SGUID” property is present.
The difference is only in the name of the GUID property, if a FGuid named “SGUID” is present the plugin assumes you want that Actor/Component to be taken into considerastion for auto-respawn and/or auto-destroy sequence of actions every time a level is loaded.
Also the plugin has nodes that can load an Actor instance from a slot based purely on these “SGUID” properties instead of relying on ObjectIDs
(perfect for inventory systems).
I submitted the plugin version for Unreal 4.24 and, due to severe and very deep changes to how the engine generates object IDs in 4.24 when the project is packaged in Shipping mode*,
I recommend you guys to setup the “SGUID” property in your Blueprints that you spawn at runtime even if you don’t want them to auto-respawn from SGuid.
- Epic is now attaching random integer suffixes to Actor IDs whenever they are spawned in runtime, so now I completely ignore those IDs and only check for base names + SGuid if your Actor have any.
That in general means that save files from previous engines will not be compatible with saves from UE4.24+ with this plugin, or they won’t be completely compatible.
So in case they change something again in 4.25+, will newer version of the engine be compatible with 4.24.x saves ?
Yes, because with SGuid property you generate yourself the “ID” suffix attached to class names, so it doesn’t matter anymore whatever Epic does to internal object IDs.
Because you’re not supposed to do that.
You have to create an instance of your slot and then you use it. There’s plenty examples in this forum topic, for example this one:
https://i.imgur.com/XyIp9ci.png
My bad, thanks a lot for your explanation. Works great now
[USER=“434”]BrUnO XaVIeR[/USER] is there a way to make the saves compatible? We have an existing game on Steam that has beta testers with their own saves. I’m only using the game instance and nothing else for saving so hopefully there is a way since the change is for runtime actors, right? I have a source build too. Will compiling an older version of the plugin work?
Compatible with what ?
The default save system?
Sorry, I meant for 4.24. We recently upgraded the engine coming from 4.21 so now the saves are not compatible in a packaged build. I was hoping there’s a solution for it since we’re only saving variables from the game instance and not saving spawned actors.
We need to make the old save files (Savior) compatible so that our beta testers don’t lose their save files.
I’m using a source build so I can recompile the plugin if needed.
GameInstance didn’t change anything, they are still saved and loaded the same way.
Even after changes Epic did to packaged builds you should be able to load any old save files if all you save is GameInstance property.
Unless you change its class.
That’s what I was doing but the game instance and all of its properties aren’t being loaded from the old save file. I’m using “Save Game Instance” and “Load Game Instance”. I also tried using “Load Game World” but that only loads the last map I was in and the game instance’s variables are still at their default values instead of what was in the old save file.
I think it fails to read the old save file.