Hi,
Thanks!
Actually I was not aware of this characteristic of JBT implementation. And so I was not particularly careful about how I implemented my nodes, but strangely I never encountered any issues all along using it for another project and now this one.
If I understand well, multi-threading last only during tick update, so - if I'm right - concurrency problems may arise only between nodes which are children of a parallel node, but still all other parts of the code, including interactions between nodes and engine, are safe. It would explain partly why I didn't experience so much trouble since I don't use much parallel nodes, and if the nodes' execution part contain only condition checks but no writing data, then there is not much to worry (except if there could be concurrency also during node intialization, where most data-writing code occurs, but I'm not sure if this case exists with JBT).
Anyway I guess now I should check all of my nodes again, and be more careful about it in the future. Thank you very much for the tip!
About the reason why I preferred to use JBT over gdx-ai, is simply because I didn't know there were behavior trees in the latter one, so I didn't even compared!
I may check and think about switching to gdx-ai in the future, since a library with much more active development is very valuable, except that I like to have a graphical editor for generating the trees (even if JBT's one is *hum* quite limited), and it seems there isn't already equivalent of this for gdx-ai.