I’ve been trying to get this value, that changes ‘live’ as you use ammo in the game to be able to be stored somewhere and change in real time - but take this value and use it in the Player Blueprint so I can use it to determine conditions on the go.
But no matter what I try, when I get that value printed outside the HUD, it is never live - for example, the Total Ammo is a fixed variable that only changes in HUD when you start using Ammo, but elsewhere it always reads as a fixed variable of the total ammo that can be carried by that gun. So I am just unable to get this variable to be read live anywhere outside the HUD.
SOLVED! I was already casting to AWM in that function, so I made a new variable in the AWM bp called RealTotalAmmo, which is being set by that same cast to AWM function in the HUD bp. So now, when I equip the AWM, the RealTotalAmmo is live at runtime, and I can use that number to interact with other runtime elements in the level.
Your inventory system should be making calls to UI when it updates itself.
Ammo deduction → Set ammo value → Call UI Manager
UI Manager → Calls function to Set Ammo Text.
Overall your UI should be 100% managed by the controller class. When you create a widget you store a base reference for it.
When you do something in your character, weapon class etc you’d use BP Interfaces to call up to the controller to have it update the UI via the stored widget reference.
I don’t come from a programming background so a lot of how people organize their code is still a bit new to me. What is confusing to me about unreal is that any blueprint can ‘spit out’ code and logic while it’s active in the game, so you can have actions be performed by the player blueprint, level blueprint, and even the ui blueprint, that can in some ways achieve the same results. So why does it matter where anything is ‘stored’ really? At the end of the day it’s just ones and zeros and as long as it works…
Now I understand that for peace of mind and organization’s sake, it’s better to have everything in separate, stored, neat little boxes. But my project is a hodgepodge of 20 different tutorials combined to make what I’m doing here, so going back and re-organizing everything that was never intended to work together might be a whole new separate task.
Controllers are persistent. You will always have a controller. That’s not the case for a character (pawn). Controller is the first thing given to you when you start a level.
Let’s for example say you have vehicles in your game in which your character can enter and exit. When you enter a vehicle (take control of a pawn) your controller first un-possesses the current pawn then possesses the new pawn. If UI is in the character you no longer have direct access to it.
UI is typically different between a character and a vehicle. On un-possess you’d remove the character based UI. On possess of the vehicle you’d load its specialized UI.
When you change levels your pawn is destroyed, but your controller persists until the new level gm issues you a new one.
At the end of the day it’s the only thing that’s constant.
