Skip to content

Reset messages

Jump to bottom
Alberto Tacchella edited this page Jul 26, 2018 · 6 revisions

The following is a sketch for the proposed mechanism for sending "reset messages" to skills.

Sequence nodes

Suppose given a node Sequence A1 A2. On the first execution the following 5 cases are possible:

  1. (A1=Fail, A2=None (skill not ticked), result=Fail)
  2. (A1=Runn, A2=None, result=Runn)
  3. (A1=Succ, A2=Fail, result=Fail)
  4. (A1=Succ, A2=Runn, result=Runn)
  5. (A1=Succ, A2=Succ, result=Succ)

This return status will be cached in the BT data structure. On the next execution of the same Sequence node:

  • In cases 1--3 no reset messages are ever needed (for every possible return value of the skills), so everything can proceed as usual.
  • In cases 4 and 5, there are two possibilities:
    • Skill A1 returns again Succ. In this case no reset actions are needed, evaluation proceeds as usual.
    • Skill A2 returns Runn or Fail. In this case we must send a reset signal to A2, or (more generally) to each successive child of the Sequence node whose previous (cached) result was Succ or Runn (but not Fail).

(Notice that Cases 3-5 would also need a different algorithm in case of a "node with memory" (a.k.a. starred node); in any case, it does not seem necessary to provide such nodes as primitives -- they are trivially implementable via a binary fallback subtree).

Fallback nodes

Here the five possible cases after the first tick are

  1. (A1=Fail, A2=Fail, result=Fail)
  2. (A1=Fail, A2=Runn, result=Runn)
  3. (A1=Fail, A2=Succ, result=Succ)
  4. (A1=Runn, A2=None, result=Runn)
  5. (A1=Succ, A2=None, result=Succ)

Here it seems that we should reset A2 in cases 2-3 if, at the next execution, A1 returns Runn or Succ.

Parallel nodes

For parallel nodes, a "short-circuit" semantics seems appropriate: as soon as enough children have returned Succ of Fail, we send a reset signal to the ones which have returned Running.

Clone this wiki locally