Animation Blueprints: Property Access out-of-sync

[Abdugani]

Hello! I was following a locomotion tutorial on YouTube. Everything started to fall apart when I got to this part. In the series, BlueprintThreadSafeUpdateAnimation and PropertyAccess are being used, and the overall locomotion system resembles Lyra’s locomotion system.

The issue is when transitioning to the Start state, the function bound to OnBecomeRelevant, SetUpStartAnims, gets outdated values, or at least LocomotionDirection is not correct. The Start state needs to select its animation based on LocomotionDirection. The LocomotionDirection variable is set to Forward by default. So when you go, for example, to the left, PropertyAccess in SetUpStartAnims returns the previous value - Forward - so most of the time the wrong animation is selected. The author says it’s a single-frame delay and that he could not understand the source of the problem, saying Lyra did the same thing, but for some reason, this doesn’t work here. He solved it by checking if the current sequence is the right sequence every frame, OnUpdate.

This user, Pulciu, in the comment section, solved it by using the PreviousAcceleration2D, not the current Acceleration2D, length to determine if accelerating. Transition to Start happens when IsAccelerating is true.

For me, it’s somewhat of a workaround. It did work, but I gather the user decided not to use a hip-aware system, meaning HipFacingDirection changes based on DesiredHipFacingDirections. It’s preferable to face the hip to the desired when in Start, so SetHipFacingAsDesired was bound to OnBecomeRelevant of LocomotionLayer_Start.

So now, even though we solved the problem with LocomotionDirection, now HipFacingDirection is out of date. I think the Start state “screened” the variables before setting HipFacingDirection.

This problem seems so trivial, but I couldn’t find any solution. Maybe I’m missing something.

I thought maybe by setting updating LocomotionDirection before checking if accelerating would do the trick, but changing the order didn’t help.

[Abdugani]

Never mind, I found out that the variables you want to be synchronized should be located in the same function. In my case, the LocomotionDirection and IsAccelerating variables were in separate functions. I moved the LocomotionDirection calculation code inside GetAccelerationData, and now all is synced. But, I couldn’t synchronize HipFacingDirection when the Start state becomes relevant.

[Abdugani]

This was an oversight on my part. I forgot to remove the workaround code. Dumping everything you need to one function does not help. I don’t know how Lyra’s achieving data synchronization.
I’ve found that in the Lyra project, Property Access’ call site is set to ThreadSafe. It sets it automatically. Call Site is set to Automatic

In my case, it’s also set to Automatic, but it always sets it to Pre-Event Graph.

I have tried to change it manually to Thread Safe, but it gives a warning and sets it back to Pre-Event Graph.

The warning is:

Property Access ‘K2Node Property Access 25’ is not thread-safe, access will be performed on the game thread (pre-event) graph and cached.

The functions these nodes are called in are thread-safe.

[Abdugani]

My problem was that I didn’t set Thread Safe in the options.

But now, everything is broken, not only the Start state.
I noticed that in my project you can view the value by hovering over the node.

But in Lyra, it says it’s not in the scope.

[Abdugani]

I solved the problem.

1. Property Access must be Thread Safe.
2. If after changing it to Thread Safe nothing works, replace old Property Accesses. Maybe refreshing nodes will help as well, but I haven’t tested it.