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

Animations are not resetting properly when played in the editor. #812

Closed
Sslaxx opened this issue Oct 23, 2014 · 27 comments
Closed

Animations are not resetting properly when played in the editor. #812

Sslaxx opened this issue Oct 23, 2014 · 27 comments

Comments

@Sslaxx
Copy link

Sslaxx commented Oct 23, 2014

https://www.dropbox.com/s/krusjk4lh0655da/812_Demonstrator.webm?dl=0

I've noticed if I wanted the animation to reset properly in the editor, I had to either play it and VERY quickly stop it, play it and then rewind the animation back to the start, then (and this is the buggy bit) if I wanted the animated item to work properly again I had to first select it.

The keyframes are at 0 and 0.5, by the way. https://mediencenter.t-online.de/auth/guest/shareToken/DDE241350EA1C553A3945179DF687D896509C0DF is the example uploaded by Wendigo on http://www.godotengine.org/forum/viewtopic.php?f=11&t=1024

@akien-mga
Copy link
Member

I must admit I did not understand the bug by watching the video... I played a bit with the test scene attached in the second link, and couple finally manage to understand what you mean by

(and this is the buggy bit) if I wanted the animated item to work properly again I had to first select it

Indeed if you stop the animation e.g. mid-course in the editor, and then run the game, it will not be shown mid-course. On the other hand, if you select the mid-course animation in the editor, and then play the game, it will be shown mid-course.

@akien-mga
Copy link
Member

After discussing it with @bojidar-bg, it's far from a junior job, as fixing this without a hack likely involves rethinking the way the animation player modifies on the fly the properties of the nodes it acts upon.

@slapin
Copy link
Contributor

slapin commented Apr 23, 2016

Why not just reset all loaded animation resource positions to 0? Should be simple enough.

@slapin
Copy link
Contributor

slapin commented Apr 23, 2016

We have a habit of "lets postpone that as this is too complex", that is not really a good habit.
Lets split big problem into simple ones and solve one by one, instead of waiting for something,
which will probably never happen.

@bojidar-bg
Copy link
Contributor

@slapin Because the 0-frames of different animations might conflict with each other, in which case we get undefined behavior. Don't think we made a quick work of it. We discussed it in depth to the point in which it became obvious that the only "normal" solution would be to rewrite the way animations are played. Not much people know godot code as much as to fix me (I don't either).

Also, if we decide on a solution for the conflicting 0-frame thing, I would be happy to implement it, though it would be behind an editor settings flag.

@slapin
Copy link
Contributor

slapin commented Apr 23, 2016

Could you please elaborate on 0-frames conflict? I don't see a case where that would conflict
at start/initialization time?

@akien-mga
Copy link
Member

The problem is that you can keyframe properties at position 0 in animations, and the way the AnimationPlayer is built in Godot implies that the state of the animation is directly reflected on the properties of the affected nodes.

So imagine that you have a scene with a Sprite with e.g. 10 frames.

  • In animation "idle", you keyframe the frame 0 at position 0.
  • In animation "run", you keyframe the frame 5 at position 0, because it's the first frame you want to use in your running animation.
  • In animation "fight", you keyframe the frame 8 at position 0, etc.

Now if all animations are reset to position 0 upon saving, the question of what frame should be displayed in the Sprite is undefined. Obviously one would like to use frame 0 in my example, which would typically be e.g. a character facing the player. But that's not something the engine could decide by itself. What if the "default" frame should be frame 4?

Same issue if you have animations starting with a fade in, by resetting to position 0 in this animation you may end up having your Sprite displayed with opacity 0 by default.

@puppetmaster-
Copy link

I ask this question again on the proper issues... #8976

Is it possible to rewind each animation before saving (scene) or playing (scene/project)?

@bojidar-bg
Copy link
Contributor

@puppetmaster- Check comments above, slapin specifically asked:

Why not just reset all loaded animation resource positions to 0? Should be simple enough.

The problem is that you might have conflicts between the first frames of different animations, as I and @akien-mga discussed way back (check the other comments for more info).

We can potentially just rewind them in alphabetical order (or some other well-defined order), with the autoplayed animation last, but I'm not completely sold over that idea yet.

@puppetmaster-
Copy link

puppetmaster- commented May 29, 2017

@bojidar-bg Sorry, I have read the comments above but for me reset to position 0 and rewind is not the same.

I found out what the problem in my case is. 😃 Created a new issue. #8994

@Sslaxx
Copy link
Author

Sslaxx commented Jun 1, 2017

Is this fixed (fully or partially) by #8982? That references #8976 which in turn references this.

@bojidar-bg
Copy link
Contributor

@Sslaxx No, if this was fixed, then #8976 could be termed fixed, since we wouldn't be able to reproduce it, the opposite isn't true.

@akien-mga
Copy link
Member

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

@KoBeWi
Copy link
Member

KoBeWi commented Jun 7, 2018

So, I'm making a complex cut-scene that involves multiple animations playing after each other and I find the Animator's behavior to be ULTRA annoying. It's counter-productive needing to rewind your current animation each time you want to see how it looks currently in-game, because otherwise everything dependent is randomly displaced over the scene. The suggestion to reset everything upon saving is unnecessary. I'd be happy with a single button that just resets currently selected animation, basically an instant-rewind, to not waste time carefully moving your timeline back.

@reduz
Copy link
Member

reduz commented Jun 7, 2018

I don't think a proper fix to this exists because the animation system does not really understand initial values.

What I propose, is that one could mark an animation as the "default", and Godot may set the state of the animation to whatever is in there before saving. Optionally, we could add a reset button that appears if this animation exists, so you can use it easily from the editor.

@reduz
Copy link
Member

reduz commented Jun 7, 2018

Or maybe when the scene is loaded in the game, the "reset" animation applies its values to everything.

@KoBeWi
Copy link
Member

KoBeWi commented Jun 7, 2018

My problem right now is that whenever I want to play my scene (which is necessary for full test, because I use some stuff outside animator), I have to either rewind the animation by moving timeline manually (absolutely awkward and you need to be careful not to skip some values) or press the rewind button and wait 15 seconds. I need a way to speed-up the process, so a reset button that instantly rewinds the animation and sets all tracks to first value in timeline, would be sufficient.

Unless I'm doing something wrong and there's a better way. I'm using a series of single animations for a cutscene and I need to rewind just one of them at a time.

@reduz
Copy link
Member

reduz commented Jun 7, 2018

@KoBeWi, I would appreciate more constructive feedback to what was proposed.

@KoBeWi
Copy link
Member

KoBeWi commented Jun 7, 2018

The "default" animation isn't really needed, but could be there as an option. I'd be for resetting everything in alphabetical order, so you can manipulate animation sorting to resolve conflicts yourself. Setting a "default" animation could override this and just reset all values to this particular animation.

As for resetting, a reset button would be obviously useful. Not sure about auto-resetting, unless you'd be able to select when it's happening. Some people might want it when saving and some only when running scene. Also, there could be distinction between "reset all" button, which would have the behavior I described above and "reset current animation" button.

btw, you said animation doesn't understand initial values, but they are just values at first key in respective track.

EDIT:
I've just seen your comment on Reddit and seems like misunderstood your idea about "reset animation". This could be nice workaround, but you'd have to set all initial values manually (while they are already defined in different animations), which sounds like could be a hassle.

@reduz
Copy link
Member

reduz commented Jun 8, 2018

@KoBeWi different animations may have different initial values, so there is not really any information for resetting. This is why I think the only practical way is to defining a special animation with the initial values on load

@KoBeWi
Copy link
Member

KoBeWi commented Jun 8, 2018

That's why I said they should all at once be reset in e.g. (reverse) alphabetical order. This way initial values would be the ones from last animation. But well, if that "special animation" you mention gets special treating (like being played before actual autoplay animation or having a dedicated reset button), it should be fine too. Still better than what we have now.

@cart
Copy link
Contributor

cart commented Jun 8, 2018

I dont think using names to create a precedence order is a good idea. Changing an animation name shouldn't affect state like that. And any sort of ordering seems overly complex / hard to reason about.

I like @reduz's "default" approach. Its simpler and more explicit. In my project I frequently use a "default" animation to reset animation state in editor and in code. It would be nice to formalize that.

@akien-mga akien-mga added this to the 3.2 milestone Nov 22, 2018
@KoBeWi
Copy link
Member

KoBeWi commented May 19, 2019

Soooo... how about some super-magical UndoRedo action triggered on play and commited on stop that would record all changed properties, so you can easily undo them?

@Anutrix
Copy link
Contributor

Anutrix commented Oct 20, 2019

Any updates?

@rvenson
Copy link
Contributor

rvenson commented Jan 19, 2020

@KoBeWi different animations may have different initial values, so there is not really any information for resetting. This is why I think the only practical way is to defining a special animation with the initial values on load

The values that we set in the editor can't be used as default values for all the animations? I don't know if I understood the problem clearly, but I have an annoying issue related to this:

ezgif-3-8bda173ce0a7

An example of unintentional lost of information

Ex.:

  • Create a black background (ColorRect)
  • Create an AnimationPlayer and an animation that change the background to red colour at whatever frame (without defining any first keyframe)
  • Play the animation
  • Now the default value (black) that I defined in the editor was lost forever!

I know that I should define the first keyframe with the black colour, but then we go back to the rewind issue problem. And sometimes, you just need to change the background colour to red, regardless of the actual colour in-game.

ezgif-3-fddf857e89a5

Rewind to get default values on animation

Sorry for any missconception and let me know if there is any workaround about this. :)

@niceeffort
Copy link

Just hit this issue myself. I would put this in the same family of confusion as #17903. Values changing in the inspector are confusing. If I change values in script, they don't maintain those changes. But if I change values with the AnimationPlayer, the changes will remain. I am solving this by setting default values in the _ready(). This has two implications from a usability standpoint:

  1. I have to change my thinking as to how to use the inspector window. When using the AnimationPlayer it is important to understand that those values are not defaults, but rather a way to input values for the animation key frames.
  2. I now need to remember to hard code the default values into my _ready() function for every value that I change. I could make a default animation to store these as well, but the same bookkeeping remains. I may try that as well just to see the difference.

Overall I am loving Godot and I have a workaround so I can move forward. No matter what tool you pick you will hit these sorts of things if you use it long enough and I am very appreciative of the hard work the community has put into this!

My suggest would be to consider another button or mode on the Inspector window to specify if you are setting/viewing default or animation values.
AnimationSettings

@KoBeWi
Copy link
Member

KoBeWi commented Oct 8, 2020

Closing in favor of godotengine/godot-proposals#1597 which would fix this issue.

@KoBeWi KoBeWi closed this as completed Oct 8, 2020
@KoBeWi KoBeWi added the archived label Oct 8, 2020
@KoBeWi KoBeWi removed this from the 4.0 milestone Oct 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests