I’ve been watching videos and reading about event dispatchers for the last couple days now and I thought I understood how they worked, but I guess I don’t.
I have the event dispatcher set up in my dialogue box, so it fires whenever the player clicks a topic that is quest related. I’ve tested this end of things thoroughly and I know that all of this stuff works, the appropriate variables are being sent, etc.
The stuff running off the event begin play node all works but the custom event isn’t firing.
Edit: I only have one dialogue box widget, it gets created from the player character blueprint so it definitely exists in the world and I’m sure it’s getting it, as it always work whenever I call it like this
Edit 2: Actually, nvm. I just ran the Bind Event node into the print string node but it’s not firing.
so what even is the point of the bind node if it doesn’t just sit there and listen? at this point, i can’t see any situation where i’d use an event dispatcher instead of just doing the logic in the first blueprint or using an interface to transfer the exec from the end of the dialogue box widget into the quest actor
I can’t really know what’s going on with such little context, you should be able to call your events on button clicks (there are also such nodes in widgets, I’m not just talking about keyboard buttons) but here’s a tutorial on dialogues:
In this video, he has the node that’s listening coming off of event begin play, ultimately, but it still doesn’t trigger the bound event until the player dies.
You said you were handling the binding in your actor called quest manager, right? Are you sure that it’s placed in your scene? It should be spawned first.
I just need a way to get from the dialogue box widget to the quest actor and carry those variables when the button gets clicked. The button itself is in a different widget parentrd to the dialogue box, and it talks to the dialogue box through an event dispatcher
As @VisAgilis has mentioned, you have a misunderstanding of how binding an event works. Binding an event is a very quick operation. It doesn’t stop there. Once bound, execution continues on to the next nodes immediately. This is why your print string node only fires once. It is correct behavior. If you call your dispatch, then the event will be called.
Think of “bind” as remembering what do to when a dispatch is called. So there’s no need to wait around.
To find out what’s going on, place a breakpoint on your Break node in your first screenshot before the “Call Quest Dialogue Fire” dispatch is called. Then step through until you reach your red “Quest Dialogue Event” node.
Let us know how far you get or if the breakpoint is triggered at all and we can work from there.
No as we established before it’s not about the bind node not being triggered again, it’s about the actual call not getting triggered (if that’s the case of course) Go ahead and check if that branch node of yours actually executes it’s true pin as @AlienRenders has suggested, by placing a print string node after it.
Ok, did you step through it? You should eventually reach your red event node meaning everything is working.
edit: I want to reemphasize that BREAKPOINTS are a thing in blueprints. You just can’t use them in materials or in Tick events. But everywhere else, you can set breakpoints on any node. So no need to use old school debugging with print string. Just set a breakpoint and trace through each node one at a time until you reach your RED event. If you get there, it works. If it doesn’t get there, you’ll immediately know what node stopped or diverted execution.
Yes. This is just indicating what event the dispatch should execute when you call it as described above. So when you call the dispatch, you’ll end up automatically calling the event instead. That’s what binding does. So there is no “listening” at all.
No. When you call the dispatch, it will automatically call the event that was bound earlier. No listening is needed.
There is no listening. That’s not a thing. Like I said before, binding is just indicating what event should be called.
A dispatch is like an envelope than you mail. But it has no address. Binding is like writing down the address on the envelope so it know where to go (or what event to trigger).
edit: In fact, I think this is why a dispatch has the envelope icon.
It’s a common term used as a metaphor when binding functions. It doesn’t mean that something actually waits around. It just means that when an action happens, a certain function/event will get called. And they call that listening. But nothing actually waits around. For most people, the use of this metaphor helps them understand the concept. But for you, you’re taking the metaphor too literally and is actually hurting you.
For you to understand properly how it works, I need you to avoid the word “listen” like the plague. Are we good? Don’t say it. Don’t use it. Don’t read it. Don’t write it. The word “listen” does not exist.
I’ve been programming for over 35 years. And this is a topic that I’ve known and used for all of that time in various environments. So this isn’t a topic I can get wrong. I’m trying to help you. I’m not gonna trick you. But you need to work with the people trying to help you. For now, we just need you to please post your findings with the breakpoint on the Branch node of your blueprint as you step through.
Did the breakpoint trigger? Yes or no?
If yes, step through each node one at a time. Were you able to get to your RED event?
edit: You’ll have to use F11 (step into) to get to the RED event from the dispatch call.
n