edit mode
My earlier fix for [#33974] (in r.54061) was causing some problems where
manually specified roll values on horizontal or angled bones were getting reset.
This could be nasty as you might not notice the changes for a while (especially
when using stick bones without axes displayed).
I've now put in place a hacky compromise solution which should catch both of
these situations nicely. For z-axis (i.e. vertical) movements, the r.54061 fix
is used, while for everything else (moving or just touch-n-go), the old setting
is used.
finally last transform tool relying on alt has an alternative.
Sequencer slide which makes room for the placed strip by moving others - Pressing G a second time toggles this behavior.
ShrinkFatten operator now uses scale key to toggle 'Even thickness' option.
With the default keymap this is Alt+S,S.
Added functionality so the header print can get the key used for the modal keymap, some other operators should make use of this too.
Limit Constraints (i.e. Limit Location/Rotation/Scale/Distance) with 'For
Transform' option enabled would still be applied when transforming objects even
when they were turned off using the eye icon in the constraint panel headers.
The "off" flag was never added to the checks for muted or disabled constraints
to be skipped here.
For example, if you're making a chain of bones (e.g. for a spine) by extruding
the tip joint of an initial bone, the bone rolls would be: 0 (for the initial
bone), 180, -180, 180, -180, etc. This has the undesirable effect of causing
B-Bones to twist to match the roll values at the other end of the bone.
The fix here seems to improve the situation in this case: bone roll values don't
flip or change anymore (in fact, the bone axes stay perfectly aligned now, as
they should). It also doesn't seem to cause any problems in other common cases I
checked.
This allows moving rigid bodies on frame > startframe.
Also rigid bodies can now be picked up and trown around while the
simulation is running.
Note: There is a small glitch with cancelling tansform during simulation
but it's tricky to get rid of.
TODO: Avoid static-static collision warnings
using numeric input
When using numeric input to move strips, the strip extent clamping code could
end up prematurely truncating one endpoint. This was because the clamping code
uses the values of the other end (e.g. end for start, and start for end) as one
of the limits on its allowable range to prevent inverted strips.
Now we just set these values twice - the first time, one of the endpoints may
still get truncated (while the other one will be able to go to its correct
value), then the second time both will get set correctly (and validated too).
