Understood. I won't touch the built-in icons (they look fine anyway)

That file appears to be corrupted. Try to find the .blend1 backup of the file, which might still be good, and remember to backup your files in the future.

Could be an unrelated bug, but I also seem to be having trouble assigning weights in edit mode. Only for certain objects, though-- I can't get it to reproduce reliably

Of course, if I release Ctrl key and try to paint weight, and as the target is 0, the stroke gets totally blue and this is expected.

In T65408#693418, @Antonio Vazquez (antoniov) wrote:

In you file you have a maximum target weight of 0.0

If you set this value to 0.0, as soon you paint any vertex, the value will be set to 0,0, and this is how is deigned. If you wants to have a maximum value of 0 in the vertex and you manipulate the vertex, the program check your current value and clamp it to the valid range, in this case from 0 to 0, so it's 0.

There are plans to integrate grease pencil inside the "general" Dope Sheet and remove the grease pencil mode.

Note: This regression must have occurred somewhere between the May 10th build (when I first noticed it) and the May 7th build (when it still works as expected). Hope that helps!

Thank you @Bastien Montagne (mont29) . I did discover a workaround which was to wrap the script in a function that is appended to the app handlers. Consider the following script:

Suggestion: Manipulators on Camera and Lamp objects should be accessed by entering Edit Mode for these objects.
For instance, one could select a Spot Lamp and press Tab to enter Edit Mode, which would expose the manipulators for size, angle, and falloff. These would be hidden in object mode so as to avoid clutter. Entering edit mode on a Camera could expose manipulators for viewing angle, shift, focus distance and clipping.

This will probably get archived as not-a-bug, but I agree, and I think this functionality should be reconsidered for 2.8.

That was 8 hours turnaround time. Excellent work, Sergey!

Thank you, aligorith!

The video output and encoding panels are poorly organized and misleading.
Here's the full proposal on how to fix them.

Interesting. Would this difference necessitate the smoothing of all normals in BGE deform?

Good lord, this issue has been up for 2+ years? It seems pretty critical. Who can be bribed to address this? I swear I'll bake them a cake.

Oops! nearly forgot the file:

I vote that the walkthrough feature go ahead and use scene gravity by default. It'd be silly to keep it hard coded, and confusing to make it distinct from existing scene settings.

Teachers and tutorial writers are the main- if not sole- user group that need an addon like this. The purpose of screencasting clicks and key strokes is so that a viewer who is new to Blender can know- at all times- exactly what buttons the instructor is pressing. So, if a limitation of the screencast keys addon presents an issue for tutorial writers, then that is a drawback to the addon as a whole.

Perhaps the input could be de-limited only in actions for which it is appropriate. But for what it's worth, I'd rather be able to break something than have to deal with artificial restraints. That's more like the spirit of Blender, right?

Invalid. Viewport color is not supposed to affect the material's actual rendered color.

Here are the settings you're looking for. You left these untouched!

I don't believe this is valid.

I'd like to add that this seems like a widespread issue in Blender. Often when an object's property is driven by another property of itself, there seems to be a lag of one logic tick, even though the dependency is not cyclic. This bug can be reproduced simply by driving the rotation of an object by its location. The "extra object/data update" hacks do not appear to remedy this.

Interesting! I'd say that this is technically not a bug...

Certain modifiers do work in a stack; the envelope modifier for instance will deform a sine wave function, but a sine wave function can also come after the envelope.

Sounds like Auto Perspective has been enabled by default in 2.70. Not a Bug. Feature!

BTW, my company is producing an online Blender animation class for children. I understand the devs' reluctance to fix minor bugs so close to an official release, but we're launching quite soon so I'm worried that if this bug survives into version 2.70, it will make children cry. Sobbing, they will repeatedly press ctrl+z to no avail, believing that their character's bone is gone and their animation is ruined forever.

Thank you, @Thomas Dinges (dingto). I tried the "=" key but it has no effect.

There is a note on the wiki:

Thanks, @Joshua Leung (aligorith)! I believe you if you say that this issue is more trouble than it is worth to fix.