• Editor
  • Auto update first/ last same keys when loop is turned on.

Related Discussions
...

When dealing with looping animation, I always think when a key is modified at the first frame or the last frame, it should be auto updated to the other side as well so that the loop will not broke. Currently I have to copy and paste manually to the other side.

This could be an option to turn on manually so that it would not affect existing user. Although, I could not think of any situation this would cause problem EXCEPT loop state is keep turned on accidentally when switching animation. This lead to the 2nd suggestion: Loop setting should be belong to animation, not shared global.
Whether an animation is looping or not, this setting will generally stay and don't change. e.g. Idle, Walk, Attack, etc.
The desired behaviour is to have dopesheet restore previous loop setting when switching animation.

I guess lots of user will like this improvement too as animations with loop are quite common.

I remember you already posted about this here:
[Add Feature] "Alias" key frames for seamless infinite loops
and an issue has already been opened here:
Sync first and last keys for looping animations · #35 · EsotericSoftware/spine-editor

Regarding the second proposal, looping or not is something that only actually influences animations in the editor, and it's for previewing purposes, plus there might also be times where you want to have a loop even on a non-looping animation. Which is why although your proposal is interesting, I doubt it would actually be used that much/consistently to justify implementing it instead of setting looping and states directly in the runtime.

I agree the first one would be very nice to have, but we have lots of features on the plate, so, as already said, it will still have to wait.
Thanks for providing feedback though! It's appreciated as always 🙂

Haha, my memory is blurry. I didn't realize I did joined that discuss 7 months ago. That post is not created by me and I was just sighing that the issue is 2 years old during that time. That's why I don't recall anything. Sorry to re-mention the issue.

I think I will just write a script to help me sync the keys to the other side since I just found that there are shortcut (q, e) to navigate to start/end frame. It still require one key press but is better than doing all it manually.
(Update: doesn't work. Spine.exe don't accept Ctrl key sent from external script)

Regarding the 2nd suggestion. I know the setting is for editor only . Of course this is for preview. With this change, the need to keep correcting the loop setting when switching between animations can be eliminated for preview. In fact, this change does not affect people who don't care toggling loop setting and use dopesheet to preview looped animations, as it is still 50% wrong for them anyway. However, the current implementation is causing trouble to people who do not have the habit to preview a non-looping animation with loop turned on.

I doubt it would actually be used that much/consistently to justify implementing it instead of setting looping and states directly in the runtime.

This is based on the assumption that most people would do something like "preview a non-looping animation with loop turned on"... I personally would open preview panel side by side to do preview when animating. There is no need to turn loop on for non looping animation. I guess a good design should take care of user with different habit.

If a change don't have disadvantage for both side but have advantage for one side, that change should be considered a good change, right?

FWIW, the fast way to copy a key is ctrl+shift+drag a key. Not as useful as a setting like in the issue above, but it may help.

Nate escreveu

FWIW, the fast way to copy a key is ctrl+shift+drag a key. Not as useful as a setting like in the issue above, but it may help.

Haha, I was trying to use AutoHotKey script to map [Ctrl + Let / Right] to copy current key to one end. e.g. [CTRL+C ] [Q/E] [CTRL+V]
but found that the CTRL key cannot be sent to spine. I guess you did the input handling with direct query on actual key state of the CTRL key. My current wish is not synchronized start/end key but just a (two actually) shortcut to copy the selected key to first / last frame...

13 dias depois

The main reason repeat is not per animation is that there can be multiple skeletons, and so multiple animations active. All animations must use the same repeat setting, since we want to have only one timeline position. However, I do think it is a good idea to store it per animation, so if there is ever a conflict between what multiple animations want for repeat, we'll just not change the repeat button. This has been done in 3.7.78-beta!

Note that it is not exported, this only affects the editor.

Regarding adding "Key First Frame" and "Key Last Frame" hotkeys, we're open to the idea, but first can you explain how you would use it? If I understand correctly, these would take the currently selected keys and copy them to the first/last frame, is that right? Also, why do you need two separate hotkeys? Ie, why not "Key First and Last Frames"?