it will retrieve the current Health
stat from the ThirdPersonPlayer via
the ‘input’ on the function and then
‘output’ this stat as ‘PlayerHealth’
(since I can’t reuse ‘Health’) in a
usable float that I can call in object
blueprints. I.e. the above interface
isn’t just creating a new stat called
Health?
This retrieves a copy of the data, it’s not passed by reference. We query, we don’t modify. If the returned value is modified by some other blueprint, it will not alter the original in the player. It’s the player’s job to modify its own data.
And that’s precisely what the implementations of Heal Player is doing.
Have a look at my example below. There the Medkit does not know or care what the player’s health is. It Attempts To Heal; the player then decides whether it was needed or not and returns results to the Medkit.
You usually don’t want to give other blueprints direct access to variables they don’t own. Generally speaking the vars should be private / protected and Setter / Getter functions of owning actors modify them upon requests from other entities.
If you want another blueprint to modify player’s data directly from the outside of that class, cast and set the var to the new value. The simplicity may seem tempting at first but as the project grows, this approach becomes less feasible and turns into a little debugging nightmare.
In the end, the choice is your.