Then once your switch actor has the Interface you can add to its graph custom Interface events that will be called by the plugin. Your setup currently doesn’t work because you are using BeginPlay instead of this Interface’s custom save/load events.
Hi Bruno, thanks for the info for the save file. One thing i noticed is when the (async) saving process is processing, and i quit the editor (or game) the game will crash… seems like a thread not being shutdown? Note that this is mostly when save files are large and so i can actually quit while saving.
There’s nothing I can do about that.
Interrupting a save process should be avoided, there’s a reason why most games warn players to not shutdown the system while saving.
A few things I have found while trying to get this plugin to work:
[BUG] Neither of the async Load Game World nodes (with or without callbacks) respect a custom slot file name - it will always look for the default file name (sync load, sync save and async save all respect this)
You cannot save without meta information if you want to do async load (even if you’re not using the meta file anywhere) - not sure if this is a bug or not, but it’s definitely counter-intuitive that I should need a meta file if it’s not used
If using sync load/save, do not set the output of New Slot Instance to a variable and use that variable to save/load - just drag the pin directly rather than creating a reference variable, or it may break it strange ways
If you have custom classes that inherit from Object rather than Actor, you will need to add them to the “Instance Scope” section of the “Synaptech - Savior 2 Settings” section of the Project Settings
Bi-directional references will create problems - if you have Actors that each reference each other, there is no discernable way to make this work; you either need to have a means to re-sync the references, or eliminate one of the references
As previously mentioned by Bruno, don’t put your save/load logic in the GameInstance if you’re using Save/Load Game World - this includes a copy of the game instance, and will crash Unreal (might be worth adding this to the docs at the start of the thread/FAQ)
Make sure you save then restart Unreal after changing anything to do with the save slot file or save/load functions before you test - weird things will happen
OK. I’m running into a weird problem where altering the Instance Scope using the ‘Savior 2 Settings’ in the Project Settings will interfere with another plugin (AdvancedSteam by Rocketwerkz) and prevent my project from compiling. Changing the settings also doesn’t seem to result in any changes to any [FONT=courier new].ini files being changed that are being tracked in my repository, so I guess I’m more wondering where these settings live at all. I know you can export/import a backup of the settings into an [FONT=courier new].ini file, but at the moment my project will not compile unless I only use the default settings for Instance Scope. I haven’t experimented with the other settings yet.
Your project might have things referenced from that plugin marked save game tag.
The plugin will try to auto respawn any object that is that scope list. If you don’t have a clear plan of which object classes you want auto respawn then it’s better to leave as is since that’s a very advanced deep control of the save system.
Usually if you want a class to auto respawn on load (UObject class) it should be a child of that default class in settings.
The only thing we were experimenting with the plugin was getting Stead IDs, we haven’t delved into the internals of the plugin to check what might be referenced for saving. I’ll have to investigate that later.
Is there anything in particular that’s needed to compile Savior into a Shipping configuration build? At the moment it works fine in a Development build, but results in a fatal error that crashes the game whenever I use a Shipping build.
Depends on which platform you’re building for.
Also without logs I have no idea.
What might happen is you trying to build for a platform that Marketplace team didn’t include any binaries of plugin for packaging (but the binaries for Editor are there).
In case like that the plugin should be moved to project/Plugins folder then uninstalled from Unreal launcher… Then when building the project Unreal should generate the new plugin binaries that are missing.
Is there something I can do differently with the build and then post/send to help troubleshoot this?
I have the plugin installed in the project/Plugins directory and not installed on the engine in the Unreal launcher. The Intermediate directory has a “Build/Win64/UE4/Shipping/Savior2” directory with a bunch of C++ files in it, so it looks like it’s building something. Telling the editor to do a full rebuild when packaging doesn’t seem to make a difference.
Shipping builds don’t seem to generate any Saved/Logs folder/files. Or did you mean logs from the build process? Happy to pick this up offlist so we don’t clog up the thread if you prefer.
The build process itself is not failing. It successfully produces a build of the game. When I run the game and then try to perform a save operation, it crashes the whole game with a fatal error. Doing the identical operation on a Development configuration build (which also does not error during the build process) correctly saves the game, no crashes.
Hi, im trying to change the default saving directory, using SetDefaultSaveLocation. In project settings i see its changed, however the files still got saved in /Saved/SaveGames. any idea how i would fix that?
The plugin doesn’t manipulate any path for save files.
It uses Unreal’s default SaveGame functions to generate the file written to disk.
If there’s a problem in there then it’s hard to say if it’s in plugin or something to be fixed in engine.
The slot object is attached to your GameInstance object while the slot is spawned and used.
If you do something to your GameInstance which destroy or invalidate it that could be a cause for crash on save or load… Other than that something in your project is causing memory access violation for whatever reason, in this case avoiding async/background thread could help you fix that. It’s very unlikely the plugin is causing the crash, but some code in the is acting upon objects that should be locked while the plugin save/load.