Is this only for the new depsgraph? Testing with the old depsgraph seems fine here.

maybe related: T51930

Can confirm. With new DEG, bone motion freezes when changing the IK length, and second attempt at moving causes crash.

Seems like this bug has resurfaced, tested on rB2836003f6b

I am going to mark as resolved then, eventually the new depsgraph will replace the current one.

I can reproduce with legacy depsgraph, but seems to be OK with --enable-new-depsgraph

Fixed in T50995, thanks for the report!

Will have a look.

I tried this on both mac and windows and found it to behave the same.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

As I guessed before opening the file (and confirmed afterwards), it looks like you're running into several things here:

1. If you've got cyclic dependencies, expect to see errors if you do not strictly advanced the timeline in forward order, and/or if you ever cancel transforms.
2. The Transition track assumes that the channels you've got keyed on strips A and B both have the same set of channels to blend between.
3. Make sure that if there are some channels which you only key in a "later" occurring strip that you've got that property keyed in some low-down strip that spans the entire timeline. For example, to avoid trouble with controls glitching out (i.e. usually scaling to zero) you'll typically want to ensure that at the bottom of the stack you've got a "Rest Pose" strip that has a keyframe for the "default" value for every property you have/will keyframe anywhere in that NLA stack, and that this strip is set to extend forward and back.

Sculpt mode avoids flushes as much as possible in order to keep best performance and less amount of lack when sculpting.

*Any* of dependency cycle will cause non-deterministic update of your rig. It might or might not work.

This is update issue… Actually, with new depsgrah (--enable-new-depsgraph option from command line), shrinkwrap constraint also updates in Edit mode e.g.

I think all current patches in master are staged for 2.79.
2.78b had a very specific set of fixes that were allowed for a 'b' release. I would suggest using a buildbot version at the moment or be patient for 2.79 which is due in a couple of months.

I checked in the daily build from today, and it does work correctly. Why was this pulled from the official release? Any chance it can be patched back in?

I just checked this in the official 2.78b release on OS X and the bug is back. Did it not get checked into main? We were relying on this fix for a bunch of shots. :(

Switching back to needs triage

Here's a file demonstrating the issue..

Hi Joey,

Thanks for the report.

@Adam W. Parker (adamwparker) please add comments rather than editing original report to answer other comments, otherwise it’s very hard to tell what has been answered or not!

I remember fixing related issue. Since there are multiple ways such a driver is created please attach simple .blend file with your particular driver which fails.