The pose tool does inverse kinematics. Drag to make a selection box to select multiple bones, or ctrl click them. Then drag any bone or the icon at the end of the chain and you will get IK. This is only for posing the skeleton though, it is not IK applied at runtime.

Being able to pin the feet and then have the editor handle keeping them in the same place would be great, it's just one of a long list of complicated features that we had to cull in order to release a 1.0 version. We're working on runtimes now, but we'll add more neat features in the future.

The pose tool only affects rotation. If you click the translate tool, you are no longer using the pose tool or IK, so it just translates the bones.

I don't understand why you can't use the IK while animating ?
you just have to bake rotation no?
That's really a missing feature atm

If it's the behaviour of the pose tool (

change the pose ) that is problematic; just create another tool and name it IK so it doesn't affect the pose

"just" is the keyword here funshark. IK is not trivial to implement and this is why we haven' done so. If we implement IK for animation, we want to make sure it's implemented right. I have worked a lot with IK animation so I know how powerful it is, but it also requires some important features to be useful.

Which ones?
I don't see any missing feature that stopping you to just using the existing implementation ( yep I'm using just again )

using just the current implementation doesn't work. It's a whole different ballpark. The current implementation only takes care of the math. For proper IK support there are far more things to take into consideration. Any way you approach it, it is not trivial.
With that said, it's something I would like myself, but if we implement it we don't want to make it a quick hack, we want to do it properly.

IK at runtime requires an IK bone chain to be defined in the UI, then an IK algorithm must be applied at runtime. Both of these are tricky, and even trickier to do well with an easy to use workflow. The alternative is not so bad (keying things manually), so we are focusing on the core of the app and runtimes before doing bigger, non-essential features like runtime IK. It isn't that it can't be done, it is a matter of priorities. Remember there is only one developer working on Spine (me ), and a whole lot of work to do. Also, you can implement IK yourself using the runtime API.

Everybody is talking just about IK (wich is absolutely fine to do)
I just want to remind of the seccond topic here: locking objects - because I also would like to lock bones or images from time to time.
By beeing able to lock specific objects you could easily select all the others by dragging-selection in the editor screen. think of overlapping bones.

But maybe a locking feature is already planned... ;-)

Nevetheless spine is really great and fun to work with!

I want to implement selection groups. Make selection, ctrl+1. Now when you press 1 you get that selection. Also for 2,3,4,etc. Works well for RTS games, could work for Spine.

wow, cool. Really interesting idea to use selection groups known from games for a tool. :yes:

About the IK, would it not be possible to implement it within the editor (to animate), but have it export as individual bone data (x, y, scale, rotation)?
I know this will be a later feature if you do implement it, but maybe it could be solely used within the editor at first.

It could be done solely in the editor by playing back the IKed animation and exporting keys every X frames or so. This would generate a lot of keyframes though. I think the real power of IK is its runtime uses, as it isn't all that difficult to pose skeletons in the editor with just the Pose and other transform tools.