this means use of deprecated struct members gives a warning.
- makesdna.c preprocessor skips this.
- DNA_DEPRECATED_ALLOW is used so readfile.c can do versioning without warnings.
- this exposes some use of deprecated struct members, will deal with this after.
Causing a flurry of refresh file prompts post-commit,
Confusing local diffs and causing merge conflicts,
Stating the obvious; redundant and useless...
We shall not miss thou, blasted expand $keywords$
handle/key
This used to be a weird per-curve setting which would happen to get
applied/work correctly if handles were set to "auto", and was a source
of constant confusion for both old and new animators. The main effect
of this handle-type/option was really to just ensure that auto-handles
stayed horizontal, instead of tilting as the keys were moved.
This commit simply changes this from a per-curve to per
keyframe/handle setting.
Actions now get tagged with an ID-code, which is used to determine
what ID-blocks they can be assigned to. This ensures that material
actions cannot be assigned to the object-level for example.
* Action lists in general will now show only the actions that can be
set for that particular slot. This prevents selection of invalid
actions, and helps cut down the list of actions.
** An exception here is the Add Action Clip in NLA Editor, which will
show all actions but will only add where appropriate. This is because
it's not easy/possible to tell in advance which blocktypes to filter
for when building this list. (TODO?)
* The "Action Editor" is now strictly for object-level action
editing+setting now. This avoids repeateded confusion by people who
try using this to view their shapekey actions, which should go to the
Shape Key Editor instead!
** A context switcher for the legitimate times where this capability
might come in handy is still being investigated.
* "Floating" actions (i.e. actions in some action_library.blend) are
NOT able to be automatically tagged until they are assigned to some
datablocks (i.e. loaded onto the rig + played back once). It is
possible to write scripts that check for certain RNA-paths and "guess"
what datablocks they work on, but it is recommended that you load up
the Datablocks Viewer, and go through such actions by hand, setting
the "ID Root Type" property as appropriate per action.
Recent renaming of Key.keys to Key.key_blocks broke converter for old
files.
Campbell Alert: However, more seriously, it has broken many current
rigs, especially those with heavy usage of (driven) Shape Keys
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
- Tidying up some inconsistent formatting
- Names of old IPO blocks are now included in the names used for new
actions. These are included after a "CDA:" prefix, (i.e. "_C_onverted
_D_ata _A_ction:"), which makes it easier to browse through these
actions later.
-> 2.50
Actionified ShapeKey IPO-blocks (i.e. "Shape Key Actions") would have
an action channel with the hardcoded name, "Shape", and this action
would be assigned to Object level (although ShapeKey blocks had their
own IPO-block slot, only Objects could have actions, so actionifying
ShapeKey IPO-blocks would wrap a ShapeKey block's IPO's to an Object-
level action).
Hence, the path conversions code would wrongly interpret this action
channel as referring to a Pose Channel instead, thus creating some
invalid paths with a 'pose.bones["Shape"]' prefix wrongly getting
tacked on. To ensure that the converted animation can work out of the
box, a 'data.shape_keys' prefix is now used instead so that these
actions can still be Object-rooted while still being able to correctly
control the Shape Keys. This is because there's no easy way to
identify and then shift such action from Object-level to ShapeKey-
level within the conversion code. The consequence though is that such
converted ShapeKey actions CAN ONLY BE USED THROUGH OBJECT LEVEL (i.e.
via Action NOT ShapeKey editor).
Secondly, the Action/ShapeKey editor version patching code has been
modified so that if a ShapeKey editor view was active when loading an
old 2.4x file, the action gets cleared from the view. This is because
of this didn't make semantic sense: the ShapeKey editor is for
ShapeKey-rooted actions, while the Action Editor is for Object-rooted
actions. The converted files though let Object-level actions be shown
in either one.
Found and fixed a few problems here, but strangely I don't recall seeing any of these a few months ago when this conversion (probably last) worked well ...
- use sizeof() in more places.
- fixed some off by 1 bugs copying strings. setting curve font family for instance was 1 char too short.
- replace strncpy and strcpy with BLI_strncpy
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
Now object layers and scene-base layers are now always synced. In 2.4x, they were only synced if there was animation for layers, but it's probably not worth checking for this these days...
Finally we can close this bug report :)
- IPO-blocks for curves were not getting handled correctly (i.e. no conversion and relinking was taking place) when converting from 2.4x to 2.5
- Old 'speed' IPO's now have their values multiplied by the path length when they are loaded from old 2.4x files so that they work correctly in 2.5.
Also...
- Cleaned up a few instances of scruffy code formatted in some weird ad-hoc way.
- Debug prints for the start/end of the file conversion process are now all hidden behind debug-only checks. Unless the way the conversions are done is significantly changed at some point, this should be sufficient...
Animation conversion needed to make transform channel driver vars (for bones) to be in local space, since that's what the old code did (albeit in a slightly more roundabout way).
