Why isn't my event dispatcher working?

OMG, I didn’t realize you had a “Get All Widgets Of Class” node. I thought it was “Get all Actors” node. The key point here is that you’re looking for widgets… likely before they are created. Not only that, but you are calling Bind Event on an array. I have no idea if that will work. You usually need to use a for each loop.

Start by using a for each loop between “Get All Widgets” and the “Bind Event” nodes. Connect the array to the “For Each” node. And connect the array element to the bind node. Then see if your print Hello node actually displays anything. If your widget hasn’t been created yet, it won’t print Hello and we’ll have to find a different way to trigger the event.

So make that change and let us know if the Hello node prints at all. Make sure it’s the only node that prints Hello. It should exist immediately after the “Bind Event” node and nowhere else. If you have other print nodes, make sure all their texts are different so you know which one printed.

I’m fairly certain the widget isn’t created when the “Bind Event” node executes since you said it’s a dialog… so I’ll leave a few possible solutions here in case your Hello node above doesn’t print anything after using a for each node. If I end up being wrong, we can revisit these.

  1. If you have access to the Quest Manager Actor when you create the dialog, then just store a reference to the Quest Manager in the dialog widget. The widget can then just call the event directly on the Quest Manager. No need for dispatchers. This is the simplest solution.

  2. If you don’t have access to the Quest Manager Actor when you create the dialog, you can do the following. Make sure you have a GameInstance Blueprint. If you don’t have one, create it and set it in your project settings. This solution only works for single player games BTW. Add a variable to store your Quest Manager reference. In your Quest Manager Actor’s Begin Play event, set itself in the GameInstance’s variable you just created. You can use “Get Game Instance” node and cast it to your BP GameInstance class to get the GameInstance. In your widget, you can just grab the Quest Manager from your game instance and call the event directly.

If this is multiplayer, you’re gonna have to either store your quest manager somewhere accessible by your widget or just do a “Get All Actors of Class” and find your quest manager that way. It’s not fast, but might be good enough for your purposes.

1 Like

you’re probably better off using an interface for this,

the problem is using BeginPlay/GetAllWidgets is, do the widgets even exist at that point.
since its unlikely every dialog widget is loaded and created before your manager class it will fail.

just have your dialog widget get a reference to your manager which is easy because it should be a singleton and call an interface/function event

another option is to use the manager itself to create the widgets and bind/unbind on creation

Why in your screenshot are the nodes not connected?

I know there’s some question about when the dialogue box gets created, but it gets created in the first person character blueprint at begin play (so it only gets created once), and then I toggle the visibility and set the text widgets inside it as needed. I think that the next thing I’m going to do is try to put a delay node after Event Begin Play. If that doesn’t work, I’ll probably handle some of this logic in the dialogue box’s blueprint, as it already has access to most of the variables I need based on what it’s doing.

I’m actually using the game instance to store variables that need to persist between levels; everything from inventory and NPC and player stats. The quest actors are mostly going to be for custom scripts to govern the various conditions that move the quest stage forward (with the game instance keeping track of the quest stage across levels), which in turn will govern the conditions and such of the actors involved in the quests. I was trying to put the logic about checking the whether dialogue topics are related to quests and stuff in the parent quest actor BP since I know most quests will get initialized through dialogue with NPCs.

Thanks for all your help. I’ll update if anything else comes up.

Okay, new problem.

I added a Delay Until Next Tick node after Event Begin Play node in the quest actor blueprint and it seems to be working now, because when I click on a quest-related dialogue topic, that Print String node fires with the Quest ID associated with the topic.

However, it seems to be firing three times for some reason (the quest id is “0000”).

image

The “Hello” is coming from the end of the logic that gets executed after I click on a dialogue topic, so I know that it’s only calling the bound event once.

The dialogue box only gets created once because it’s set to get created at begin play in the player character BP.

The only thing I can think of is that the Text widgets that get created in the Dialogue Box’s blueprint to represent the dialogue topics and parented to it are being counted as being members of its class, and the binding is happening three times, so when the call goes out it fires three times. For this NPC that would make sense: one dialogue box plus two topics = three “0000s.” Is that even possible though?

But that seems unlikely since they don’t get created until the NPC is spoken to and the dialogue box’s visibility is changed. E: I’m also only getting top-level widgets of this class, so even if the topic widgets counted as being of the W_DialogueBox class through inheritance, they shouldn’t be seen by that node.

If “Hello” is only printing once, then there’s only one event and only one widget (this part is working correctly), but three things bound to it. That would seem to indicate you have three quest actors in your level.

edit: You could put a print node after the Bind node to verify if this is true. If it only prints once, then dunno. I’d be surprised if the Get All Widgets node would have the same widget three times in its array. That would be very weird. But you could print the length of the array as well to see.

Also want to say I’m really happy to see you’ve made some progress. This is really good news.

Grazi mile, mate.

It turns out I’ve gotta rebuild my quest system to make it more dialogue intensive, but you’ve dropped some hard knowledge on me and I’m going to carry it with me.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.