Hi Emi,

Thank you for following my video!
If you are encountering problems with the repositioning of a constraint, you could add a second constraint that follows the first target, but reposition it, or also set the mix for translation to something that is over 100.

Please find a project attached that shows a modified chibi stickers to add a huge "tall-spineboy" skin.
I tried to test the problems you were having, and I could solve them by doing two things:

• checking that the order of the constraints is correct.
• tweaking the influence of the repositioning in the animation.

Now let's go in detail about what I did.

SETUP
I repositioned the hips and limbs to make a tall boi as in this blog post:
http://esotericsoftware.com/blog/skin-constraints-for-different-proportions

• Then I stole Luke's sword and shield to add them generically outside the rig, as I assumed this might be your setup.

• I set two IKs on the arms on standard Spineboy to it.

• Then I had to reposition the shield and sword for the tall version with two more transform constraints. (just like the hips bone is repositioned)
  
  Note: The constraints weren't working nicely at this point, so I had to move the positioning of the sword and shield for tall spineboy on top of other constraints. This did the trick.
  
  

• I restored the setup pose to hide the sword and shield, and set the mix of the IKs on the hands to 0 in setup as well

• In animate mode I first made two animations using chibi Spineboy idling and attacking

• I switched to the tall version which had some ugliness that needed fixing, this is easy to do by animating the mix! first a simple example on the emojis:
  Dead tiny Spineboy:
  
  Dead tall Spineboy with standard mix floats:
  
  Translation mix set to 0 on the hips constraints so it causes no issues: (I also reduced the scale of the limbs mix a bit)
  

Now let's see the trickier sword animations, on Spineboy normal chibi:

But here's how they look on the tall version with no tweaks:

Note you can key a constraint to go over 100 as to make a movement wider:

Let's also say in that ugly idle animation I made, I feel it's super important that the legs bend for reasons, I can also lower the mix to make that happen at specific keys, so the result of these is:


But let's say you want the sword to hit exactly in the same spot, you can do that too simply by setting the mixes a bit differently!

Here's the downloadable project, I hope this helps!
https://www.erikari.it/uploads/1337-tall-spineboy-attacks.zip

As an alternative if you're having difficulties with this method, I would recommend separating the skeletons, but naming the bones exactly the same, them importing the animations from one skeleton to another, and tweaking them there, as shown in this tip:
http://esotericsoftware.com/spine-tips#import-animation

Image removed due to the lack of support for HTTPS. | Show Anyway

Emi
Each approach has its ups and downs, so if you choose to separate the skeletons, you will have to reimport the same animations across all skeletons and apply the tweaks. This can be an advantage if you plan to have not many animations but lots of customization in your files. Vice-versa, if you won't have too many characters, but lots of animation, the effort in using a single skeleton is worth it.

Considering what you're doing is pixel art, that usually has fixed angles in its pure form (0, 90, 180, 270 of rotation, translating items only at full pixels or half) there can definitely be advantages in importing animations expecting less tweaks.
If you're using a hybrid approach (the base art is pixel art, but you don't care about keeping pixels at an angle, or will later apply a pixel art filter) then it means that you will be able to animate freely, but given the odd angles you may get, the matching may not be as precise and therefore reliable.

Emi My understanding is that if I animate the bones, the animations would look the same for characters that are physically different. I could just change the length of each bones to match new characters’ body parts.

While it's true that if you reimport an animation, it will add the same amount of translation/rotation/etc. to a child bone, but keep in mind this is relative to its setup pose.
Ultimately, the length of a bone does not matter for animating purposes, only for IK and path constraints as it's used by these to calculate the bones' postions.
So you could also not change the length of a bone, it's more important to change its position technically and broadly speeking.

Emi While if my animations are solely based on keying in IK’s positions, I will then need to re-adjust each animation’s IK’s positions for different characters.

It depends, sometimes all that's needed is to reposition an IK target in setup and that's it. Sometimes the target needs more tweaks.
I think the amount of work for IKs would likely be similar both in a single skeleton or multiple skeletons situation.

As for bones themselves, you'll need to tweak their animations in both cases as well, the real question is:
is it going to be more time consuming to add new skins or to add new animations in the long run? and that should tell you which approach to pick.
If you have to constantly add new animations, don't separate the skeletons, if instead you have to add tons of little hats, different body shapes etc. do separate them if you like your sanity.

Emi Erika answered your question about whether you should animate bones or IKs, so let me skip it. I'm glad to hear that the information about what can be done with the Spine runtime was helpful!

If it is the case that you do not need to use mesh deformation and just want to attach an image to a bone, e.g. a sword or a gun or something rigid, it may be worth considering making the image follow the bone at runtime. If you use the spine-unity or spine-godot runtime, it is also possible to refer to the draw order of a specific slot. This means you can insert an image to the draw order of a skeleton at runtime. However, there are differences in what each runtime can and cannot do, so it may not be possible depending on which runtime your project actually uses.

If you have any more questions, feel free to ask in this forum.

Emi Hmmm, as far as I have tested on my end now, it can be successfully applied to AnimationReferenceAssets created from different SkeletonDataAssets, as long as the setup is exactly the same. But it is possible that I am not understanding it correctly, I will ask Harald to check this thread.

Emi

May I please double check one thing: with your 2 skeletons (A and B), if you have 5 animations in A and 0 animation in B, all 5 animations from A can be applied to B and make B move?

Yes, like in the following video, it works on my end:

Spineboy-A has multiple animations and Spineboy-B has no animations at all. When Spineboy-B references the AnimationReferenceAssets generated by Spineboy-A and plays the animations, it works as expected.

Anyway, I have asked Harald to check this thread, please wait for his answer for more details.

Emi may I please clarify that you meant we need to import all the animations to each skeleton that we use? Then export each skeleton to our unity developer.

Yes, I meant to ensure that each skeleton export contains all animations.

Emi If so, why do we still need to use AnimationReferenceAsset in unity since all the skeletons will have all the animations?

AnimationReferenceAsset serves to allow selecting an animation by assigning a Unity asset to Inspector properties, instead of writing code to query an animation by name and cache the resulting Spine.Animation object for multiple use. The AnimationReferenceAsset does nothing more really, it does not serve as stand-alone animation data or the like.

Can't we just play them from skeleton?

You always play an animation of a skeleton.

Is it correct that the most reliable way for doing my project is for me to import all animations into the 3 skeletons/spine files and export for development team, then they need to update 3 skeleton files to ensure animations are in.

Yes. If you have an enormous amount of animations, your developers could automate the Unity setup process via Unity editor scripts.

Will this work for later spine version as well?

I'm not sure I understand this question correctly. In general, Spine and the spine-unity runtime will always allow you to play the animations of an exported skeleton which have been exported along with it, yes.

@Emi glad to hear it's been helpful, thanks for getting back to us!