There are cases where it’s harder to use property access nodes and I’m trying to figure out if it’s worth the trouble.
For example, property access nodes themselves are still under the hood, taking the data on the game thread, and caching it.
So for something simple like velocity = characterMovement->getVelocity(), what’s the benefit of doing that in the threadsafe update using property access instead of just doing that in the regular non threadsafe blueprint update function? Is it really that much faster if property access is still caching it on the game thread earlier?
I’m also considering, should I mix regular update and threadsafe update? Like if I have a chance to put as much of my update code in the threadsafe update, but then if there’s like 1 thing that needs to go into the regular non threadsafe update, am I losing the benefits? Or are we supposed to mix them when we need to?
I have one function that takes a parameter, so it can’t be used in property access. And I’m trying to figure out, is it worth me adding a getter for that one specific thing that doesn’t take the parameter just so I can actually use property access or is it just doing the same thing underneath anyway even if I use property access, and I just added weird apis to my beautiful clean code?
General rule of thumb is you never get, you use pre-filled variables instead.
So in the character realm (since that is the forum you posted in) you make a character class, add all the variables you want and expose them, then set them to update or fill in.
From them on, everything else (like the animation blueprint) accesses said variable directly.
No re-mirroring and re-setting needed as it takes more effort and compute to transfer than to read.
With that, some vars are pre-filled by the original class you modify. Location, tranform, velocity etc. So you can and should access them directly.
The only real concern with characters is the fact your ABP has to have 0 code and you need to make sure you aren’t negating fastpath by complicating transitions with non fastpath accessible checks.
Because of that, it’s often better to create variables in the ABP and force the character to update the ABP variables directly. So Maybe velocity, location, etc is something you expose in ABP, update from character, and consume directly.
Make sense?
Also. Velocity is directly tied to input realistically. So if you are concerned about threads and having to set it, you can just solve it again by reading the input axis and multiplying by the speed allowed like the system does under the hood. Ofc this isn’t the same as re-reading it and won’t always work (like if you use root motion or a curve to set the velocity for instance). It is however easy to work out in other ways if you dont want to access the character movement component… is it worth the effort? Maybe? Maybe not? In the end it’s what you like better so long as you don’t violate best practice standards…