Announcement

Collapse
No announcement yet.

Behavior Tree "Gotchas"

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

  • replied
    Very new to BTs, so I have to ask.
    Using the task Run Behavior allows you to select another BT to execute. But if these use different BBs, then the subtree won't execute past the first composite.

    Example:
    Click image for larger version  Name:	BTSameBB.png Views:	32 Size:	86.8 KB ID:	1769086

    In the bottom example, sub BT with different BB from what the main one is using won't execute.
    Is that intended?

    Edit; to Run Behavior in another tree, the behavior trees needs to have the same blackboard - something that the top example did have, but the bottom did not.
    Last edited by ste1nar; 06-21-2020, 06:51 PM.

    Leave a comment:


  • replied
    Originally posted by BiasedAgent View Post
    Completely missed this message. Thanks! My debugging skills failed me... completely missed it was called twice.. Seems really obvious now *facepalm*.

    Leave a comment:


  • replied
    Note that the fix is in 4.26. Since this issue is a lot more wide spread than we thought I'll merge the fix to 4.25.1.

    Leave a comment:


  • replied
    Originally posted by Bino View Post
    I should highlight that this is a bug and this approach is a work around. It's been fixed https://issues.unrealengine.com/issue/UE-92936
    Workaround with synced keys also worked for me (blueprint project) Thank you Bino!

    Leave a comment:


  • replied
    I should highlight that this is a bug and this approach is a work around. Its been fixed https://issues.unrealengine.com/issue/UE-92936
    Last edited by Bino; 05-09-2020, 07:47 PM.

    Leave a comment:


  • replied
    Originally posted by AJ_Lakeman View Post

    I'm currently working on a blueprint-only project, and since updating to the 4.25 release today we are experiencing a crash whenever closing out of the game:
    Code:
    Assertion failed: BlackboardDataToComponentsMap.FindPair(&BlackboardData, &BlackboardComp) == nullptr
    This is the only thread I can find discussing this issue, and we're not sure how to proceed, still looking for a blueprint workaround at the moment.
    I, too, am having this issue.

    However, using the workaround that Bino mentioned:

    Originally posted by Bino View Post
    2) I removed all synced keys from my blackboard - for whatever reason they hang around when cleaning up and thus the ensure is fired
    I disabled Instance Synced on the one key I have that was using it and it stopped crashing.


    Leave a comment:


  • replied
    Awesome. I came back here to reply, as I had gotten a proper UDN response on this. It is a known issue that already has a fix in UE GitHub if you have access to that.

    And yeah, the suggested work around was to just nuke Synchronized keys as you say for now, as that is what is ultimately causing this issue. Just doing that was fine for me as I had only 1 sync key and I was no longer even using it. But I imagine if you need them right now, you will want to get that fix!

    Leave a comment:


  • replied
    https://github.com/EpicGames/UnrealE...68deac06c92837
    Enjoy.

    Leave a comment:


  • replied
    I've been looking into it and I've managed to work around it.

    1) I moved my initialization code to the first frame of the tick. It seems that required components weren't being initialized in time (didn't always happen)
    2) I removed all synced keys from my blackboard - for whatever reason they hang around when cleaning up and thus the ensure is fired

    Leave a comment:


  • replied
    Originally posted by nakedeyes View Post

    I am experiencing this exact issue. I have been fine thus far, by kicking off my AI in my controllers via:

    Code:
    GameLevelAIController::OnPosses()
    I would call in C++ :

    Code:
    // Set up Blackboard and Behavior Tree UBlackboardComponent* BBCompPointer; UseBlackboard(BlackboardAsset, BBCompPointer);
    I am doing this instead of manually managing A Blackboard component on the controller class / BP ( maybe that is bad ).. but just by calling that in my game code, I get the ensure you pointed out due to the Blackboard Component getting initialized twice and not handling it correctly, which totally crashes a packaged build and although its fine in editor for me, it does endlessly hit the ensure in UnregisterBlackboardComponent().

    I think this is a legit new bug in 4.25. Hope for fix or work around soon!
    This definitely seems to be an issue introduced with 4.25.

    I'm currently working on a blueprint-only project, and since updating to the 4.25 release today we are experiencing a crash whenever closing out of the game:
    Code:
    Assertion failed: BlackboardDataToComponentsMap.FindPair(&BlackboardData, &BlackboardComp) == nullptr
    This is the only thread I can find discussing this issue, and we're not sure how to proceed, still looking for a blueprint workaround at the moment.

    Leave a comment:


  • replied
    Originally posted by Bino View Post
    Bit of a long shot as this is an old thread but thought I'd see... I just upgraded to 4.25 preview 7 and I'm having issues with AISystem.cpp. In particular the registering and unregistering of components.

    The check at the bottom always fires now and the ensure sometimes fires. It's hard to make out what's going on as values are optimized away. This wasn't occurring in 4.24.

    For the check I think it's reference to an the AI actor controller hanging around. Or maybe it's not being removed by RemoveSingle??

    Feedback: I quite like the AI system but I'm ready to ditch it. It's by far the biggest time sink in debugging issues and just getting it to work for this project. I can a lot of love and thought was put into it but when using it in anger... it's hell.


    Code:
    void UAISystem::UnregisterBlackboardComponent(UBlackboardData& BlackboardData, UBlackboardComponent& BlackboardComp)
    {
    // this is actually possible, we can end up unregistering before UBlackboardComponent cached its BrainComponent
    // which currently is tied to the whole process.
    // @todo remove this dependency
    ensure(BlackboardDataToComponentsMap.FindPair(&BlackboardData, &BlackboardComp) != nullptr);
    
    if (BlackboardData.Parent)
    {
    UnregisterBlackboardComponent(*BlackboardData.Parent, BlackboardComp);
    }
    BlackboardDataToComponentsMap.RemoveSingle(&BlackboardData, &BlackboardComp);
    
    // mismatch of Register/Unregister.
     check(BlackboardDataToComponentsMap.FindPair(&BlackboardData, &BlackboardComp) == nullptr);
    }
    I am experiencing this exact issue. I have been fine thus far, by kicking off my AI in my controllers via:

    Code:
    GameLevelAIController::OnPosses()
    I would call in C++ :

    Code:
     
             // Set up Blackboard and Behavior Tree         UBlackboardComponent* BBCompPointer;         UseBlackboard(BlackboardAsset, BBCompPointer);
    I am doing this instead of manually managing A Blackboard component on the controller class / BP ( maybe that is bad ).. but just by calling that in my game code, I get the ensure you pointed out due to the Blackboard Component getting initialized twice and not handling it correctly, which totally crashes a packaged build and although its fine in editor for me, it does endlessly hit the ensure in UnregisterBlackboardComponent().

    I think this is a legit new bug in 4.25. Hope for fix or work around soon!

    Leave a comment:


  • replied
    Bit of a long shot as this is an old thread but thought I'd see... I just upgraded to 4.25 preview 7 and I'm having issues with AISystem.cpp. In particular the registering and unregistering of components.

    The check at the bottom always fires now and the ensure sometimes fires. It's hard to make out what's going on as values are optimized away. This wasn't occurring in 4.24.

    For the check I think it's reference to an the AI actor controller hanging around. Or maybe it's not being removed by RemoveSingle??

    Feedback: I quite like the AI system but I'm ready to ditch it. It's by far the biggest time sink in debugging issues and just getting it to work for this project. I can see a lot of love and thought was put into it but when using it in anger... it's hell.


    Code:
    void UAISystem::UnregisterBlackboardComponent(UBlackboardData& BlackboardData, UBlackboardComponent& BlackboardComp)
    {
        // this is actually possible, we can end up unregistering before UBlackboardComponent cached its BrainComponent
        // which currently is tied to the whole process.
        // @todo remove this dependency
    ensure(BlackboardDataToComponentsMap.FindPair(&BlackboardData, &BlackboardComp) != nullptr);
    
        if (BlackboardData.Parent)
        {
            UnregisterBlackboardComponent(*BlackboardData.Parent, BlackboardComp);
        }
        BlackboardDataToComponentsMap.RemoveSingle(&BlackboardData, &BlackboardComp);
    
        // mismatch of Register/Unregister.
    check(BlackboardDataToComponentsMap.FindPair(&BlackboardData, &BlackboardComp) == nullptr);
    }
    Last edited by Bino; 05-07-2020, 10:35 AM.

    Leave a comment:


  • replied
    As I mentioned above, Timers should be automatically cancelled on deactivate, so you don't have to worry about that.

    Other "external" events could be anything you may have implemented in your own game. Basically, by external, I mean an event that is called by code or blueprints outside of the behavior tree (or at least outside of the subtree in which your node is executing). One way that could be done is by calling a function on some other blueprint (like the AI pawn) which registers for that pawn to call the event on your node when the event occurs. If it's done by calling a "register" function, you'd need to call "unregister". If it's done by setting a variable or reference, then clearing that reference to none would be correct. However you are causing yourself to get the event called from outside the normal tree flow, you need to make sure you aren't receiving that event when your node is not active.

    Fortunately, we handle the most common built-in events for you (Timers, Timelines, and Delays), so no need to worry about those!

    I hope that helps.

    Leave a comment:


  • replied
    Hi Daniel! For clarity, can you give some explicit examples about the "registering for external event" gotcha for us non C++ folks? Do you mean things like passing references to other blueprints and then having that BP do some sort of event with the reference? If so, is simply clearing that reference to 'none' and clearing timers/etc. the preferred method of de-registering? Thanks!

    Leave a comment:


  • replied
    Using any "Tick" Events can in behavior tree blueprint nodes may be bad for perf!

    I'll add some more details here in a bit. Mieszko just suggested I add this point as I was posting the others.

    Leave a comment:

Working...
X