I’d probably use UMG, I think HUD is the old way of doing things at this point. What I’d do is spawn a UMG widget with the relevant text based on your state/event and then set up some logic in the widget to remove itself after a specified amount of time. You can store and set a text variable on your UMG widget so it would be possible to set up a general class of widget that could handle any message you want using this method.
What I need to do now is to call the ChangeText function from a C++ class.
I know there are alternatives, but I already tried those.
For example, I tried binding an event from the GameMode. But since my game is going to be a Multiplayer game, I read that the GameMode isn’t good for this kind of HUD.
Re-Reading your previous thread your main issue now is that the message gets printed only once, right?
I’m seeing a logical issue in your Show/Hide call sequence. Where exactly are you setting the Visibility back to “Visible” after hiding it the first time? Merely setting “To Display” boolean to true is not enough as your logic ShowHide needs to be called at least one more time - i.e. exactly after the “Set Player Killed Message” node sets the player message and exactly before the HUD Delay sequence goes through. If you don’t do that, how will the text message be visible the second time? The first time probably works because the text message is already Visible (by default) but set to a blank string.
I can’t think if anything else I’m afraid - overall your event dispatcher approach looks alright to me apart from this logic issue.
The main “Master Widget” has a TSubclassof<> variable which specifies a type of UserWidget (in my case, a UBZGame_DeathNotification). I create a widget based on UBZGame_DeathNotification in the content browser and then set the Variable in the master widget to that new widget. The master widget also has a UPanelSlot variable declared in C++, and I set that variable in the event graph using Event Construct - to one of the items in the designer.
When the player is notified of a death, it creates a new death widget as part of the master widget, sets two FText variables on it for the player names, and adds it to the master widget in the slot that I specified.
Over time the widget fades itself out to completely transparent then removes itself, and is marked for destroy.
Blasphemy. ShooterGame is a fantastic resource and if it does something a particular way, you should probably follow it. There’s a reason things are done the way they are.
