Reacting to cancelled actions/behaviors

[andriyDev]

As far as I can tell (please correct me if I'm wrong), there is no way to detect a cancelled action or Behavior. For example, if you have While(Wait(5.0), Action(MyAction::Dance)), if the 5 seconds expires, the action will be exited early. This can be problematic if your dance animation doesn't turn off automatically (perhaps it loops by default).

By the same reasoning, it could be nice to have a way to react to a whole Behavior getting cancelled. For example, part of the tree may start with "claim a spot in a queue of agents". Leaving this subtree would ideally "release" that claim. We might be able to fake this by using something like WhenAny(the_queuing_tree, Action(MyAction::ReleaseSpotOnCancel)). Then we just do nothing for this action normally and when it "hears" about the cancellation, it can react to it. This is quite cumbersome though, so it would be nice to somehow make a single Behavior that does all of this.

To do this, we could add a second FnMut that deals with cancellations. This would unfortunately separate the action logic from its cancellation logic, but it is a very easy solution.

[kaphula]

That sounds a bit like something you could solve with WhileAll, have you tried that? WhileAll does not exit its action sequence in the middle like While does even if the "while" condition changes. Only when WhileAll's action sequence has reached the end will the "while" condition be checked again to determine if its action sequence should be executed again. You can also exit from it in the middle of the action sequence by returning Failure from one of the actions.

[andriyDev]

I don't follow. If the parent of the WhileAll doesn't "follow that branch" (e.g., it is a While node whose condition just completed), there's no way for any "cancellation" action to be ticked, so it can't react. This also applies to actions: by the same logic, actions can't react to cancellation (today) since they could just not be ticked due to a changed decision in its ancestors.

[kaphula]

I see. Is it too bad to add a separate action like MyAction::EndDance and chain it like this, or did I still misunderstand what you meant:

Sequence(
    While(Wait(5.0), Action(MyAction::Dance)),
    Action(MyAction::EndDance)
)

I tend to just build something like begin, working and ended actions for my trees.

[andriyDev]

That works in that simple example, but lets consider a more complex scenario:

Select(
    vec![
        While(
            Action(MyAction::NoEnemies),
            vec![While(
                Action(MyAction::NoOneToTalkTo),
                vec![Action(MyAction::Dance)}
            )]
        ),
        do_something_if_there_are_enemies,
        do_something_if_there_is_someone_to_talk_to,
    ]
)

In this tree, we want to dance if there's no enemies and there's no one to talk to, and if either of those conditions aren't true we want to stop dancing. However if we want to apply your pattern we have to somehow do that outside the While(NoEnemies) behaviour, and this applies to any behaviors. This makes the fact that we have to stop dancing "leak" out of the particular dance action all the way up the tree.

I'm new to this crate, so hopefully my example makes sense haha

[kaphula]

Okay. In this case I'd probably keep book of actions that have or have not happened in the dancer's state and then put a behavior to be run right before both do_something_if_there_are_enemies and do_something_if_there_is_someone_to_talk_to called ResolveOwnState which would handle the cancellation code as needed.

It sounds a bit challenging and potentially inefficient unless the solution is smarter than walking the whole tree down and searching for cancelled actions every time a while condition does not pass. Generally I am personally against this if it breaks the existing API or affects the overall performance of existing trees not using this feature.

As a side note, perhaps unrelated, but you don't always have to encode the whole behavior logic inside a single tree if it feels like it gets overcomplicated. You can make multiple tree behavior constructors and rewrite your current tree instance in the middle of its execution if you are sure something bad happened and you want to start doing something else right now, for example. But this itself can get complicated and hard to follow too. I do it like this by caching the separate trees lazily and cloning them as needed:

pub fn do_work() -> Behavior<FarmerAI> {
   // ...
}
// ... 

pub static AI_FARMER_DO_WORK: LazyLock<BT<FarmerAI, ()>> = LazyLock::new(|| {
   BT::new(FarmerAI::do_work(), ())
});

// ...

// rewrite current tree:
farmer.ai_tree = AI_FARMER_DO_WORK.clone();

[Sollimann]

@andriyDev Thanks for bringing up the discussion. As you mention, we don't support cancellation, but I think its possible to extend @kaphula 's idea to achieve this.

I haven't tested this myself, but building on @kaphula 's idea I wonder if its possible to e.g do:

let wait_then_cancel = Sequence(Wait(5.0), Action(MyAction::CancelDance))
While(wait_then_cancel, Action(MyAction::Dance))

If I remember correctly, wait_then_cancel will return RUNNING when <5s has passed, once >= 5s it proceed to cancel the dance and return SUCCESS

To broadcast a cancellation from one action to another you can e.g use the blackboard to relay cancelation signal or simply use a mpsc or oneshot channel.

Like @kaphula said, we generally want to avoid any breaking changes unless there is a potential large gain here. Also, we need to be careful not introducing any performance regressions.

If you guys have any good examples and/or clever BTs that could benefit others (e.g how to effectively cancel actions), feel free to add them to the examples/ folder @andriyDev @kaphula