strange 'debug break' behaviour

[WiredEarpParticipant]

I have a very basic AI test project. In this project, I have a Target and an Enemy. In the BT, I meant to use a PARALLEL for the header, but accidentally changed it using ‘switch to’ to a SEQ while playing around (its a bit of a gotchya that it doesn’t change the name of the node when you do this switch, although I can see why it has this behaviour. Perhaps if the node has the default name though, it should be switched to the correct name of the node on using ‘Switch To’, to avoid confusion).

Anyway, using the SEQ, I noticed a strange behaviour. Specifically, I have this setup:

SEQ (repeat forever)
- DETECT (until success) - this sets a form variable DetectTargetPos
- MOVE (forever)

I would have expected the detect to null the DetectTargetPos once the target was out of detection range. However, this doesnt happen - if I move the target out of range of the Enemy, it still moves to the target. HOWEVER, if I click ‘Debug Break’ on any of these nodes, then the DetectTargetPos variable IS nulled (and so the enemy stops chasing). This happens even if I double click the Debug Break quickly enough that it doesn’t actually get hit, so doesn’t pause the game. So, behaviour when I double click ‘Debug Break’ is different to when I dont.

I’ve moved my header node back to a PARALLEL which works fine for me, but would like to know exactly why using the Debug Break option is giving different behaviour when I use it to when I dont? I thought Debug Break was simply setting a breakpoint, but it seems to be forcing some sort of refresh?

If necessary, I can upload my sample project, but it should be simple to replicate. I’m running RAIN 2.1.6.1 which I believe is the latest.

[primeKeymaster]

Any changes you make to the behavior tree at runtime, including toggling the debug break option, does cause the behavior tree to reset. When it resets, it starts back at the top of the tree.

The reason the detect isn’t nulling out the variable is that once it detects the target, it never runs again. In the sequencer, the Detect will run until it succeeds, then move on to the Move node. The Move node repeats forever, so the detect will never run again and will never get a chance to unset the variable (which is why using a parallel is necessary.)

We’re already looking at numerous changes to the behavior editor, including limiting when the BT gets reset. Thanks for the suggestion on swapping the name of the node in the default case.

[WiredEarpParticipant]

Thanks Prime - I was wondering if it was something like that, and just wanted to make sure that was the cause of the behaviour. Good info to hear that making any behaviour changes does the same thing as well.

[Author]

Posts