I’m noticing that if I hit save at the beginning, then my actors will never appear in the list of saveable actors.
Also now if I press the load actors debug key, it will load 1 actor if I spawn a different one of the same type first…
its pulling that single chest from memory or something because even if I delete my save files and load, the same chest appears.
It’s the same catch-22 with your chests.
You are not figuring out the correct way to identify them once you have spawned one of them using “Spawn Actor” node.
Think of SGuid as an Actor name that you can edit at runtime if needed.
but it doesn’t seem like the SGUID is saving. I’m setting the SGUID on the Chest, and adding them to an array on the Actor from the chest itself. when I try to load, from the SGUID that was given to the maincharacter from the chest. it does not load.
I’ve narrowed it down to these 2 screens.
oddly enough, it “Says” its loading. but Its not appearing.
After reading in to it more, its loading the chests. but it’s not recognizing their positions, I forced it to spawn regardless just to see whats wrong and the location is set to 0,0,0 on all of them
You should reset chest transform after loading.
I have no idea why it’s transform is saved as zero vector there.
resetting doesn’t seem to have helped. I’m going to package up the project and try and email it to you.
Hey Bruno I am using Saviour in 4.26 and added the function:
virtual void OnLoaded_Implementation(const FSlotMeta &MetaData) override;
to an actor many of my blueprints inherit from and now unreal crashes after compile when it tries to hot reload. If I comment this out it works fine.
Are these functions now blueprint only?
Ok.
Is there a way short of adding the plugin code directly to my source and recompiling with custom logic so that I don’t have to reparent the BPs with a ‘middleman’ BP that has the “on load” logic? Just trying to do it the most time-efficient way possible that also will work moving forward.
Thanks Bruno!
Fleece_Cardigan Actually if you email me your cpp code and your crash log I could have more clues about what may be happening there.
I just installed the latest version of Savior from the Marketplace. I wanted to start with simple transform saving to restore actors positions. Sadly, I can’t get it to work. The actors are not spawned dynamically, they are placed on the level in the editor - so I guess it should work out of the box, but it doesn’t.
At first I thought I was missing something but then I downloaded the test project (Savior_3.2.0_Demo_UE4.26), ran it in UE 4.26.1 and observed the same behavior - the mannequins don’t have their positions restored after load. (HP and other stats are restored though).
I tried the other test project (Savior_3.0.0_Demo_UE4.25) on UE 4.25.4 - with the same result. Additionally there’s also a compilation error in one of the BPs.
The last thing I tried was running the 4.26 test project on another machine. The result was similar to what I described above, so it’s not a matter of my configuration.
Can anyone confirm this? Bruno, do you have any ideas what’s going on here?
Heya, sorry for newbie question (im still learning): i was using free Save Plugin and all i had to do to make it work set checkbox SaveGame in variables inside my blueprints and then use function to save and load them.
In general this plugin works same way? Can i just checkbox needed vars and then use functions to save and load them?
I have seen function called “Save world” or something like that. Is that what i was think it is? Its saving everything from the world?
Thank you!
@jackthejazzcat this system expects you to setup your own actor save ID (so complex projects can customize the plugin for their needs).
Besides checking “Save Game” checkbox on variables, you have to create on your classes a property called “SGUID” if type Guid then generate an unique value that will identify instances of your class at runtime for the save system.
Or you can ignore that and simply use “Save Game Mode” function that will automatically save a record of your Player Controller, Character, etc, all members of current Game Mode group of classes.
OK, so I missed that the SGUID property is now obligatory for all actors which need to be saved. After adding the property I was able to save/load in my project. Bruno, thank you for your quick replies via PM!
That being said, the demo level doesn’t present the same behavior as shown in the official youtube video. For example, the balls on Level 1 have their positions restored on the video and that’s not the case in the actual demo level. It may be confusing for newcomers.
Also I’d love to see some form of basic documentation extracted from this thread. There is a lot of useful info scattered across 49 pages and it would be awesome to make it more accessible.
I can add a Actor Tag “!Guid”…
So static mesh actor instances that have that tag would load data from slot regardless of SGUID existing or not.
Keep in mind that in this case you are responsible for giving each instance a unique name label, or they will just overlap each other’s transforms on load.
I will experiment with that next weekend.
And documentation, one day I will develop one when I actually learn how to build a website, I don’t have funds to hire a web developer ^^
Oh, for me it’s OK to use SGUIDs - I’ve added it in some of the base classes and it works flawlessly. I’m not sure the !Guid tag is needed.
I’d rather go for a basic documentation. 
If you don’t want to work on a website I suggest creating a GitHub repo with a readme. You get a nice landing page with simple formatting and I believe it can be set up in one evening (using info and screenshots gathered from this thread). There’s also an issue tracker and a Wiki included which may come in handy.
Hi Bruno,
I am seeing the same behaviour that Andrea66 mentioned, where if you add a frame delay of 0 after a Save/Load Level Async call, both slots (for multiple levels) will save. If you remove the frame delay, the first save will work - but the second will immediately fail.
I was just wondering if there was a fix for this yet or if I need to continue with the frame delay fix for the time being.
Thanks
Example of my logic:
Hello,
I’ve tried to bind to *USavior3::EVENT_OnFinishDataLOAD *in C++ and noticed that it is not broadcasted on a correct instance of Savior3 when calling USavior3::LoadGameWorld with ResetLevelOnLoad set to true. It seems that this is the culprit:
if (const_cast<USavior3*>(this)!=System->StaticSlot) {
if (SlotMeta.SaveLocation!=Context->GetWorld()->GetName()||ResetLevelOnLoad) {
AbortCurrentTask();
//
**USavior3::ShadowCopySlot(this,System->StaticSlot,Result);**
UGameplayStatics::OpenLevel(Context,*SlotMeta.SaveLocation,true); return;
}
}
USavior3::ShadowCopySlot doesn’t copy the delegate bindings.
After this discovery I looked at the code used for blueprint nodes to check if there’s any workaround for this, but no, there’s none. The delayed flow outputs of [SAVIOR] Load Game World (Async) don’t work when **Reset Level on Load **is enabled, confirming that it’s buggy.
@OregaHDD To start a new save thread, you have to wait for current thread to finish it’s task, unless you set slot used to run in synchronous mode.
@podkova.covenant I don’t know if there’s a solution for that, everything is interrupted for a new level about to load.
If you want to bind to slot delegates, I would probably try to bind into StaticSlot’s instead and see if that works.
Best thing to do is simply use Serializable Interface’s events instead.
Binding to the event from the StaticSlot instead of my slot instance is what I did as a workaround - and it does the job. I marked this as a hack in the code base, because I wasn’t sure if that’s a safe solution. Looks ugly, that’s for sure. 
I might try using Serializable Interface, thanks for the suggestion.
But that’s a fix for my C++ code, and Savior’s blueprint node mentioned in my previous post is still broken. Do you plan to introduce similar workaround to the node’s code?
The node cannot execute flow from there.
A level will load, there’s no level anymore to continue execution of that graph, and the engine will not resume a graph from where it was once a level is reopening.
I don’t understand why you say that’s broken.
The engine is doing the right thing.