when using the Numpad0 feature to reset properties to their default
values.
While this implementation here is not a full/proper implementation, as
you cannot truly specify a default value for some pointers that may
require something other than NULL (i.e. nothing), this should be good
enough for the vast majority of (editable) cases which are fine if set
to NULL.
This is most noticeable with the Active Keying Set field in the
TimeLine header, where it's now possible to simply use Numpad0 to
clear it instead of using a confusing click+backspace+enter dance to
do the same thing.
Crash in Bezier animation (inserting keys on control points in
curve object). The animation rna paths were not fixed after an
editmode session, which got fixed 2 weeks ago, but for all older
binaries the issue can still pop up.
The crash happened because the RNA array-itterator was not doing
a boundary check, even whilst the array size was passed on to the
itterator callbacks. With rna then writing far outside of valid
memory, very bad and unpredictable corruptions happen.
I've added a range check now, and a decent print to denote the
issue. An assert quit is useless, since a tab-tab on curve objects
will fix the channels nicely.
Example of warning print:
Array itterator out of range: Spline_bezier_points_lookup_int (index 30 range 2)
Makes adding new flags give ambiguous results and also makes it less easy to tell whats intended.
In some places it looks like OB_RECALC_TIME should be left out too.
eg, "matrix[3][2]" could be used as a driver.
Test from python
bpy.context.object.path_resolve("matrix_world[2][3]")
Before this was always treated as a 1 dimensional array.
only tags the ID and does the actual flush/update delayed, before the next
redraw. For objects the update was already delayed, just flushing wasn't
yet.
This should help performance in python and animation editors, by making
calls to RNA property update quicker. Still need to add calls in a few
places where this was previously avoided due to bad performance.
this report raised a number of problems with rna paths, while we still dont have multi-dimensional array access, invalid paths were being accepted which confused things.
rna path resolving code was accepting all sorts of invalid input because atoi() just returns 0 for non numeric input.
now check if 0 number == '0' character.
added r31826.
This is valid python syntax but I rather be strict with data path format else it becomes harder to parse them if we try to support this.
it means checks like fcurve.data_path.startswith('pose.bones["SomeBone"]') isn't ensured to work, since blender uses "" quotes everywhere for keyframe paths I dont think its an advantage to allow users to do it differently.
Simple python benchmark shows this to be about 3x faster in the case where an update isn't needed.
This also speeds up rna function argument parsing, since each arg in a function call did 2 string lookups on the context which were never needed.
By Lukas Tönne
In the console RNA paths can use double quotes (" ") or single quotes (' ') to select from a collection, an
ID property or a vector/color component. The RNA_path_resolve function however only accepts double quotes. This patch
adds the ability to use single quotes in areas other than the console too.
PS. Note the very nice patch ID :)
patch [#23317] Changed some operators' RNA to accept lengths
by Lorenzo Tozzi (oni_niubbo)
with the minor change to use XYZ subtype rather then LENGTH.
An example of how this is useful - an importer mixin could define the filepath properties and a generic invoke function which can run the subclasses exec for each selected file.
- Panels and Menus now skip the property check when registering.
- renamed _idproperties_ to _idprops_ in function names, function names were getting very long.
- raise an exception when python calls is_property_set(name) or is_property_hidden(name) and the property does not exist.
- added BLI_findstring_ptr(), which finds a named item in a listbase where that name is a pointer to a string.
- replaced inline for loops with calls to BLI_findstring_ptr() and IDP_GetPropertyFromGroup().
Modifiers were being mistakenly recalculated at every frame as long as the object had animation, slowing things down due to incorrect depsgraph recalc tags.
Renamed OB_RECALC -> OB_RECALC_ALL to reduce future confusion. During this process, I noticed a few dubious usages of OB_RECALC, so it's best to use this commit as a guide of places to check on. Apart from the place responsible for this bug, I haven't changed any OB_RECALC -> OB_RECALC_OB/DATA in case that introduces more unforseen bugs now, making it more difficult to track the problems later (rename + value change can be confusing to identify the genuine typos).
Throwing an exception if the strings too long means scripts need to be aware of string lengths and changing a string length in RNA can too easily break scripts.
Instead honor the string length in RNA_property_string_set()
