hotkey to jump a slot between Skeleton & Draw Order?

Nick

Is there no shortcut to jump a slot selection between Skeleton Tree and the Draw Order list? I could not find it in the hotkey setting file. It will be more convenient if I spot a slot with incorrect draw order, I could select it on the screen and press a hot key to jump to the Draw Order list.

I also notice that the scrolling position is lost after pressing ESC key to quit searching in filter mode. I have to double click the "auto scroll to selection" button, the one with corner and a dot in the middle, to get back to the correct position.

One last issue I found is that if a bone has zero scale in x or y or both in Setup Mode, that bone cannot be scaled correctly in Animate mode. It will hold the zero value. If I want it to have zero size by default and only popup by growing. I have to use very small scale like 0.01 instead of 0.

Thanks

Nick

Erika

Hello Nick!

Regarding changing the draw order when you select something in the skeleton, just press one of these combinations:

PLUS          Draw order move up
SHIFT+PLUS    Draw order move up five
MINUS         Draw order move down
SHIFT+MINUS   Draw order move down five

Spine: Cheat Sheet
This is not necessary, but if you want to be sure to only select slots, you can filter the tree on slots, then select on screen the attachment you want to edit, and the slot will be selected instead. This works great when you want to quickly reparent slots (by selecting, then pressing P to reparent them to a bone).

The first time you press ESC after searching, it will clear the search textbox, the second time you press it, it will deselect everything. ESC, SPACEBAR and double clicking in the viewport all perform the action of deselecting. This is especially useful when you want to have a complete view of the dopesheet in an animation.

Indeed it is uncommon to set a bone scale to 0 in setup mode. A better approach is to leave the bones at 1 scale in setup mode but hide the attachment, then during the animation scale the attachment down, then make it appear.

Nick

Hello Erikari

thank you for your quick response.

Erikari wrote
PLUS Draw order move up
SHIFT+PLUS Draw order move up five
MINUS Draw order move down
SHIFT+MINUS Draw order move down five

I know about the + / - key, my projects are very common to have quite a number of slots and I also prefer a more precise control without guessing the current draw order position. A very common situation is that I have a set of slots needed to be changed. For my case, getting to the draw order list to select those slots and drag moving them is more reliable and is actually quicker to be done. If possible, I would love to see spine to provide a shortcut for that.
(off topic: I also noticed that using the +/- key with multiple selections on a long Draw Order list is a quite slow too for every key press.)

Erikari wrote
The first time you press ESC after searching, it will clear the search textbox, the second time you press it, it will deselect everything. ESC, SPACEBAR and double clicking in the viewport all perform the action of deselecting. This is especially useful when you want to have a complete view of the dopesheet in an animation.

Thanks for the explanation but what I am trying to say is when I ESC to quit searching, the scroll position is better to stay on what is current selected instead of getting lost. Right now after clearing a search, the selected item is out of sigh because when returning from filter mode, more items are restored and the selected item is pushed down in the list far below the visible region. I think a better behavior is to auto scroll to the current selection. (same as deactivate and re-activate the "auto scroll to selection" button to regain the correct scrolling)

Indeed it is uncommon to set a bone scale to 0 in setup mode. A better approach is to leave the bones at 1 scale in setup mode but hide the attachment, then during the animation scale the attachment down, then make it appear.

I think of that too. This is another way to work around. I just wonder if this is a bug or software design decision. Isn't things more simple and straight forward if there is no such scaling restriction?

Thank you