-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Expose missing AnimationNodeStateMachinePlayback to scripting to allow serialization #7885
Comments
I can agree with exposing some of the internal properties about AnimationNodeStateMachinePlayback, but I think there are a few properties that need to be readonly for state safety. However, I think it will be difficult to do things like save the state itself if we can't rewrite it, so some properties will only have a getter, and when you want to set them, you will need to go through a higher level setter that requires a structure or some properties. For example: StringName get_prev_node();
// void set_prev_node(StringName p_node); // This should not exist because it could break the state.
// The prev_node should only allow setting through an API that guarantees such a safe state.
void set_prev_and_current(StringName p_prev, StringName p_current, real_t p_progress);
May be related with godotengine/godot#77347. @Daylily-Zeleen Also you might be interested. |
Describe the project you are working on
3D VR online virtual worlds application.
Describe the problem or limitation you are having in your project
The AnimationTree, but more specifically, the AnimationNodeStateMachine, currently relies on an internal resource called AnimationNodeStateMachinePlayback to keep track of certain state, including travel paths, state transitions, and playback position. This resource, however, does actually expose all of internal variables to scripting, and doesn't expose any of them to writing. As a result, if a game requires precise savegame serialization, such a heavily state-machine driven gave, it cannot reliably save and restore the data required to accurately reconstruct the exact properties of a working AnimationNodeStateMachine.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The simplest solution is to expose this to the scripting API, though this might also invite broader re-evaluation of some of the internal of how animation state is tracked, but one way or another, there needs to be a way accessing the full playback state so accurate serialization can be performed.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
It would simply involve new functions added to the AnimationNodeStateMachinePlayback resource to allow both read and write access to these hidden properties.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Since there is currently no way via scripting to access the full internal playback state of an AnimationNodeStateMachine, engine changes are required in order to make this happen.
Is there a reason why this should be core and not an add-on in the asset library?
See above.
The text was updated successfully, but these errors were encountered: