Blueprint Dialogue System

[Cinebeast]

Have you checked for circular references with these three classes? That would be my best guess, I haven't dealt with trash_class errors outside of these two scenarios I'm afraid.

I'm not familiar with circular references. Looking it up, it sounds like a pretty scary situation. According to Epic, circular references are unavoidable, and ultimately part and parcel of the engine, yet they also inevitably cause bugs. I'm not sure what to look for.

If the problem lies in there being too many children to pass through, couldn't I move all the scripting I have in GenDio into your own BPC_Dialogue, and inherit from there directly?

Also, I'm using a slightly outdated version of your blueprint. I could try bringing in your latest patch. Except, I don't know how to integrate your latest patch without completely overwriting what I've accomplished so far. Do you have any advice on that point?

[Grogger]

I'm not familiar with circular references. Looking it up, it sounds like a pretty scary situation. According to Epic, circular references are unavoidable, and ultimately part and parcel of the engine, yet they also inevitably cause bugs. I'm not sure what to look for.

If the problem lies in there being too many children to pass through, couldn't I move all the scripting I have in GenDio into your own BPC_Dialogue, and inherit from there directly?

Also, I'm using a slightly outdated version of your blueprint. I could try bringing in your latest patch. Except, I don't know how to integrate your latest patch without completely overwriting what I've accomplished so far. Do you have any advice on that point?

Check the references of the three files in question (right click them in the content browser and hit the show references button). If the parent is aware of the child class (possibly even indirectly), you'll have a circular reference. If this is the case, you can likely work around it by using interfaces or inheritable functions in the base class. If it's not the case, I'm not sure what else is the problem and the Epic team might have a better idea on how to help you out

As for updating, ideally, you would never change the dialogue system files and instead only inherited from them. If you haven't changed the base files, you can update by simply migrating over the new files, if you have then anything you've changed in the base files will likely be lost while updating (there's no way around this AFAIK, BP assets can't merge differences unfortunately).

[Cinebeast]

Check the references of the three files in question (right click them in the content browser and hit the show references button). If the parent is aware of the child class (possibly even indirectly), you'll have a circular reference. If this is the case, you can likely work around it by using interfaces or inheritable functions in the base class.

Okay, it looks like BPC_Dialogue is, in fact, aware of its children. I have no idea how, though. I don't cast to them, I don't have any variables referencing them, nothing.

As for updating, ideally, you would never change the dialogue system files and instead only inherited from them. If you haven't changed the base files, you can update by simply migrating over the new files, if you have then anything you've changed in the base files will likely be lost while updating (there's no way around this AFAIK, BP assets can't merge differences unfortunately).

You're right, the transition was pretty smooth. Only thing that got overwritten was my custom UI, but it only took a few minutes to change it back to how I wanted it.

[Grogger]

I'm glad the transition was smooth

Okay, it looks like BPC_Dialogue is, in fact, aware of its children. I have no idea how, though. I don't cast to them, I don't have any variables referencing them, nothing.

If you haven't changed BPC_Dialogue, then it won't know about it's children (when looking at the references, the left side nodes are the ones that the current blueprint is using, the right side are the files that are using *it*)

[Cinebeast]

If you haven't changed BPC_Dialogue, then it won't know about it's children (when looking at the references, the left side nodes are the ones that the current blueprint is using, the right side are the files that are using *it*)

Well, then I'm especially confused. The various children -- GenDio, SchoolDio, etc. -- appear on the left, but I'm doubly sure I haven't changed BPC_Dialogue because I literally just replaced it with the blueprint in your latest patch. Are you sure it's not the other way around? Because there are a lot of things on the left-hand side of the reference viewer -- all of my maps, most of my actors, and a blueprint interface I made.

The right-hand side has UI_Dialogue, my Game Mode, and a host of other things such as the Use Action Handler, Script Interpreter and the blueprint interfaces you made.

[Grogger]

Well, then I'm especially confused. The various children -- GenDio, SchoolDio, etc. -- appear on the left, but I'm doubly sure I haven't changed BPC_Dialogue because I literally just replaced it with the blueprint in your latest patch. Are you sure it's not the other way around? Because there are a lot of things on the left-hand side of the reference viewer -- all of my maps, most of my actors, and a blueprint interface I made.

The right-hand side has UI_Dialogue, my Game Mode, and a host of other things such as the Use Action Handler, Script Interpreter and the blueprint interfaces you made.

Oh, I'm sorry you're right, it looks like I mixed them around.

[vipeout]

I'd like to ask you if there's any example on how to do branches dependent on custom functions. I see you mentioned it recently, but whenever I try to call a script interpreter function from inside the branch column it never fires off. I can do it from text, pre/post columns but not from branch. I tried something as simple as calling a Close(); function inside there, so theoretically it should close as soon as it checks for branches, but it doesn't.

I probably just don't know how to type it in there so it's interpreted and unfortunately I don't see it in the sample content either. What I want to do is:

1. Call my custom function that returns "true" or "false"
2. Check what was returned
3. Fire a proper branch depending on the returned value

Thanks for any help.

[Grogger]

I'd like to ask you if there's any example on how to do branches dependent on custom functions. I see you mentioned it recently, but whenever I try to call a script interpreter function from inside the branch column it never fires off. I can do it from text, pre/post columns but not from branch. I tried something as simple as calling a Close(); function inside there, so theoretically it should close as soon as it checks for branches, but it doesn't.

I probably just don't know how to type it in there so it's interpreted and unfortunately I don't see it in the sample content either. What I want to do is:

1. Call my custom function that returns "true" or "false"
2. Check what was returned
3. Fire a proper branch depending on the returned value

Thanks for any help.

Hi Vipeout,

Ah, no the Branch column isn't able to execute script. To accomplish what you're looking to do, you can do it in a few ways:

You can either leave the branch column empty and manually make the decision in the post-action column and use the SetBranch function once you've figured out which should execute next, OR, you can use the Silent trait and a blank record as the 'selector' and apply Conditions to the branches (the sample does this with the RandBranch; Silent traits for selecting greetings).

Hope that helps

[vipeout]

Ok thanks, I guess I'll get it working in one of the ways you described. I'd however point (not being rude, really) that in the decumentation Branches are listed as able to execute scripts under "Scripting" section.

[Grogger]

Ok thanks, I guess I'll get it working in one of the ways you described. I'd however point (not being rude, really) that in the decumentation Branches are listed as able to execute scripts under "Scripting" section.

Thanks for pointing that out! I know branches aren't currently supporting script, though I clearly had something else in mind when writing the documentation. I've marked it to review and I'll try to figure out why it isn't supported + fix it if it should be

[Grogger]

Hi everyone!

I wanted to let you folks know that there's a crash bug in 4.14 with the dialogue system.
I have fixed the issue (along with others, which I'll have more details for soon), and submitted it for the marketplace. I'll post again once it's gone live so you can update.

The fix was simple:
In file Lib_String, function ParseIntoArray2 the collapsed graph "GetSubstring" is using a select node to use a different set of instructions when the string is 'not found'. The problem is that the select node will execute all of the code, causing GetSubstring (with a now negative length) to hit a new assertion in 4.14, crashing the editor.

The fix is to replace the select with a branch, only executing the code that is valid.

Cheers!

[Grogger]

Ok thanks, I guess I'll get it working in one of the ways you described. I'd however point (not being rude, really) that in the decumentation Branches are listed as able to execute scripts under "Scripting" section.

Hey vipeout, just an update, I have reviewed my previous decision on this and it turns out that I had dropped the feature because of syntax complexity. The parser isn't easily made to understand the difference between #text:text (cross-component references) and text?text:text (ternary conditional operator). I could revisit this later, but at this time it isn't trivial to achieve

[vipeout]

Don't worry, man There are at least 3 other ways I could've done it once I started to mess deeper. That one is solved and now I'm on the next thing to do, so it's cool ;P The only thing I'd do is to remove that text from documentation as to not confuse others

[motorsep]

[MENTION=2545]Grogger[/MENTION]

Any chance to see an update for having an option for dialogues to be in UMG 3D widgets instead of conventional full screen UMG ?

[Grogger]

Don't worry, man There are at least 3 other ways I could've done it once I started to mess deeper. That one is solved and now I'm on the next thing to do, so it's cool ;P The only thing I'd do is to remove that text from documentation as to not confuse others

Done and done

[MENTION=2545]Grogger[/MENTION]
Any chance to see an update for having an option for dialogues to be in UMG 3D widgets instead of conventional full screen UMG ?

Hi Motorsep
I haven't done this myself, but this should be something you can achieve by overriding the DisplayUI function in BPC_Dialogue to do what you want instead of adding a 2d ui to the viewport, and probably would use the 'passive mode' to auto-flow (depending on your use case).