Closed Franz-Inc closed 9 months ago
I think I solved my use case by adapting one of your _on_utility_ai_agent_behaviour_changed(behaviour_node): examples and using .get_parent(). Basically, I assess if a group has changed everytime the behaviour changes by comparing .get_parent() of old and new behaviour, and if its new, I run an end/start behaviour_group scripts that are loaded on each behaviour group.
func _on_utility_ai_agent_behaviour_changed(behaviour_node):
var new_group: bool = false
if current_behaviour != null && behaviour_node != null:
#current_behaviour.end_behaviour(self) -- not needed yet
if behaviour_node.get_parent() != current_behaviour.get_parent():
new_group = true
current_behaviour.get_parent().end_behaviour_group(self)
else:
new_group = true
current_behaviour = behaviour_node
if current_behaviour != null:
my_behaviour_label.text = current_behaviour.name
if new_group:
current_behaviour.get_parent().start_behaviour_group(self)
#current_behaviour.start_behaviour(self) -- not needed yet
else:
my_behaviour_label.text = "No behaviour!"
Good that you found a workaround. I've added the signal now as well. What system are you running? I can provide binaries so you can test if the signal works as you expect.
Oh wow, that was fast. Awesome! I'm running Godot 4.2 on Windows 11. I'm not actually a programmer (other than casual python scripts and hobby gamedev), so I don't actually know what to do with binaries.
No worries, the binaries are just the dll-files for the extension. Just in case, take a backup of your godot project folder before trying these out. I don't think anything will go wrong and everything worked in my test project just fine, but I still want to play it safe so you don't loose any progress on your project if I have managed to add a bug in addition to the signal.
Extract the files in the attached zip-file and then copy them over the existing ones with the same names in the addons/utility_ai/bin folder of your godot project. If you want to go back to the previous version, just copy the old dll-files over the new ones from your backup.
libutilityai.windows.template_debug.x86_64_for_testing_signal_20240111.zip
It seems to be working! Nice one!
Just for my own info, is this how I would update your add-on in the future? When you release subsequent versions, I merely copy over the updated DLL files (backing up accordingly, of course)?
Speaking of backups, I guess I should finally wrap my head around using git with Godot...
It is best to copy the whole utility_ai folder. This way any other content, like icons, config files or in the case of the coming version, some debugging scenes will be added.
Actually just coming back to this, I noticed this error message thast gets triggered when the UtilityAIAgent.evaluate_options(delta) is run:
This may be related to the changes you made? I rolled back to my project before the dll change, and the failures we're not there. Cheers
Sorry about that! Here's a fixed build. The signals in godot don't have the "on" prefix so I changed the naming to match the usual way, and missed the behaviour group signal names. Basically when there's the "on" in the name, the method becomes _on_on_signa_name so the on-word is duplicated in the method name.
Sorry, it took me a bit before I finally got around to testing, but this did the trick! Thanks as always for your speedy support!
It might be useful to have signals for On_Behaviour_Group_Changed as well (or on action_group etc). I am using Behaviour Groups to organize my actions, and have been grouping them into States of Awareness of sorts. Similar to your vision and hearing Baddie example, my enemy will see the player and go into a Combat Behaviour Group. Once he looses sight of the player, he will revert to a Searching Group, triggering a Search Timer. However, I would like the flexibility for this timer to start once the Searching Group is entered, rather than when he looses sight (as there may be other reasons for the Behaviour groups to change). Also, if I start the timer when he 'looses sight', this doesn't take into account any delay due to the thinking_delay_in_seconds parameter (since the timer would start immediately, but the actual behavioural switch would occur after x seconds)