Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert BehaviourToolKit to use resources and graphic edit #65

Closed
Shadowblitz16 opened this issue Dec 31, 2023 · 1 comment
Closed

Convert BehaviourToolKit to use resources and graphic edit #65

Shadowblitz16 opened this issue Dec 31, 2023 · 1 comment

Comments

@Shadowblitz16
Copy link

Shadowblitz16 commented Dec 31, 2023

Consider converting behavior toolkit to use graph edit and resources..

Here are the pros of doing so...

  • Behaviours could still be saved and files
  • Behaviours would be resource based so they would be faster
  • Behaviours would be resource based so no more accidentally overriding _physics process. everything is done through your own bt interface.
  • Behaviours would be safer to export as moddable content since users would only have access to what is provided instead of a whole scripting language
  • Fsm events could be predefined and chosen with a dropdown box (no more invalid events)
  • Parent a child relationships could be staticly typed. (no more adding a Transition node as a child to another transition node only State nodes)
  • Actor signals and properties could be type checked.
  • AnimationTree could possibility be used as the node. aka behaviour toolkit root could extended AnimationTreeRoot

Here are the cons...

  • Rewriting everything as a resource and graph edit takes time
  • Might require implementation of some stuff for getting things like input or using physics since there would be no _input or _physics_process methods
  • Behaviors and states that are saved might need to be populated into a registry of some sort so we can create them later in the graph edit.
@ThePat02
Copy link
Owner

In short: There are way to many benefits of just keeping them as nodes. They are easier to edit, extend and use. You are however free to make your own fork and implement these things by yourself, but the plugin is heading in another direction, as one of the next big PRs will allow users to dynamically move nodes around at runtime. #47

Parent a child relationships could be staticly typed. (no more adding a Transition node as a child to another transition node only State nodes)

When are you doing this? Transition Nodes should only be children of State nodes.

Actor signals and properties could be type checked.

This can be done now by using something like actor = actor as CharacterBody2D.

AnimationTree could possibility be used as the node. aka behaviour toolkit root could extended AnimationTreeRoot

No, this is not possible. You would have to build your own Control.

@ThePat02 ThePat02 closed this as not planned Won't fix, can't repro, duplicate, stale Dec 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants