Announcement

Collapse
No announcement yet.

Blueprint Dialogue System

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by vipeout View Post
    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

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Originally posted by vipeout View Post
    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

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Originally posted by Cinebeast View Post
    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.

    Leave a comment:


  • replied
    Originally posted by Grogger View Post
    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.

    Leave a comment:


  • replied
    I'm glad the transition was smooth

    Originally posted by Cinebeast View Post
    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*)

    Leave a comment:


  • replied
    Originally posted by Grogger View Post
    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.

    Originally posted by Grogger View Post
    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.

    Leave a comment:


  • replied
    Originally posted by Cinebeast View Post
    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).

    Leave a comment:


  • replied
    Originally posted by Grogger View Post
    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?

    Leave a comment:


  • replied
    Originally posted by Cinebeast View Post
    I'm sorry, I'm not quite getting it yet I guess.

    In BPC_GenDio I made a new function, which I called HandleScriptFunctionDio, where I moved all the scripting. Now all the original "HandleScriptFunction" does is call that function.
    ...
    Unfortunately the error remains. In fact, it's worse -- now I can't compile GenDio without compiling the original BPC_Dialogue. Any clue what I missed?
    Yea, that's pretty much what I was talking about. Back when I was getting the trash_class issues with inheritance, that would fix it.

    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.

    Leave a comment:


  • replied
    Originally posted by Grogger View Post
    The workaround would be to make a new function in BPC_GenDio (eg. Bar), and BPC_GenDio::Foo would call Bar. BPC_SchoolDio would then implement Bar instead of the very base Foo function
    I'm sorry, I'm not quite getting it yet I guess.

    In BPC_GenDio I made a new function, which I called HandleScriptFunctionDio, where I moved all the scripting. Now all the original "HandleScriptFunction" does is call that function.

    Click image for larger version

Name:	ue4_handlescriptfunction_child.png
Views:	1
Size:	41.4 KB
ID:	1116626

    Unfortunately the error remains. In fact, it's worse -- now I can't compile GenDio without compiling the original BPC_Dialogue. Any clue what I missed?

    Leave a comment:


  • replied
    Originally posted by Cinebeast View Post
    I'm running 4.13.1. I am, in fact, inheriting from a child component -- BPC_SchoolDio is a child of BPC_GenDio, which inherits from your own BPC_Dialogue. That explains it, then.
    This is fine (it's how I do it too), but there shouldn't be circular references between them. Blueprints are a bit flimsy with this. <-- I'm guessing this will be the problem.


    Originally posted by Cinebeast View Post
    Could you delve into this, please? I don't quite follow.
    It doesn't sound like this will be the problem because it's fixed in 4.13 afaik, but I'll explain it just in case:
    Lets say you have a function called "Foo" in BPC_Dialogue, and in BPC_GenDio you override that function and it runs some custom code with a call to Parent::Foo, and then BPC_SchoolDio overrides the function again and also calls the Parent::Foo. BPC_SchoolDio's Foo function would cause a TrashClass bug (at least it used to).

    The workaround would be to make a new function in BPC_GenDio (eg. Bar), and BPC_GenDio::Foo would call Bar. BPC_SchoolDio would then implement Bar instead of the very base Foo function

    Leave a comment:


  • replied
    Originally posted by Grogger View Post
    Hey Cinebeast,

    What version of the editor are you running? I haven't seen a TRASH_CLASS bug since 4.12.

    In my experience, these often had to do with circular references (eg. BPC_SchoolDio is aware of BPC_Dialogue, but was BPC_Dialogue changed to be aware of BPC_SchoolDio?). Another issue was with inherited blueprint functions and events that are several layers of inheritance deep (eg. a function declared in BPC_Dialogue is inherited by BPC_SchoolDio, and then again inherited by a child class of BPC_SchoolDio).
    I'm running 4.13.1. I am, in fact, inheriting from a child component -- BPC_SchoolDio is a child of BPC_GenDio, which inherits from your own BPC_Dialogue. That explains it, then.

    Originally posted by Grogger View Post
    The workaround to the function issue was to call a different inheritable function in the base class to avoid inheriting a function more than once or twice.
    Could you delve into this, please? I don't quite follow.

    Leave a comment:


  • replied
    Originally posted by Cinebeast View Post
    Hello again!

    I've been having a lot of success with the system so far, but now I've hit an odd issue. I tried to package my game yesterday and failed, and after some time looking through the crash log and getting feedback from Epic staff, it looks like this add-on is the source of the problem. (Or one of the sources, at any rate.)

    Here's the offending bit in the log:

    Code:
    UATHelper: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2016.10.13-14.22.12:035][  0]LogBlueprint:Error: [Compiler BPC_SchoolDio] Error This blueprint (self) is not a TRASHCLASS_BPC_Dialogue_1387, therefore ' self ' must have a connection. from Source: /Game/BlueprintDialogues/Blueprints/BPC_Sch
     UATHelper: Packaging (Windows (64-bit)): oolDio.BPC_SchoolDio
    I'm not sure what any of that means, but I have a hunch.

    For a little while now I've run into a weird bug where, every time I open the project, the child components that inherit from BPC_Dialogue refuse to compile. That "BPC_SchoolDio" you see in the log is one of the children I made. All I need to do is open BPC_Dialogue and compile it, then compile the children, and bam, they work.

    So, easily fixed in the editor, but how do I fix things for a packaged project?

    If you've seen anything like this or know how to proceed, please let me know. Thanks for being a cool cat, Grogger.
    Hey Cinebeast,

    What version of the editor are you running? I haven't seen a TRASH_CLASS bug since 4.12.

    In my experience, these often had to do with circular references (eg. BPC_SchoolDio is aware of BPC_Dialogue, but was BPC_Dialogue changed to be aware of BPC_SchoolDio?). Another issue was with inherited blueprint functions and events that are several layers of inheritance deep (eg. a function declared in BPC_Dialogue is inherited by BPC_SchoolDio, and then again inherited by a child class of BPC_SchoolDio). The workaround to the function issue was to call a different inheritable function in the base class to avoid inheriting a function more than once or twice.

    Leave a comment:

Working...
X