R 27991 broke all script-based Keying Set support, including all the Built-In Keying Sets. This meant that it nearly impossible to still keyframe anything (there are other less convenient ways, but none work quite as well).
* Fixed all the dangerous code added in 27907. Using the code there, scripters could corrupt animation files in ways which would render them useless, with channels not appearing in any animation editors, and others not getting evaluated at all.
* Partial fix of bug 21818, by disabling destructive replacement of keyframes. Will followup this commit with a more comprehensive commit which gets rid of the rest of the problems, by incorporating some requests from Durian team.
* Fixed problems with users being able to see+edit the name of the active Keying Set in the Scene buttons. There is still a bug though with the list widget given how the indices are now interpreted...
* Added 'id_name' property, which is used as the "typeinfo_name" by Keying Set instances. This is simply the name of the relevant KeyingSetInfo classes.
* Renamed the 'array_index' arg for ks.add_path() to 'index'. Also removed the 'entire array' toggle arg in favour of just passing -1 to index. However, Keying Sets in general still maintain their 'entire array' toggle flags for now, it's just that the API function does conversion between the two.
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
