It sounds like you are experiencing issues with copying and pasting animations in Spine, where some actions become invalid after extending the animation. This can happen if the keys for certain actions are not properly copied or if there are missing keys in the extended part of the animation.

Here are a few steps you can try to resolve this issue:

1. Ensure All Keys are Copied: Make sure that all the necessary keys for the actions are copied. Sometimes, keys for certain bones or slots might be missing, which can cause the actions to become invalid. You can manually add keys at the frame you want to copy from if they are missing.

2. Check Key Interpolation: Verify that the interpolation between keys is correct. Sometimes, the interpolation might not be copied correctly, leading to unexpected behavior in the extended animation.

3. Use Box Selection: When copying keys, use box selection to ensure you are selecting all the relevant keys for the actions. This can help in copying all the necessary data.

4. Duplicate Animation Clips: As a workaround, you can try duplicating the entire animation clip and then adjusting the timing to extend the animation. This can help in maintaining the integrity of the actions.

5. Check for Animation Cleanup: Ensure that the "Animation cleanup" option is not enabled in the Export Settings, as it can remove keys identical to the setup pose, which might be causing the actions to become invalid.

For more detailed steps, you can refer to the following resources:

• Keys - Spine User Guide: Key shown
• Dopesheet view - Spine User Guide: Box selection

If the problem persists, you might need to manually adjust the keys in the extended part of the animation to ensure all actions are correctly represented.

herolulu Sorry, I am using Google Translate to communicate with you.

No need to apologize. Please note that you can also save the effort and write your posting in your native language. The forum provides a translation button at the bottom of each posting left of the Reply button:

--

herolulu it could be that even if you copied all keys from one animation, when pasting it into another the movement is still incorrect. This could be caused by keys absent in your first animation but present in the next one. To ensure that what you paste looks exactly the same in the target animation there are a couple of ways:

A brutal one that creates many extra keys consists in selecting all the bones then pressing CTRL+L (CMD on mac) to key all of their transforms. You would then need to clean up the animations to remove the unnecessary keys.

A second method that only adds the keys necessary in the second animation consists in copying all of the frames from the first animation, then in the second animation pushing the already present keys forward so that there's enough room at the beginning to accomodate all of the first animation keys.
Paste the first animation keys, then press the spacebar to deselect and make the whole dopesheet visible,
now you can create the missing keys by pressing CTRL+SHIFT+L (CMD on mac).
With all the necessary keys in place, you can select the frames that belong to the first animation, cut them, (you can also undo after copying) then paste them at the desired point of the animation once its original timingis restored.

http://esotericsoftware.com/spine-cheat-sheet

herolulu Okay, so see the videos below. The copy-and-paste should have been done in the following way (To make the problem easier to understand, I reproduced the problem with an animation leaving only the path position animation.):

To fix this, delete the middle key and double the value of the last key to the original value:

The reason for doubling the value of the last key is that if the original value is left unchanged, it would take twice as long to reach the specified path position. (This is the state shown at 0:02-0:06 in the video above.) To make it move at the same speed, we need to double the value.

For a closed path, changing the path position from 0 to 100 means that the constrained bones will move along the path. So if we think in terms of the constrained bones' coordinates, their coordinates at path position 0 and at path position 100 will be the same. However, the value that the path position keys have is different, and this is what we need to be aware of when copying and pasting the key.

Next, let's look at how to set the path position to 100 at frame 59.99 and back to 0 at frame 60. To set the key at frame 59.99, either hold the SHIFT key and move the timeline bar to set the key there, or use the Current field of the Dopesheet view to move the timeline bar to frame 59.99. In the following video, I used the former approach. I then selected the key at frame 59.99 and switched the curve to stepped.:

If you copy and paste this animation to repeat it, there is no need to modify the path position values after pasting:

For your information, a frame like 59.99 is called a fractional frame. This is explained on the Keys page of the User Guide: https://zh.esotericsoftware.com/spine-keys#%E5%B8%A7%E5%AF%B9%E9%BD%90

herolulu I am glad the videos were helpful!

As for how to invert the entire animation, this can be accomplished by performing a box selection of keys in the dopesheet view and scaling them. Scaling can be used to reverse the order of the keys by moving the left edge past the right, or the right edge past the left. See the User Guide for instructions on how to make box selections:
https://zh.esotericsoftware.com/spine-dopesheet#%E6%A1%86%E9%80%89

Incidentally, if the animation is to be played using the Spine runtime, you can specify reverse playback via the code for playing the animation. See the API reference if you are interested:
https://esotericsoftware.com/spine-api-reference#TrackEntry-reverse

herolulu Oh, when doing box selection and inverting, be aware of the fact that if you have not held down the Shift key, the keys on the fractional frames will be placed on the integer frames, and the key may disappear if the near integer frames have keys. On the other hand, if you do it with the Shift key pressed, the operation is a little more difficult because the frame you want to place on the integer frame is not properly aligned with the integer frame. A feature that would make it easier to invert the animation might be something we could consider. I will think about how best to add this.

herolulu Hmm, I checked the Spine project, but I can offset the zuoxiaobi bone's timeline and the mesh shapes seen in the viewport seem to match at frame 0 and at the last frame, so I'm not sure what the problem is. If you have sorted out the constraints so that it works, could you please show me the project where the problem occurs?

By the way, if you send us a Spine project that is too complicated, it tends to be unclear where to look, so it would be helpful if you could send us a project with only the parts that cause problems and remove the rest.

herolulu Thanks for submitting the simplified Spine project! It seems that the rotation keys for bone84, bone85 and bone86 do not match in frame 0 and the last frame:

Did you filter the rotation timeline? When you filter the timeline of a particular transformation in the Dopesheet or Graph view, you may think you have selected all the keys, but you have not. If you can think of any reason for this confusion, please let us know for our reference.

herolulu Hmm, that's weird. As far as I have tested, I have been able to match the rotation values of the first and last keys by copying and pasting the keys:

So I am not sure what the actual cause of the problem is. However, I noticed that while the offset button is enabled, even if you select the white key in the overview row, you cannot select the keys in all the timelines of the same frame, so I thought that might be the reason why you thought you had selected all the keys, but actually hadn't:

In the video above, you can see that when the offset button is disabled, selecting the white key in the overview row selects keys in all rows, but when it is enabled, only the key of the top bone is selected. This has always been the case, so it's not a bug, it's design, but I thought it might cause confusion when trying to copy keys.

Could you please try again to see if you can copy and paste the keys correctly?