godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.16k stars 97 forks source link

Add a global parameter input node for AnimationTree #1261

Open mrzapp opened 4 years ago

mrzapp commented 4 years ago

Describe the project you are working on: A general purpose framework for RPGs

Describe the problem or limitation you are having in your project: The AnimationTree requires parameters to be set on individual nodes with specific paths

Describe the feature / enhancement and how it helps to overcome the problem or limitation: A "global" parameter input node added to the AnimationTree, so we can set parameters once and use them anywhere.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

Current UI, parameter values have no dynamic input:

image

Possible future UI, parameter values can use dynamic inputs:

image

Usage:

animation_tree.set("global_parameters/collider_height", my_collider.shape.height)

If this enhancement will not be used often, can it be worked around with a few lines of script?: No

Is there a reason why this should be core and not an add-on in the asset library?: This is would be deeply integrated with the AnimationTree

mrzapp commented 4 years ago

A better name for this node might actually be "blackboard", considering its functional similarity with blackboards in behaviour trees

desperate-coder commented 4 years ago

@mrzapp Imo i would settle to name it as before, since "blackboard" seems too specific. As i understood this proposal, the "Parameter"-node only provides a specified variable in the Tree-node, that can be accessed by the child-nodes from the topmost root and be linked to an appropriate connection-point.

If it is intended for the connected nodes to listen to the change of the linked parameter-value, then maybe "Property" might be suitable as well? Not sure if this proves to be very efficient though, said connections have to be established after all...

Also the data-type has to be considered, maybe there should be a type-specifier when setting up the parameter?

Ivanfs8 commented 3 years ago

It's kinda underestimated how much extra lines of code you need to use for the animation tree to work and be responsive. In a recent small 3D project I had to set the current velocity to at least 5 different blend nodes, imagine a complex character with different states like crouching, aiming, shooting, jumping, etc. This proposal would make the animation tree much more useful and faster to develop

Ivanfs8 commented 3 years ago

I think the global parameter node should also denote what type of variable it is, since blend trees use floats and state machines use bools. It would be just like visual scripting where floats are light blue and bools purple

elXill commented 1 year ago

At first I also supported the need for a global parameter for AnimationTree.

But after some time I learned you can add a script to AnimationTree and use variables in it, which pretty much gives the same flexibility I wanted

ouijahija commented 1 year ago

Just leaving a comment to show my support for this idea. I might be to used to how unity handles animator variables, but how godot currently handles it's AnimationTree variables is just unneccessairily complicated...

MarkoSFG commented 8 months ago

I was very surprised that this wasn't already implemented; this is sorely needed (who is going to set 30 different blend values all over a character's AnimationTree when all you want to update is something as simple as walking / running or standing / crouching?).

Another possible implementation (instead of a node that feeds in) is an input field for a global variable to cut down on the amount of nodes needed? (or a dropdown next to the blend value that allows you to choose between the current setup, "node-in" value and then also just a textbox to enter an AnimationTree global parameter name)

bertodelrio256 commented 3 months ago

I agree with the OP, I have a lot of branching transition nodes which are all controlled by the same value. So, in my scripts, I have 8 lines of code for each time this "common state" changes. but for now, this can be shortened by putting these lines in a function. also, you can have the same names for each transition node for instance and call them using the same strings even if you dont know the destination so maybe its not so bad without it but globals would be nice to have.

alex-andromedon commented 3 weeks ago

Had the same issue, but found a simple workaround: 1) On the AnimationTree attach the advance expression base to whichever node has the script you want controlling the tree to the advance expression base property 2) Instead of condition use the expression field, for example "idle == true" will check for an idle var and advance if true