1. Woah! Since when did this change to that hideous alphabetical order?!
2. Nice + timely fix!

An update:
So this seems to happen when you move the keyframe past the other keyframes, triggering the keyframe sorting (sort_time_fcurve()) . Disabling that step solves the crash here, but is kindof undesirable in that the curve doesn't get resorted/recalculated.

I'm running into this bug as well with both the Grease Pencil branch (own build) and Buildbot (blender-2.80-f860369-win64.zip).

A small optimisation tip.

Hmm... it's a bit unclear atm what is intended here regarding what modes these will be available in. On one hand, it sounds like you're saying that facemaps will always be available in object mode, but then, in the next paragraph/section, you mention stuff about these activating corresponding bones and allowing tools like keyframing/breakdowner/pose-library/motion paths/etc. to be used as if the bone was selected.

Not a bug.

@Jason schleifer (jasonschleifer) @Luciano Muñoz Sessarego (looch)
You guys might be interested in testing this patch sometime ;)

In its current form, I do not think this patch is fit for inclusion. My main objections are:

1. It's not a good idea to be temporarily changing the context to do things that are not supported in the current context. Yes, it is the hacky way that many many scripts do it, but they do it due to limitations in the PyAPI. We should not however allow such tricks in the core code. If what you want to do isn't supported in the current context, you should delegate the task to be handled later by the correct context at a more convenient time when it is in scope instead (i.e. by sending suitable notifer flags)
2. In terms of the animation tools, it's incorrect to do it this way - What you're doing here is you're creating a temporary context that will use "default" filtering options. These can however be different to what the user actually sees in any animation editors they have open.

There are currently location + rotation keyframes on some of the objects (frames 0 and 33). Try removing all keyframes before fixing the position of all the objects.

One tip is to see if this only happens during particular times of the day. For instance, for years, the SVN/tracker/wiki sites were all slow from about 0200 UTC to 0600 UTC (or some subset of that) as the daily backups were running at those times. Of course, this may not be a factor here - I personally haven't seen it happen with the git server. Then again, I haven't had time to update in a while either ;)

From memory, last time we tried removing it, we ended up putting it back eventually as various studios were using it (including the institute). I'm not sure if anything's changed, but I suspect this is still very much the case. If anything, we should be padding it out to make it even more useful.

At least in the 3D view, there's also the option of just using Image Empties that can be manipulated in these ways. AFAIK, it seems quite similar to the "textured plane" approach you mention, except it's not really "real" geometry that hangs around. That said, I haven't really used these enough to tell if there are some serious downsides to doing this (or whether they're already considered the "better" way of doing this).

Thanks for helping narrow this down to a nice tidy window. It really helped looking for the cause. :)

This is very strange...

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.

This is a known issue that's on my todo list for when I get enough time to have another decent look at the NLA evaluation backend.

Technically, the old driver is still there, and should still work perfectly fine.

Doing this, I noticed that you have to zoom out the view at lot more to see the entire bone (when it is created using cm units). It looks like the bone isn't especially thin; it's more that the thickness doesn't automatically scale to match a 100 BU (i.e. 100 BU = 100 "cm", assuming 1 BU = 1 cm) high bone. In other words, BBone sizes are in absolute units (which are not adjusted to deal with the unit scaling stuff).

I looked into this a few weeks back, but only figured out what was going wrong when I saw one of the forums posts somewhere about this.

REVERT THIS!

The problem here is that your various clips have different framerates (i.e. 30fps for the screencast, 25fps for the camcorder, 30fps for the camera, and 26.57fps for the phone).

Hrm... this is strange indeed...

For example:

import bpy

Have you got 'Only Needed' enabled in the user prefs?

@Steffen Mortensen (stifan): Thanks for identifying the problem! Fixes committed to master now :)

I tested this again just now, and overall I think it should be fine to include :)

Indeed, this tool doesn't take NLA tweakmode into account (as it wasn't expected that people should/would be doing a lot of animating that way). But, with a few tweaks in a few places, it should be relatively easy to fix.

Ah yes, there's that problem.

The purge orphan data operator works by saving and reloading the file. That in turn triggers the current context to be destroyed, and a fresh one to be created.

Perhaps I'm missing something, but since the original problem was that the user was trying to use Flip Names to swap the names of a pair of selected bones, wouldn't it make sense to just swap the names of a pair of matching bones (if both are selected)? All the other cases we could leave as-is for now.

Hey Campbell, thanks for the tips!

Great to see someone tackling this at last! :D

Please include a file so that we can see what's going on.

Ah, I was referring to https://developer.blender.org and not https://developer.blender.org/maniphest/project/2/type/Bug/

IIRC, on last check we weren't doing any of the fancy color management stuff yet. Previously, as a UI tool, this didn't matter so much, but now that GP is being used for art, we'll have to tackle this I think.

I've had a look at what's going on here:

• If you create a task via Maniphest (i.e. via the '+' in the top-right corner -> Create Task) the description box is left empty (since the task could be for anything). That page is simply titled "Create Task"
• If you create the task via the "Report Bug" button on the homepage, you'll instead see a page title "BF Blender Bug Report", complete with instructions on what to include in the bug report, as well as a pre-populated description box with a basic template.

Actually, even just trying to print the mycolor variable (before changing the name) caused a crash in current master.

You mention some crashing issues when trying to render: IIRC, there have been some recent fixes for crashes related to sequencer stuff.

Could you check with latest master (i.e. buildbot builds)? IIRC, sergey committed a fix for this sometime in the past few weeks-month.

Hmm... this looks suspiciously like a bug in the UI code related to the way that it trims off excess zeros off the end of numbers. Some observations:

• Once it has removed the zero, it doesn't remove any more digits/characters in subsequent editing cycles
• If we replace the 0 with a 1 (or add a 1 after it), no truncation occurs.