Hello. I can’t figure out how to make a responsive, non-ticking UI in Unreal. Let’s say I have a bunch of HUD UI elements and when something happens in the game I want the HUD to change, like a widget starts moving, a text widget’s text updates, UI animation starts playing, etc. Complex stuff. I can’t even figure out how to simply update a text without it ticking.
The only resource I found is this: Drive UI Updates with Events | Unreal Engine Documentation Sounds like the event driven approach is what I need. But that documentation seemingly stops before the final step. In the end it calls “set percent” and never explains what it is. Is it a custom function the text is bound to? Then we’re back at ticking. Also it never explains how the property binding actually works, I’m assuming that’s ticking too, otherwise how would it know if the property has changed?
Then I found SetText: Set Text | Unreal Engine Documentation Which doesn’t show up to me at all. Not from the widget, not from other blueprints. Even worse documentation, doesn’t explain the scope of this node, or anything. If I turn off context sensitive, it’s there, but expects a RichTextBlock, which is not what the standard UMG text widget is.
I can’t even imagine how I’ll set up complex UI functionality like for example let’s say a mini upgrade tree is always visible, then when something happens in the game it transitions to full screen, while flashing, with some text changing to “new upgrade available”, then the user can scroll through the tree, etc etc. Is something like this even possible without having dedicated people working on custom C++ UI solutions or something? How do others do it? I can’t find resources.
If it’s helpful, the “Set Percent” node in the Documentation is for the “Progress Bar” element. It sets the percent for the fill material. The binding uses an event dispatcher, which are incredibly useful for creating Event Driven systems that are not tick driven: Event Dispatchers | Unreal Engine 4.27 Documentation
Is something like this even possible without having dedicated people working on custom C++ UI solutions or something? How do others do it? I can’t find resources.
Yes, it’s a standard way of doing things, the only reasonable way of creating a performing UI. Look into event dispatchers, as mentioned above.
Thanks for the response. Indeed I’m trying to use event dispatchers, I think I just need the last step. I bind it, make a custom event, and then what happens? How do I actually update a UI element?
This requires no Dispatchers and is still event driven. The player gets hit and fires off an event in the widget to visualise the health value decreasing.
But lets say we need to communicate in a more complex manner… We click a button in one widget (use a healing potion) and the player will heal and update another widget that shows their health.
This is still quite simplified because the healing amount should come from the potion itself. And that’s what Event Dispatchers are for. They allow you to push data around rather than just a click like in the example above.
A slightly different thing: with event dispatchers, I need to have a reference to the blueprint that calls it. Doesn’t this create a mess of cross-references? Am I worrying too much about performance (ticking, and references → a lot of stuff getting loaded into memory)? At that point I could just have one big central class which handles everything, and to which everything has a reference through event dispatchers. But as I’ve learned it can’t really be the level BP, as that can’t be referenced / cast to. (Is that correct?)
Above, the player clicks a potion and the button calls a dispatcher. Note the New Param, that’s the data we’re pushing around. The player can register with that call:
Dispatchers are quite performant actually and do not create or require hard references. You must provide a reference to an instance ofc. You can do this:
In this case, the actor and the widget do not know about one another. You could have a manager blueprint that spawns and binds everything and then destroys itself. The bindings will work fine. Zero references at this point. No casting. No ticking.
Avoid using the Level Blueprint for things that are unrelated to that one level. It’s awkward in most cases.
