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

Unexpected behavior on SpriteFrames animation FPS config #79445

Closed
stephannv opened this issue Jul 13, 2023 · 1 comment · Fixed by #79692
Closed

Unexpected behavior on SpriteFrames animation FPS config #79445

stephannv opened this issue Jul 13, 2023 · 1 comment · Fixed by #79692

Comments

@stephannv
Copy link

Godot version

v4.1.stable.official.970459615

System information

Vulkan API 1.2.231 - Forward Mobile - Using Vulkan Device #0: Apple - Apple M1 Max

Issue description

When changing a specific animation (eg. animation_a) FPS if you click on another animation name (eg. animation_b), the new FPS value is assigned to both animations.

Steps to reproduce

  • Create two animations
  • Select one animation
  • Click on FPS input and change to a new value
  • Click on another animation name
  • Now both animation with have the same FPS value.
Screen.Recording.2023-07-13.at.18.30.04.mov

Minimal reproduction project

Doesn't need a specific project, just create a new project and a new AnimatedSprite2D and assign new sprite frames and follow above steps.

@Miguel0312
Copy link
Contributor

I am trying to solve this bug and the the relevant class is SpriteFramesEditor defined in the file sprite_frames_editor_plugin.h.

The problem is due to a value_changed signal emitted with the old value of the anim_speed field.

For some reason this signal is emitted after the _updated_library function is executed but still with the old value, but I can't find out what is triggering this signal. If anyone has an idea why this is the case, I would appreciate an explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants