Purpose of bool param in multiframe Action about npbehave HOT 9 CLOSED

this parameter is true in case another node requests your action to be stopped. In this case you will need to abort your action and are not allowed to return Result.PROGRESS.

This can happen for example if you have another decorator on another branch that watched for a blackboard condition that now became true.

from npbehave.

I see. Can Result.BLOCKED be returned? Tho thb, not fully sure what the difference between FAILED and BLOCKED is.

from npbehave.

ah right, BLOCKED might be not very obvious, it's meant in case you need to wait for some kind of initialisation before you want your action to be started. It doesn't actually abort the task like returning FAILED would do, but try to trigger your action again next frame without re-evaluating the parent nodes or even the entire tree ( as returning FAILED could potentially do ).

Anyway that's more for kinda specific uses, so the recommended way would be to create your own Tasks classes anyway .

from npbehave.

Understood, what sould be returned then when task is "cancelled"? Is the result even considered?

from npbehave.

In NPBehave terms, you cannot "cancel" a task from within the task. A task can either: Succeed, Fail or stay in Progress.

Cancelling always happens either by some other higher priority node requesting stopping of your node, the entire BT being stopped or if you hit the Stop Button in the Debugger window.

So in case something inside your task logic wants the task to stop running, what you want to do from within the task is Succeed or Fail. For example if you have an "Attack" Task, but the player blocked it, you could "Fail" your Task to allow a parent selector node to fallback to a different strategy. If you fail or succeed depends really on the way how you structure your BT.

from npbehave.

I meant that the bool param passed is a request to cancell

from npbehave.

sorry, of course!
So in that case you either return Succeed or Fail, again depends on the structure of your BT. In case you got aborted with IMMEDIATE_RESTART or LOWER_PRIORITY_IMMEDIATE_RESTART the return code shouldn't matter. EDIT: I read up the code and it's also the case for IMMEDIATE_RESTART rules: see next comment below

For now I would suggest you to always return Fail in case you got cancelled.

from npbehave.

OK sorry to make this detailed explanation here, but it has been a while since I implemented it and a a general answer on what to return (SUCCESS or FAILED) is not really possible, but I want to give you the best explanation possible.

The following is however only relevant if you actually use Stops rules. If not, then just ignore the whole topic and just always return FAILED - the cancel boolean should never be true in that case anyway

I've checked the unit tests and to clarify, regardless of the Stops rule you use, the return code of a branch will result in the parent composite to continue it's execution based on the composite's rules.

So to give some examples:

1. in case the aborted branch is nested inside a Selector node and stops with a FAILED:

• without IMMEDIATE_RESTART: would just start the next child of the Selector
• with IMMEDIATE_RESTART: would start the node that cancelled your action
• (that's why I recommend returning FAILED if in doubt, because from my experience this is most likely what you want)

2. in case the aborted branch is nested inside a Selector node and stops with a SUCCESS:

• without IMMEDIATE_RESTART: the selector would succeed (traversal continues as usual)
• with IMMEDIATE_RESTART: the selector would succeed (traversal continues as usual)

3. in case the aborted branch is nested inside a Sequence node and stops with a FAILED:

• without IMMEDIATE_RESTART: the sequence would fail (traversal continues as usual)
• with IMMEDIATE_RESTART: the sequence would fail (traversal continues as usual)

4. in case the aborted branch is nested inside a Sequence node and stops with a SUCCESS:

• without IMMEDIATE_RESTART: would just start the next child of the Sequence
• with IMMEDIATE_RESTART: would start the node that cancelled your action

So as I said, it really depends on what you want, however to get closest to UE4s behaviour I would recommend returning FAILED and using the IMMEDIATE_RESTART versions of the stops rules.

It's possible that I will simplify aborting rules in a future version of NPBehave, because actually the non-IMMEDIATE_RESTART are imo not really that useful and in any case, aborting should always just continue execution at the node that aborted it.

from npbehave.

I've documented the parameter in the README https://github.com/meniku/NPBehave#action

from npbehave.