Download

Child Blueprint Class - parent bool not updating for all children, only one who called it

Hi all, I’m having some issues with some badly behaved children…

I have a parent blueprint that has a bool that is set to 0 as default.

Within Child 1’s blueprint after being called, an Event Dispatch is sent that is received by the parent. At the end of a sequence within the parent it gets/sets the bool (The bool is called ‘1-1-4’) to true, then Child 1 moves on to do another sequence by way of a branch once interacted with again. The bool is definitely switched and it is confirmed in a debug hud I have set up.

Now that the bool is set to 1 and confirmed, I then interact with Child 2 expecting to see the true statement of Child 2’s bool branch (is bool ‘1-1-4’ true), instead the debug hud reverts to show the bool as 0 and Child 2 runs the sequence associated with false. Hmm, strange!

To add to the strangeness, I go back to Child 1 and reinteract. The bool/debug are shown as 1 again and Child 1 is still following the true statement of my branch.etc.

So it is as if both children have separate instances of the parent bool even though both set/get it within the parent.

My main question is, is this normal parent/child behavior to have individual instances of the same variables? If so is there a good way of sharing variables between children aside from casting to each child? I’m attempting to use a parent/child relationship to manage NPC’s and dialogue.


Here are some redacted (but large. Open in new window for full size) blueprints incase they may help. The more I think about it the more I think that there is something wrong in the blueprint. Excuse the mess and inefficiency, it is still a work in progress!

Parent - with Event Dispatchers holding the dialogue tree’s so I can keep an eye on the bool with my Debug hud more efficiently. Dialogue Answer 1 of the lower two Dialogue Answers sets the bool ‘1-1-4’ to true, upper two can’t access the same bool result.
4200d3049b1294fdf6b6e129813ce56c41f272e1.jpeg

Child - receives call from parent, sets dialogue name variable, sprites when interacting.etc then sends a message to parent to begin the appropriate dialogue tree.

3f787af257fc342232ac72fdaaffaf64d8ae2a4f.jpeg

Player Controller - Checks if object hit by line trace is ParentNPCHandler (Parent - Image#1)

d1448b3d8c0083e57c0d899f2260f9faa53234b7.jpeg

You have to think of ParentNPCHandler as more of an interface than an object itself. NPC1 and NPC2 are both separate instances of ParentNPCHandler, each having their own instances of variables, like your 1-1-4 bool.

Based on what you wrote, it seems like you want that bool to actually be sort of like a global variable. If one child changes it, then it changes for all children. If this is correct, there are a few ways to handle this.

One thing you could do is to use the node Get All Actors of Class, and then select ParentNPCHandler. This will return an array of all ParentNPCHandler actors at which point you can loop through the array and set the bool for each one.

Another thing you could do is push the variable out to an object that all NPC’s have access to, like GameState. You’d have to create your own instance of GameState if you want to add that variable though.

Thanks for the reply, I do like the idea of having both singular variables per NPC and also being able to get all actors of class, loop, set.etc as you said. That could be interesting :slight_smile:

I have tried this but I don’t have much experience with Arrays yet so I could be missing something vital!

bf23919779392a1274509fba8152f19f9def841d.jpeg

I ideally want to avoid creating more links in the chain if possible, so I would like to keep the dialogue and dialogue related variables that push it on in one place (which I am sure in six weeks time will not be as good of an idea as I think it is!). The ParentNPCHandler will be the parent to most things in my project that drive the game forward, other NPC’s, chests, all items obtained, bosses defeated.etc. Anything with a dialogue box essentially. I am definitely open to other ideas though on how to handle this, redoing everything would be painful after I leave my small little test realm and begin building

Very close, from your ForEachLoop drag from the Array Element (like you did with display name) and search for Set 1-1-4, almost similar to how you set Dialogue Finished in the lower left hand corner of that image.

Another idea, since you seem to be good with Event Dispatchers, you could always create one of those to do this for you.

Based on your last paragraph, it appears you want ParentNPCHandler to behave a bit like GameState, which essentially keeps track of the current state of the game (global variables and such). What you currently have, just based on those screenshots, are parent functions on how you want all of your NPC’s to act. In the end, if you continue on this path, all NPC’s will know everything. It could get a little messy in the future, and if you have a lot of NPC’s, that is a lot of duplicate memory wasted and CPU power wasted as well trying to update every single one every time a variable changes.

GameState is good for handling variables that every Actor/NPC will need to know that are based on the overall current state of the game. 1-1-4 is a good instance of a variable that should be moved there. I know you said you don’t want to create more links in the chain but adding this one could save you a lot of trouble in the future.

Doh, yes that did it.
Thanks for the heads up, so my dream of a centralised drag and drop NPC handler is slowly ebbing away. hmm.

So would you say I could minimise the fallout of this issue you raised if I moved the dialogue back into each child? (it was only in the parent for debugging purposes so I could try and see what was going on). This would mean that each time a variable is set in any NPC, i would instead run the array of “global” variable setters like you mentioned above. I don’t think unreal would struggle running this and it should minimise the load. Actually, even better, I could turn the array building process into a function/custom event in the parent to minimise repetition. I’m rambling now, which is probably a good sign :slight_smile:

My original goal was to have a means of creating a drag and drop type NPC that I can give a Name (NPC1/2/3.etc) corresponding to the NPC data table, a row name for each dialogue option in a separate table, a custom sprite and movement flipbooks, all with easy access the necessary variables as if they were global variables, like you said.

I have tried other methods before this one but casting all the time to move dialogue on and create interaction became such a nightmare that I decided to try and centralise it. Can you see any pitfalls I may be missing if I impliment the first paragraph again and go ahead with that and start cleaning up/condensing it? I would probably end up moving each “chapters” of dialogue into its own function within the child npc so I can split key game progression into separate functions on all npcs. Is Chapter = to 2 -> run Chapter 2 dialogue function, then within the function branch between text options for minor dialogue change events.

What would the benefits be of using a gamestate rather than parent child if the above is implemented?

Thanks for your help, it’s good to bounce ideas around with someone more knowledgeable, I hadn’t even considered how messy it could get in the late stages.

If you are going to have a lot of different NPC children blueprints and all with different dialogues, it might be better to move them into the children. Otherwise, that parent blueprint will get very large and hard to manage.

As for gamestate, it is more of an addition instead of replacing the parent/child. It’s just a central place where every object can look for things that every object needs to know about. You will still want the parent/child set up you have now so that every dialogue NPC acts similarly.

Okay thanks, that’s about all I need to know. I’ll start reading up about utilising a Gamestate and play around a bit to get a test running.

Thanks for the help, you’ve helped steer me in the right direction yet again!