I’m working on the HUD for an FPS. I’m trying to drive the health value displays via events, and have the architecture mostly in place. I have a delegate inside the player character that broadcasts when their health changes, and now I just need to subscribe to that delegate in the UMG widget.
What’s the best way to do that? Both OnConstruct and OnInitialized fire before the player character is loaded into the level. Adding a delay works, but is a band-aid solution that potentially fails if the player has a long loading time. Subscribing off of Tick works, but that destroys the point of stopping unnecessary code from being executed every frame.
Both OnConstruct and OnInitialized fire before the player character is loaded into the level.
Where do you create the HUD?
I have a delegate inside the player character that broadcasts when their health changes, and now I just need to subscribe to that delegate in the UMG widget.
It all sounds logical. But why isn’t the HUD in the player? You may have a great reason - asking just in case.
These are both architecture questions I don’t have the answer to. The project is a large one, and a partner studio wrote the code that spawns the UI and the Player. I’m digging through their code to find those answers myself, but I haven’t come across it yet.
The easiest way would be to bind the necessary dispatchers after both the player and their hud are up. Obvious, ofc.
If the architecture is complex and the HUD is not associated with the player directly (many reasons to have it this way), I’d have both entities communicate their readiness to a framework class which can then bind them. Event Driven, ofc.
Let’s say the Game Mode has a couple of false bools: bHudReady and bPlayerReady
Widget OnInit reaches out to the GM and check if bPlayerReady is true, if so - the GM binds both. If not, set bHudReady to true.
The player blueprint does the same but queries the bHudReady bool instead.
Depending on the game a good solution could be to create an event dispatcher that triggers on PC ViewTarget change. Then your HUD can subscribe to it and rebuild itself whenever the viewtarget changes. This handles possessing / unpossessing / respawning pawns, and also handles spectator mode cycling through players.
Obviously if you don’t have those use cases it is probably overkill. If you only ever possess one same character then solution above simpler.
Thanks for the suggestions, everyone. As it turns out, I randomly stumbled across a solution while I was debugging a separate issue – The partner studio had made a custom widget class that has an event that fires on pawn attached.