unexpected behavior

[bcristian]

I don’t know if I should call this a bug or something that should be emphasized by the documentation, but it certainly was for me unexpected, and took a few hours to figure it out.
A reset event, checked by a conditional decorator, the action is to set a bb integer to -1, let’s call it “crt”.
A set event, also checked by a conditional decorator, that has an integer argument, that the conditional saves into that same “crt” variable.
A number of identical buttons, each has an index >= 0.
When clicked, if the “crt” variable is >= 0, they raise the reset event first. If the clicked button was not the selected one (i.e. if its index did not matched the “crt” value), it raises the set event with it’s own index.
The behavior handling the events checks the reset event first.

But implementing the above does not work as expected, and it took quite a bit to figure out why.
I was expecting that the conditionals are evaluated when graph execution reaches them, which is also when they make any state changes (e.g. setting bb variables). And this is indeed how most of them work, but not the event checking conditionals. Instead, these are triggered as soon as the event is raised, and change bb variables at that point too. Which in my case meant that when going from a selected button to another, and the event sequence was “reset” followed by “set to new index”, the set conditional would immediately set the “crt” variable to the new index, only for it to be overwritten by the actions conditioned by the reset event.

Why the event-checking conditionals are implemented that way is easy to understand.
But is it also semantically correct, or the behavior one would reasonably expect?
In my case (with a C++/C# background) it obviously isn’t, but then again maybe there are coding/logic paradigms where this is in fact the norm – which is why I didn’t call this out a bug.

From my point of view, I think the best way of dealing with events would be to use the semantic they have in C# (and Java, Python, etc.) – once raised, all the listeners are immediately executed, in no guaranteed order. This would mean creating event-type behavior tree roots, like “Start”, and either have multiple trees in a BT owner or separate BT’s that start with an event checked instead of “start”.

The above would of course be a major change and paradigm shift, and maybe not even a direction you would like to go.
In this case, I think the best change would be to not do any state (bb) change in the immediate event handler, but only to set the flag that the event occurred (like it also does now), but save any argument to an internal temporary variable and only do bb checks/changes on the proper node execution.

[Gavalakis]

Hey,

I’ve read your post more than twice, but I really have a hard time following :/ I’m really sorry especially considering that you have taken the time to write a really big explanation.
Can you please share an image of a tree (or a small reproduction package) just so that I can better understand what you mean?

Are you referring to the fact that when an event is send (through SendEvent method or action), that the event is not latched to be consumed by the condition CheckEvent as soon as it executes, but rather it is immediately checked if the condition is already evaluating at the time the event is send and only returns true for the immediate next one frame?

Please let me know if that’s the case.
Thanks!

Join us on Discord: https://discord.gg/97q2Rjh

[bcristian]

Hi
I’ll create and upload tomorrow a package with the behaviors, as it’s indeed quite difficult/lengthy to explain.

[bcristian]

Check this scene to see what I mean.
On the Canvas BT there are both the non-working version and the workaround.
The key point is when the “check event” condition sets the global crt variable.

asd

Attachments:

You must be logged in to view attached files.

[Author]

Posts