i will take my time and look at this carefully. Thanks!!!

Nice to see someone working on this, thanks! I'm also going to try to have a look next week.

This caught my attention:

@facontidavide The idea behind this is, before ticking an async child, the BT should halt the other running children (if any). Let me know what do you think about this.

Have you thought about letting the first async node finish execution when ticking the second async node instead of halting the first async node right away? This would mean both would run at the same time for a certain period. That's how I would imagine a reactive sequence to behave and it would allow for some nice use cases.

Nice to see someone working on this, thanks! I'm also going to try to have a look next week.

This caught my attention:

@facontidavide The idea behind this is, before ticking an async child, the BT should halt the other running children (if any). Let me know what do you think about this.

Have you thought about letting the first async node finish execution when ticking the second async node instead of halting the first async node right away? This would mean both would run at the same time for a certain period. That's how I would imagine a reactive sequence to behave and it would allow for some nice use cases.

That is possible already (but be careful in doing so). When sending the halt, it calls the halt() function, however the execution of the tick() is not stopped if not handled explicitly. To handle the interruption of the tick() execution you can do something like this:

In the halt() you set a variable

and you check it in the tick()

Anyway, If you want to discuss more about this, I think it is better if we move the conversation in another place (i.e. not in a PR).

Cheers
MC