Using 32nd bit of integer with our int RNA prop is not a good idea, it does not
really support unsigned int even with PROP_UNSIGNED type...
Most likely this has been unveiled by recent work over property clamping in RNA.
Not critical, but should be backported should we make an 'a' release.
When all the names in Blender were updated to go from having 32 characters to 64,
the "pchan_name" field in the DriverTarget struct was missed. This meant that if you
had a bone with a suitably long name, it would have been impossible to use values from this
bone in a driver.
The only reason this probably hasn't been discovered yet is because the standard/old depsgraph
doesn't work that well for bones in the same armatures, so setups where this may have
occurred are not that common.
To prevent this problem from happening in future, I've added the standard "MAX_ID_NAME-2"
comment to the comments on each line likely to be impacted by such changes, making it
easier for whoever does a search and replace in future :)
While this isn't essential, accessing this setting required navigating to each scene and using render menu.
Expose in sequencer UI for more convenient access.
Something weird, seems some buffers _might_ be shared between codec context
and frame, which is quite weird. Could be a bug in FFmpeg or could be wrong
API usage somewhere else..
Was possible to do Alt-RMB on a strips handle - which only make the strip active (but didn't select).
This isn't really useful, so just select the strip and its handles in this case.
In fact, some areas in FFmpeg might require alignment up to 32, so now we
make temporary conversion in an aligned frame. We only do this if width is
not aligned to 32.
As suggested by Sergey, do not register those anymore, this way we keep undo step,
but user cannot 'redo' them (does not work, since cached DM in particle modifier data
is not yet re-created by depsgraph update after undo when operator is redone).
UI now has two buttons, one to (dic)connect current psys, the other to (dis)connect all.
Also fixed similar issue with Connect Hair op.
This has several benefits:
* User count remains coherent, regardless of the order in which you use 'user_one' & real refcounting users
(i.e. if you add to group, and then link in scene, or the reverse, you now always get same final user count).
* Avoids the need to check for potential 'user_one' extra user in count in several places in code (e.g. when
making IDs single users...).
* Users won't wonder why they cannot make 'single user' and ID even though its user count shows '2'!
* readfile.c now always uses code from BKE's library.c when modifying id->us. Which means we can consider
(asside from assignment during initialization) that id->us is read-only outside of library.c context.
Note that this commit reverts previous one (rB6b1d77a8052b) - please **do not** backport this one in 2.77.
Similar cause as in T47482, we used to have poor handling of 'user_one' cases of ID usage,
leading to inconsistent behavior depending on order of operations e.g.
Here, was object used by a group but not linked in any scene - once linked in scene,
their usercount would be 2, leading to 'making single copy', when it's actually not needed.
We now have better control here, so let's use it!
Note that other ID 'make single user' code will likely need similar fix (Images, etc.).
Safe to be backported to 2.77.
Problem was, during initialization of boids particles in `dynamics_step()`,
psys of target objects was not obtained with generic `psys_get_target_system()`
as later in code, which could lead to some uninitialized `psys->tree` usage...
Think it's safe enough for 2.77, though not a regression.
* Don't show name of keyframe type in timeline header. It's getting a bit too crowded
for that, so just show the keyframe icon. Hopefully that will be enough.
* Tweaked the tooltip and label to make it clearer what the setting is for
The new "default keyframe type" dropdown on the timeline header
(and also the "Keyframe Type" operator/properties in other places)
now has procedurally generated icons which reflect what that keyframe
type will look like when rendered in the Dope Sheet.
This was achieved using the ancient "VICON" (vector icon) stuff
that's lurking around in the dark parts of UI code. From memory,
the only other things that use (or used to use) this stuff included
some of the triangle icons for some dropdown buttons, or something
like that.
Notes:
* Theme colour changes are reflected immediately by these icons.
This is possible because they are all drawn procedurally
* These icons scale with the DPI setting. I manually guessed the size of
these icons. They can be adjusted further if needed.
* I've documented the steps for adding voodoo icons like this on the wiki
(http://wiki.blender.org/index.php/Dev:2.7/Source/Checklists/Vector_Icon)
* It's true that the rendering of these keyframes doesn't quite fit the rest
of the icons in the UI. However, since we're just leveraging the standard
keyframe drawing methods (to avoid discreptancies between the two), we'll
leave it as such for now. Maybe later we can consider blending in a bit of
the glossy keyframe icons in the Icon Sheet?
To make it easier for animators working in a multipass pose-to-pose workflow
when inserting breakdown keyframes and so forth, it is now possible to specify
the "type" of keyframe being created (i.e. the colour of the keyframe, when drawn
in the Dope Sheet).
Usage:
1) Choose the type of keyframe ("Keyframe", "Breakdown", "Extreme", etc.) from
the new dropdown located between the AutoKeying and KeyingSet widgets on the
timeline header.
2) Insert keyframes
3) Rejoyce that your newly created keyframes have now been coloured for you already
in the DopeSheet.
Todo:
* Look into a way of using the actual keyframe colours (from the theme) for the icons
of these types.
