- The armature weakref list was being incref'd twice then decrefed twice (incref and decref were used incorrectly), now only once. My 'fix' broke this.
- In bpy_pydriver_create_dict the 2 refs added from running PyDict_SetItemString twice were undone when clearing the dictionary (added comment)
- changed Py_XDECREF to Py_DECREF int BPY_pyconstraint_update and BPY_pyconstraint_target, Py_XDECREF checs for NULL value which would have crashed blender before it got to Py_XDECREF anyway.
- after every error is reported (PyErr_Print), remove sys.last_traceback and clear the error, I found this fixed certain crashes (usually when starting the game engine or exiting blender), so best do this all the time.
- header_text.c, CcdPhysicsEnvironment.cpp, KX_CameraActuator.cpp - remove some warnings.
* subsurf code had a lot of unused variables, removed these where they are obviously not needed. commented if they could be useful later.
* some variables declorations hide existing variables (many of these left), but fixed some that could cause confusion.
* removed unused vars
* obscure python memory leak with colorband.
* make_sample_tables had a loop running wasnt used.
* if 0'd functions in arithb.c that are not used yet.
* made many functions static
Bug: Draw.Number wasn't properly checking that the initial, min and max values passed to it were numbers. On errors Python would set an error flag that would only be caught later on, masking where the real problem was. Pesky bug...
Reported by André (jaguarandi) on irc, thanks!
PS for bpy devs: PyInt_AsLong returns -1 on error and sets the error flag. With functions like that we need to take special care or not that obvious bugs appear.
a script error with a script that has an interface would not stop the interface from running again immediately, causing an annoying
error message loop.
fixing [#11362] Blender.Draw.Image() method does not clip properly
also return silently on zero zoomlevel rather then raising an error, only raise an error on negative values.
Also scripts will re-run on undo rather then closing.
This is done by saving and loading the name of the script or textblock of the 'Script' datablock, connected to the ScriptSpace. This way when there is a name but the script dosnt run.
Blender runs the script or text block if available.
* initial values I added in radialcontrol.c might need to be reviewed if they cause problems(I used 200, as it seems many tools were setting that)
* #pragma warnings are the only warnings I still get, so that means we have a clean slate again
[#8354] Blender or Python25.dll crash on... quit, reported by David B. (myvain)
The BPy_FreeButtonsList() function is also called after we call Py_Finalize(). Calling PyGILState_Ensure()/Release() there crashes Blender. Added a test to prevent this, but note that function still runs Python API code to free a buttons list. Doesn't seem to give problems, though. Thanks, David.
* Make PyNodes work with threaded renderer. This patch is by Willian. He has worked hard on getting this sorted out - now you should be able to render with PyNodes AND multiple threads.
I was careful in selectively rolling back revisions, but if you've committed changes unrelated to BPY mixed with BPY changes, I might have reverted those too, so please double check.
This commit fixes the Draw module. All buttons/widgets created via the Draw
module in a SpaceScript area are now inserted into a global list attached to
the SpaceScript data. This list is cleared before each draw, when freeing
the space, and when the area is switched to another space.c
This is necessary to prevent Blender's internal UI code from getting invalid
pointers to python data. In addition, it allows storing widget tooltips
inside the python Button objects, which solves that little bit of stupidity.
Note that this reverts the previous weaklist solution. In fact, I had to go
over each previous commit by Campbell after this code originally branched
before the weaklist commit and re-add each commit. So if anything is
missing, just tell me, or feel free to re-add it.
* incorrect args to Draw.Create() would crash blender because it wasnt deallocating the value properly.
* deallocation of an uninitialized button could also try and free uninitialized memory if the type happened to be a STRING.
* removed the unused tooltip pointer from teh Draw.h's Button struct.
Data from Armature.c and logic.c still leaks.
Mostly todo with PyList_Append adding a refcount and the bpython api not decrefing.
Also added some features needed to fix a bug in mesh_clean.py (ob.pinShape and ob.activeShape)
BPyMesh.py - own dumb error, was using dir as an arg (which is a py keyword)
object_drop.py - new script, the first to use UIBlock, it drops objects into terrain, either a group or the active object. on teh Z axis or view axis.
Bone.c - return an empty list rather then None for bone.children bone.getAllChildren()
Draw.c - per button callbacks are now have (event, value) passed
curve - added curve_type() to return the curve type
BPyModule & gen_library - works with text3d now, can also make new text3d through bpy.curves.new
Added Draw.Label() so scripts can draw can using freetype.
widgetwizard - use Draw.Label
Please read:
http://www.blender3d.org/cms/Imaging.834.0.html
Or in short:
- adding MultiLayer Image support
- recoded entire Image API
- better integration of movie/sequence Images
Was a whole load of work... went down for a week to do this. So, will need
a lot of testing! Will be in irc all evening.
Bug #4484:
http://projects.blender.org/tracker/?func=detail&aid=4484&group_id=9&atid=125
A recent update to Draw.c made the button attr setter function not exit
where it should for one of the cases, when new and old strings had
same length (code was missing a "return 0;" line in one of the if
cases). Should work fine now, I don't get the error under linux anymore.
Also saw in the same function that a py object could be created but
was not being decref'ed in two other 'if' cases.
Thanks elbarto for reporting the bug.
Window.py added note about the view offset being flipped.
editview.c Fly mode timed redraws so motion is the same speed erespective of scene complexity.
