Question about Few Things and Thank you for supporting this! <3

[ashfidable]

So, I have been looking into different behavior trees and everything to jumpstart. This is probably the best I have seen so far and loving the constant support. I tried few behaviors with timer and it's pretty fun to see the flow right on the tree.
I will start with the questions:

• Why did you opt for physics_frame and idle_frame approach than normal process and physics_process? Not going to lie, I am loving this and did learn a new thing. Are they even different from godot's own built in functions (idle = process, physics = physics_process)?

• I created this custom patrol behaviour (it's barebones right now) but I keep getting assertion failed because of "not running()". The code is below.

go_to_position.gd

extends BTLeaf

func _tick(agent: Node, blackboard: Blackboard) -> bool:
	var ag = agent as Agent
	ag.move_towards_position(Vector2(85, 190), blackboard.get_data('delta'))
	if ag.global_position.distance_to(Vector2(85, 190)) <= 50:
		return succeed()
	return running()

agent.gd

extends KinematicBody2D
class_name Agent

export (NodePath) var blackboard_path
export (float) var speed

onready var blackboard = get_node_or_null(blackboard_path)
onready var sprite: Sprite = $Sprite

var velocity: Vector2

func _ready():
	blackboard.set_data('position', $Node/Position2D.global_position)

func _physics_process(delta):
	blackboard.set_data('delta', delta)

func move_towards_position(target_position: Vector2, delta: float):
	print(target_position)
	var difference = (target_position - position).normalized()
	velocity = move_and_slide(difference * speed, Vector2.UP)
	velocity.normalized()

I am pretty sure it's my mistake, if so.. I would love to know fix and few pointers based on the script. You have been massive help to my workflow, I would love to continue using this.

[kagenash1]

First of all, thanks for the kind words! I'm glad to see this tool is helping someone and I'm doing my best to improve it and address everything.

As for you first question, in the next version I'm going to switch to the _physics_process and _process functions, because what I did there doesn't make much sense :)

About your problem, right now the way to leave a node running is not to call run(), which is called automatically at each tick(by the way, running() is to check whether it is running), but to yield() for something.
In fact, since run() is called automatically, if you yield() the tree will automatically understand that the node is running and progressively suspend the execution of all the higher nodes for optimization.
Your leaf then must only return either succeed() or fail(). If you yield(), then the node must be running().

With that being said, here are a few alternatives to make this work:

In this case, we consider reaching the goal a success, and not reaching it a failure.

go_to_position.gd

extends BTLeaf

var ag: Agent # Useless optimization
var destination: Vector2 = Vector2(85, 190)

func _tick(agent: Node, blackboard: Blackboard) -> bool:
	ag = agent
	ag.move_towards_position(destination, blackboard.get_data('delta'))
	if ag.global_position.distance_to(destination) <= 50:
		return succeed()
        else:
                return fail()

EDIT: The above example allows you to do something cool. You can put this leaf under a "bt_repeat_until" and set it until success.

or, let's change the way we think of it a little bit. The action is successful if you move, not if you reach the goal.

agent.gd

func move_towards_position(target_position: Vector2, delta: float) -> Vector2:
	print(target_position)
	var difference = (target_position - position).normalized()
	velocity = move_and_slide(difference * speed, Vector2.UP)
	#velocity.normalized() # I'm not sure what the purpose of this is, it return a new Vector2 but it is not assigned to anything.
        return velocity

go_to_position.gd

extends BTLeaf

var ag: Agent # Useless optimization
var destination: Vector2 = Vector2(85, 190)

func _tick(agent: Node, blackboard: Blackboard) -> bool:
      ag = agent
      var velocity = ag.move_towards_position(destination, blackboard.get_data('delta'))
      blackboard.set_data("distance_to_destination", agent.global_position.distance_to(destination))

       if velocity.length() > 0.1: # If we moved
		return succeed()
       else:
                return fail()

So what? Now you know the distance to the destination, so after the agent moved (successfully) you can have a conditional node (a decorator) where you say if distance <= 50 execute whatever you have to execute.

I think the last option makes the most sense, because why setting a leaf to a running state if it's not running? You are gonna call it every frame, so it is gonna run and complete successfully at each frame. The action is to "take one step", not to reach the goal, so it is successful at each step :)

Moreover, another reason why your leaf cannot be running, is that you are doing a move_and_slide() call at each frame. By definition, if the leaf is running(), it will not be ticked, because the tree suspends execution while it is running. This is wrong because you do wanna tick it at every frame, and thus you wanna either succeed() or fail() at each tick() call.

(I'm assuming you know how to use yield, but if you don't I suggest you to check the documentation in the GDScript Basics page, at 'Yield and Coroutines'. On top of that, I suggest you to check the two script templates I included, where you find an example on how to do all the things you might wanna do with leaves and decorators.)

This whole process is gonna change in 1.2.0, where I plan to use the run() method for consistency and to even allow aborting running states, but until then this is how it works. I will try to make the future update so that it will not break your previous trees too much.

I hope I clarified your doubts and if you need more support feel free to ask :) I'm open to suggestions and change proposals if they are requested!

[ashfidable]

First of all, I would like to thank you so much for replying as soon as possible. You are a life savior for real and yes I am aware of yields (pretty powerful coroutines really). So, I did read the whole thing and honestly the last one works pretty well to me due to separation of distance check and the whole move_towards_position thing. Happy to say, it's working great here.

My bad about velocity.normalized() thing, it was from my main project and I had to cut out most of the code to paste it here for easy debugging - sadly forgot to take that off haha

Honestly, I do like this idle_frame and physics_frame thing. It looks nicer but that is no surprise that many here are used to physics_process and process instead. However, I am happy either way and loving the fact that you are catering towards user experience more.

Coming to think of it, how would you go about implementing patrol between x number of points?
I was trying it now and most probably my head isn't working due to sleep but here's how I structured it for now.

• BT
• BTSequence
  • BTSequence
    • AssignPoints (Assigning a point from waypoint_list to a blackboard key called current_point)
    • GoToPosition (Same thing as above but instead of hardcoded Vector2, its referring to current_point key)
    • Distance Check (Decorator)
      • AssignAnotherPoint? (But then this will get changed when it repeats the tree again, so it's pretty pointless here)

Why the awful suggestion for the second AssignAnotherPoint was because the first AssignPoint keeps on repeating itself, so the current point keeps on changing. Let me quickly type out basic code for choosing a point from list

change_points.gd

extends BTLeaf


export (Array, NodePath) var waypoint
var curr_point = 0


func _tick(agent: Node, blackboard: Blackboard) -> bool:
	curr_point = (curr_point + 1) % waypoint.size()
	blackboard.set_data('current_point', get_node(waypoint[curr_point]))
	return succeed()

Also, is it weird to say I am hyped about 1.2.0 than Godot 4.0? - you are killing it with the updates. When do you think that's going to come and will it change fundamentally when supporting nodes? Although, that's not an issue. Logic anyways in every node stays the same for sure. So, it's hardly any problem haha.

[kagenash1]

The first thing I can suggest is to think of this in the opposite order, first check if it's reached, and move if it's not.
So basically:

_BTSelector (instead of sequence)
_ _ IsPointReachedOrNull? (extends BTDecorator)
_ _ _ AssignPoint
_ _ Move

If you look carefully I said reached or "null". You have a lot of freedom on this, but in general you may want to have some additional information (in this case, when the point is null) to know when to start the whole process.

I've been developing this for months and sometimes I forget the reason why I did things. There reason why I didn't use process is because I wanted to stop execution, and process is called at every frame. But that can easily be fixed with set_process(false), which, incredibly, I didn't know of at the time lol.

The visual editor is just gonna be on a higher level and won't change the actual logic (it will dynamically create a SceneTree).
As for all the other changes and improvements, I will make sure they are backward compatible, since there are already a few people using this.
So far I've been pushing changes recklessly cause I was the only one using it, but now I have to be more careful 😄

I'm flattered that you are waiting for the update, ha! Godot 4 will bring lots of crazy improvements that I'm looking forward to to improve the Behavior Tree. But I have a whole LOT of improvements and future versions planned, as I'm actively using this in my game and sharing the improvements as I go.

[ashfidable]

OOF. I am the dumbest person alive. Here I was thinking assertion crashes when the condition IS met. I tried putting two timers and it's working. God, I feel embarrassed to keep making this mistake. I did change the assert line to print line to remind me what's wrong in it.

[kagenash1]

😆 don't worry. It's clear I should print some kind of error in the next version.
The assertion is there to prevent doing meaningless things, but obviously if you remove it it will work.
My suggestion is you not remove it because I think it helps: I very often found myself having unnecessarily big trees because I accidentally left single-child sequences or selectors.
What you could (and should) do if you just wanna lay out an abstract version of the tree, without implementing the actions, is to populate the sequence with empty BTLeaf nodes (instead of wait nodes which will stop the tree), and give them proper names, but without extending the script to implement the action. Empty BTLeaf will work fine and they will just succeed() at every tick.

[ashfidable]

Woah, that's actually pretty good suggestion! I am already saving branches as scenes (God, Godot is freaking amazing at that) and this will make less mistakes on my part.

I don't know how to thank you for helping me with this. I am getting better at this. Seriously, go to asset for any game with complex AI to me. There are other behavior trees but the discussion is too minimal and there are not really much of starter BTNodes to do whatever you want. This one got almost everything I want from nodes.

Coming to think of it, when do you see 1.2.0 coming since it's really huge in update compared to incremental ones?

[kagenash1]

Yeah that's good! I tend to have several trees rather than a big one. Then I can separate my AI more, for example if I have an enemy I will make a BT for pathfinding, one for movement, one for shooting, and so on. They are more controllable this way, and the good thing is they can all use the same blackboard to communicate between each other.

I'm glad you are comfortable with my tool, I hope you can achieve the AI you want and break the monotony of game swith state machine AI, lol. Looking forward to what you create.

As for the new version, I don't know really. I am developing the package as I progress with my own game. The next version will be 1.1.3, mostly with bug fixes and minor improvements, and that will probably be the stable version for the time being. But I am not rushing it cause I wanna make sure I address every bug, so as long as I find stuff to fix I'm not releasing it.
Then 1.2.0 will start being worked on but that will require even more time, and since 1.1.3 will be stable development won't be so urgent, cause I also wanna focus on my game and that version will be good enough.

To summarize, I'm glad you are looking forward to it but don't overthink it, 1.1.3 will be a very "light" update and you will have no problems using it with your previous trees. So have fun with the current version, cause 1.2.0 will take quite the time 😆

(This is unless some kind of driving force cough cough donations cough turns up, or the community grows and someone happens to develop good enough features for the new version)

[ashfidable]

That's great! I am planning to wrap BT with one or two states for aware and unaware state. So far, it's working pretty good!

Please take your time with 1.2.0, it's a really huge update with graphedit and everything. I am really happy to know that 1.1.3 will not touch the logic of our action and decorator codes!

Keep doing what you do man, one of the best packages in recent times for sure on godot.