Nate yazdı

Setting a key for each frame is a huge pain, even with hotkeys. We'd like to improve mixing frame by frame with skeletal animation soon-ish. Ideally you'd have a single attachment that knows about all the frames and plays them back at a fixed framerate. This also allows for looping, pingpong, etc throughout animations without needing any keys. The task is in Trello.

Hello!
Have you implemented this function now please?
Because I have more than 100 images and the keyboard shortcuts are not working. It's hell if I have to do this for every sprite, it's about 1 century.

I'm sorry, we haven't done it yet. However, we just finished 4.0 and have plans to do this in 4.1! The issue for it is here:
https://github.com/EsotericSoftware/spine-editor/issues/9

Hotkeys should be working. Maybe we can help with that?

A user created a Python script that you might find helpful:

Ok, thank you. Do you have an approximate release date for version 4.1 please?

4.0 was just released. After some time we will start releasing 4.1-beta versions. When all the features are finished and stable, then we will release 4.1 as non-beta. It will be quite some time, but I'm afraid I can't give an estimated date.

Ok, thank you!

Can you inform me about the content of 4.1?
It will be possible to import a traditional animation and that this is automatically applied with the keys (as with the script, but without having to do the manipulations)?

Since we just did the 4.0 release with huge new features and it took a long time, for 4.1 we will focus on "quality of life" type of improvements. Those are the many smaller features that make using Spine more pleasant.

For frame-by-frame animation, the idea is to have an attachment that has a frame rate setting and will show a number of images sequentially. It is a single attachment that shows multiple images, keys are not necessary.

Nate yazdı

Since we just did the 4.0 release with huge new features and it took a long time, for 4.1 we will focus on "quality of life" type of improvements. Those are the many smaller features that make using Spine more pleasant.

For frame-by-frame animation, the idea is to have an attachment that has a frame rate setting and will show a number of images sequentially. It is a single attachment that shows multiple images, keys are not necessary.

This feature will be absolutely awesome!!

Nate yazdı

Since we just did the 4.0 release with huge new features and it took a long time, for 4.1 we will focus on "quality of life" type of improvements. Those are the many smaller features that make using Spine more pleasant.

For frame-by-frame animation, the idea is to have an attachment that has a frame rate setting and will show a number of images sequentially. It is a single attachment that shows multiple images, keys are not necessary.

Are we likely to see 4.1 released this month? Do you have an estimate on the release date please?

Syneos yazdı

Are we likely to see 4.1 released this month?

FYI, here is the non-beta release history. The minimum interval is about 6 months. At most you could get is a 4.1 beta which include your requested feature implemented but no way for a complete non-beta 4.1 release this month.

4.0 2021 July
3.8 2019 Aug
3.7 2019 Jan
3.6 2017 Jun
3.5 2016 Nov

Aye, non-beta takes a while, as we need to be sure people won't have a catastrophe when they update.

We pushed very hard for 4.0 and the team has been taking summer vacations to recuperate in a rotating fashion, so we always have folks available to help. We'll be back at full capacity soon and will start making progress on 4.1.

Nate yazdı

Aye, non-beta takes a while, as we need to be sure people won't have a catastrophe when they update.

We pushed very hard for 4.0 and the team has been taking summer vacations to recuperate in a rotating fashion, so we always have folks available to help. We'll be back at full capacity soon and will start making progress on 4.1.

Thank you for your answers!
So any chance to see the 4.1 beta release next month for example or is it still too early?

Why is the sequence option placed on the attachment instead of the slot?

Isn't it more straight forward to enable the sequence from a Slot and have the slot auto detect the loop range from the attachments underneath? Or even simpler, when range is not set, just loop everything under the slot when the sequence option is enabled?

As with nearly any new feature, there are many ways it could be done, each with various trade-offs. The way we chose makes it easy to display frame-by-frame animation. Your idea would require creating an attachment for each frame. That gives some additional flexibility, for example allowing each frame to be positioned or to use a different mesh. However, it is more work to set up, needing many individual attachments to be defined in the tree, in exports, and in memory at runtime. More importantly, it would mean you'd need to use a slot for each sequence. With our approach where the attachment is the sequence, you can have multiple sequences as well as non-sequence attachments under the same slot. This fits more closely with how attachments are used and especially how skins work.

Note in the GIF that there is no need for the other right-wingXX attachments. Those are there only because the existing dragon skeleton was modified for the GIF. You only need a single attachment for the sequence.