Then I need you to delete your log files from project/Saved/Logs… then enable logs in the slot, try to save once and send me the newly generated log file from the Saved/Logs folder:
Did it and sent you via mail…
Bruno, I did some tests and I discovered something…
Pls hold on and wait to analyze the lo file that I finish the tests and I’lll post the results, because maybe this can help you understanding (and maybe discover that I did something wrong).
The async node should not let users mess things like this.
I am thinking a strategy to make the node adapt to whatever input the user insert there and never fail.
I miss qhat you mean with mess things like this… Is it related to the log file I sent you?
So, this is the complete saving function I did.
As you can see there is first a call to a save level function with callback.
Once this is finished, in the callback function, I run the save game instance with call back.
As I mentioned before, this was not saving the game instance file.
If I then disconnect the save level and connect directly the save game instance, the save game instance is correctly saved.
So, it seems that 2 savings (one for the level and one for the game instance) one after the other will not work, doing only the first saving but not the second.
Maybe this is not acceptable by your plugin concept.
I did a last test with a small delay before calling the second save (Game instance), and in this case seems to work. Both file are saved!
Another small issues I found, is that if I run a saving with the callback, creating the new slot instance before it, the filename is not the one inserted in the “Slot File Name” field, but it fall back to the slot Asset name, even if it is not empty…
No, I am adding a check to async nodes to see if the slot is an instance and its world pointer is valid.
If not then create a new instance.
This in theory will prevent users from create an instance of another instance or try to store data into an slot that should be instantiated first.
This is what caused the problem you have with that node.
If you want to run multiple save/load on the same slot you have to wait for the one currently running to cleanup itself**.
It’s a mistake on my side to let the callback “Finished” to fire before that slot is actually fully clean after save.
I will see if I can make that work better.
- (unless you run the save in main thread, instead of as a background task on slot asset settings)
In case of background task (default), use “Get Thread Safety” to check if the background thread has actually finished its work before starting a new process on the same slot.
Yes, I was also interpretating the finished as the event where everything is finalized.
I’ll check the get thread safety option and also the synchronous task to check if this will be helpful (I do not like to leave a delay as a solution)
By the way, just to be sure that you got my concept, I’m not starting a new process in the same slot, but a new process in a different slot…
Last, remember pls to check the issue on the filename not correct in case of new slot instance. Is not a big problem at all, but it is strange…
I’ve to review my previous sentence regarding the filename "Is not a big problem at all, but it is strange…"
It is important. I just relaize now. If I save via the callback function, and the file is not named as it is planned in the slot settings, re running the game, if I check with “Does save game exist” using as an input the “Get Slot File Name” from the slot itself, it will give a false results, and therefore will not load anything.
I hope this can be solved easily…
Just for your info, here below a slot settings and the name of the saved file that do not match (it will fall back to the default)
World_Of_Rohim is the name of the project
Save_Slot_1 is the name of the slot
Okay, will check that. Name string might be lost on slot instantiation process.
Thanks for the support!
Hey so our team just bought this plugin and I started messing with the demo to get an idea of how it works. Not sure if this is a bug or not, but when you load a slot for the first time it appears to work correctly, however any subsequent loads of the same slot without saving appears to fail and no character or actors are spawned in the level. Is this expected or is the Savior_3.0.0_Demo_UE4.25 not complete?
Load results depends on whether you are resetting the level or not (before loading).
Actors already respawned on load will not spawn another copy with same ID if that ID is already existing in world.
@Andrea66 That is really a problem caused when the level changes (the slot is destroyed then copied to a “static” slot) and loading new level.
When creating the static copy of slot records, to load when new level was open, I actually forgot to copy the “Slot File Name” to the temporary copy of the slot data.
On my end the static copy is now correctly looking for the name you have input for “Slot File Name” field.
I will pack a build and send (3.0.5) update to Epic for review:
Hmm so I’m just running the demo unchanged, which calls LoadGameWorld with ResetLevelOnLoad set to true which would suggest that this behavior shouldn’t be happening?
Could you please show me a video of that?
I have never experienced what you describe above.
[USER=“434”]BrUnO XaVIeR[/USER] Is Savior 3 for 4.26 going to take advantage of Zen Loader ?
Thanks Bruno. As soon it will be available, I’ll updade it and check if everything is ok ad give you a feedback.
This is a video demonstrating the bug I was talking about where subsequent loads of the same slot and level don’t work. This is with an unchanged Savior_3.0.0_Demo_UE4.25.
