To be fair, I never actually did witness this problem with the save game, I just figured it would happen sooner or later. I just spent a while pressure testing the save game update and found, in fact, it wont do this.
I can’t get the save game to update inconsistently, even with large number of actors writing simultaneously.
I have absoltely no idea how that works…
Can you change your comment to an answer, because I think it’s also relevent. I think the async versions are for when you have a lot of data to write and don’t want a hitch.
What about Async save and load? Aren’t they used to see if save/load is completed?
I never used them, that’s what I understand from their description.
I personally would probably end up creating a dedicated save game blueprint for tower properties and assigning different save slots to different towers. Not really efficient, but at least I’d have full control over them. Then again, I have little experience with such stuff.
I don’t know the underlying mechanics of how saves really work in UE, but it seems to me that saving to a slot only affects the altered variables. What I mean is, you don’t really have to load game, change a variable, ans save it back. You can create a new save object of the same type, set one variable, and save game, and the remaining variables won’t get defaulted in the resulting save, they will stay the same from the previous time you saved the game. Maybe the variables are marked dirty the same as any changed video settings, and only dirty variables get updated; that would explain why lots of actors can simultaneously update a single save file with their own variables without affecting the remaining ones, and everything just works.
That’s just my theory; It would be great if someone from UE Staff could give some in-depth explanation.
I guess you have to look at the code ( life’s too short ).
I did a test with 8000 actors all updating the save game with unique IDs and reading them back.
Works absolutely fine with the normal nodes, apart from a big hitch.
Does not work at all with the async nodes… I can see the async in operation, but it ends up making a mess of the save game.
Could well be something I am missing.
I didn’t know that about only having to write update variables. The logical thing to me would be to wipe the hole slot with the variable you give it. I mean, if I give it a toally virgin savegame, how does it know not to write zeros over everything…?
Just tested it again and yes, I was wrong. The remaining variables do get defaulted after all if you create a new save object. I need to go review my blueprints now =)
But I actually think it would be a great option to only update dirty variables. Creating a new save game object is more convenient than loading the existing one and casting to the needed type.
How about a save function that loads the existing saves of all other objects on the new save, or all other target objects / types, and then caches the new save for when the next or a new load is initiated?