which can be defined to call C functions with defined parameters.
* Parameters are RNA properties, with the same types.
* Parameters are stored in a ParameterList, which is like a small
stack with the values. This is then used to call the C function.
* Includes Python integration.
* Only one test function is part of this commit, ID.rename.
* Integration with the editors/ module is not included in this
commit, there's some issues to be worked out for that still.
If the density texture was taken into account with hair parent particles there were cases when there weren't any parents left to interpolate children from. Now a density texture is only taken into account for hair child particles.
When using 'angle' display for camera, the 'lens' ipo didn't update this
button. Implementation still lacks a bit... having both variables in the
camera struct is asking for troubles. Put on the re-think list for 2.5!
- added a module for the BGE - GameTypes, only contains types.
- added KX_PYATTRIBUTE_DUMMY attributes for KX_Light, KX_PolyProxy, KX_VertexProxy, so all types should give correct results from a dir().
- added a script to check for missing methods in the epydocs - bge_api_validate_py.txt
Now it is possible to add more keyframes to the 'active' F-Curve by simply Ctrl-LMB clicking in the graph space.
NOTE: more advanced polling callbacks are needed in the Graph Editor...
Mipmap creation for render crashed, in this case:
- use Curves tool on an Image, which is UV mapped on object
- Save the image to disk, under new name
- Render (F12)
This fix is only for the crash, there's something not well coded
for Curves tool, how it manages float buffers. That's for 2.5.
-Virtual parents were not randomly selected due to optimization in child particle distribution code.
-Wave-kink had a wrong matrix multiplication.
-Amount of virtual parents wasn't scaled properly to the amount of children rendered.
-Calculating virtual parents is now thread safe.
Previously this only worked with the Blender API.
- bpy_internal_import small C file that Blender scripting and the game engine use.
- Tested with blender, blenderplayer, loading files
- Needed to use a hack to override the Main struct since the game engine doesn't set G.main
- when the sandbox is set, only internal scripts can be imported.
- action attribute wasnt checking for NULL (own fault)
- KX_Scene getCamera wasnt checking for NULL
- CListValue had asserts for not yet implimented functionality, this would close blender. Better to print an error if the user manages to run this functions (I managed to by CListValue.count([1,2,3]))
KX_PolygonMaterial and KX_BlenderMaterial - Added a print function (would raise a python error on printing)
* Crashes *
KX_GameObject SetParent - Disallowed setting a parent to its self, caused a recursion crash.
KX_MeshProxy "materials" attribute was segfaulting because of my recent change - I was wrong, you do need to check material types (no idea why since they are both PyObject * at the base)
KX_VisibilityActuator - Wasn't initialized with PyType_Ready() making it crash on access (own fault)
* Crashes because of missing NULL checks *
KX_PolygonMaterial's "gl_texture" attribute wasnt checking for a valid m_tface
KX_GameObject - added checks for GetPhysicsController()
KX_RayCast::RayTest - didnt check for a valid physics_environment
KX_SceneActuator's getCamera python function wasnt checking if there was a camera.
RNA-Paths + Array Indices for Keying Sets, F-Curves, and Drivers are now editable. We could disable these later if need be, it is useful to be able to edit these (especially for debugging purposes now).
- changed epy_docgen.sh so inherited attributes & methods are included inline for each type, removed source option since its not useful and makes the download bigger.
- made camera use PyAttributeDef's
- removed unneeded duplicate matrix type checks
- fixed own bug (added since 2.48a) that broke a converting 4x4 matrix to a PyObject
- I key over a button inserts a keyframe.
- Alt+I removes a keyframe.
- With right mouse button a menu with these options pops up.
- Buttons are colored green if the property is animated, yellow
if it is on a keyframe. I followed the colors from the UI
mockups, but the flicker on keyframes seems too distracting in
practice?
- This only works for properties on the ID itself at the moment,
path callbacks need to be filled in for all structs but mesh
still.
- It doesn't work when you're over a related label, that needs to
be made to work.
- I made it insert keyframes outside of any keyingset. Not sure
how this is supposed to integrate?
Next part of UI drawing migration coding.
Now all calls go via the new wrapper; apart from some special types
(Colorband, HSV picking, Curve, Normal) they draw OK.
Also added new menu system, nicer shadow, and using same AA code.
Used dark theme suggestion from William btw. Don't get afraid, it'll all
be tweakable. :)
Next steps:
- move over all special button types
- make external calls for AA draw (nodes for example)
- remove old draw code
- make new colors save in theme
I also have to check on how to treat icons in buttons; this is a bit
cumbersome in cases.
Then the layout system comes back on agenda, will go over this with
Brecht tomorrow.
So; all WIP, be patient!
- Initialize python types with PyType_Ready, which adds methods to the type dictionary.
- use Pythons get/setattro (uses a python string for the attribute rather then char*). Using basic C strings seems nice but internally python converts them to python strings and discards them for most functions that accept char arrays.
- Method lookups use the PyTypes dictionary (should be faster then Py_FindMethod)
- Renamed __getattr -> py_base_getattro, _getattr -> py_getattro, __repr -> py_base_repr, py_delattro, py_getattro_self etc.
From here is possible to put all the parent classes methods into each python types dictionary to avoid nested lookups (api has 4 levels of lookups in some places), tested this but its not ready yet.
Simple tests for getting a method within a loop show this to be between 0.5 and 3.2x faster then using Py_FindMethod()
Added the method into the PyType so python knows about the methods (its supposed to work this way).
This means in the future the api can use PyType_Ready() to store the methods in the types dictionary.
Python3 removes Py_FindMethod and we should not be using it anyway since its not that efficient.
