Do semaphores or something similar exist in blueprint

Does anyone know if there is any way of locking or sycronizing systems in UE?

I’m specifically thinking about the save game here.

For instance I have 4 towers with dials on them. Each tower saves it’s own dial positions after randomizing them.

To do this, it must

read savegame → update savegame → write savegame

Because of the beauty of modern multi tasking, there’s no way of knowing if tower 1 is in the middle of it’s save process when tower 2 starts it’s.

So we can end up in a situation like this:

tower1 reads savegame → tower2 reads savegame → tower1 stores it’s settings → tower2 stores it’s settings → tower2 writes savegame → tower1 writes savegame ( without tower2’s update ).

Centralizing the save for all 4 towers has plenty of downsides:

  1. You end up with a procedural actor messing your lovely object orientated tower code

  2. There’s no guarantee that there isn’t something else in the middle of save anyway

So my question is whether there is any way of locking or syncronizing processes in UE, or do we have to muddle through and hope for the best?

I’ll check out the async thing, cheers.

Dedicated tower saver doesn’t help actually, if you think about it :wink:

Interesting…

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.

True, but like I say, it has no way of knowing. You might very well want to clear the save game, it just doesn’t know.

I have the whole lot in a macro, so whever I want to read or write it, it’s just one node.

True, but like I say, it has no way of knowing. You might very well want to clear the save game, it just doesn’t know.

I have the whole lot in a macro, so whever I want to read or write it, it’s just one node.

( MANY macros mind you… )

I can confirm though, you do have to load and then save… :wink:

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?

Presto, thanks for your answer, but if you look above, we did sort it out.

The save game somehow magically processes things in a mutex, so it’s not actually a problem :slight_smile:

On the general concept of syncronization in UE, though, it would be nice to have something in BP.