Python dir(ob) for game types now includes attributes names,
* Use "__dict__" rather then "__methods__" attribute to be Python 3.0 compatible
* Added _getattr_dict() for getting the method and attribute names from a PyObject, rather then building it in the macro.
* Added place holder *::Attribute array, needed for the _getattr_up macro.
* Made GameLogic.addActiveActuator(actu, bool) to raise an error if the actuator is not in the list. Before it would allow any value as the actuator and fail silently (makes debugging scripts more difficult).
* Allow the actuator to be a string which is convenient if you dont want to change the settings of the actuator.
* Added activate/deactivate functions to the controller, this is more logical since the GameLogic.addActiveActuator() function is running through the controller anyway.
GameLogic.addActiveActuator(controller.getActuator("SomeAct"), True)
...can be replaced with...
controller.activate("SomeAct")
Use 'const char *' rather then the C++ 'STR_String' type for the attribute identifier of python attributes.
Each attribute and method access from python was allocating and freeing the string.
A simple test with getting an attribute a loop shows this speeds up attribute lookups a bit over 2x.
The principle is to replace most get/set methods of logic bricks by direct property access.
To make porting of game code easier, the properties have usually the same type and use than
the return values/parameters of the get/set methods.
More details on http://wiki.blender.org/index.php/GameEngineDev/Python_API_Clean_Up
Old methods are still available but will produce deprecation warnings on the console:
"<method> is deprecated, use the <property> property instead"
You can avoid these messages by turning on the "Ignore deprecation warnings" option in Game menu.
PyDoc is updated to include the new properties and display a deprecation warning
for the get/set methods that are being deprecated.
This is an interesting bug since it is likely the cause of many other suspicious python crashes in blender.
sys.last_traceback would store references to PyObjects at the point of the crash.
it would only free these when sys.last_traceback was set again or on exit.
This caused many crashes in the BGE while testing since python would end up freeing invalid game objects -
When running scripts with errors, Blender would crash every 2-5 runs - in my test just now it crashed after 4 trys.
It could also segfault blender, when (for eg) you run a script that has objects referenced. then load a new file and run another script that raises an error.
In this case all the invalid Blender-Object's user counts would be decremented, even though none of the pointers were still valid.
I'm getting this error now:
GPG_Application.cpp: In member function 'void GPG_Application::stopEngine()':
/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/marshal.h:12: error: too many arguments to function 'PyObject* PyMarshal_WriteObjectToString(PyObject*)'
GPG_Application.cpp:720: error: at this point in file
Are we offically not supporint older versions of python now? :)
Kent
Previously, this behaviour was available only for sensors
that were not connected to any active state, which was
forcing the game designer to duplicate sensors in some
cases.
For example the Always sensors used to initialize the
states needed to be duplicated for each state. With this
patch, a single Always sensor with Level option enabled
will suffice to initialize all the states.
A Python controller can determine which sensor did trigger
with the new SCA_ISensor::isTriggered() function.
Notes:
- When a sensor with level option enabled is connected
to multiple controllers, only those of newly activated
states will be triggered. The controllers of already
activated states will receive no trigger, unless the
sensor internal state toggled, in which case all the
controllers are triggered as always.
- The old isPositive() function returns the internal
state of the sensor, positive or negative; the new
isTriggered() function returns 1 only for sensors
that generated an event in the current frame.
buttons_logic.c - NULL checks for game logic buttons, linking in groups with some logic links to objects outsude the group could crash blender. There are NULL checks for this case elsewhere so I assume it should be supported.
CMakeLists.txt - remove YESIAMSTUPID option, is not used anymore.
somewhat random crashes, which I think was caused by the error print
using python objects that were freed too soon. Now it frees the dictionary
after the print.
* 2 returning errors without exception set another return None instead of NULL.
* a missing check for parent relation
* BPY matrix length was incorrect in matrix.c, this change could break some scripts, however when a script expects a list of lists for a matrix, the len() function is incorrect and will give an error. This was the only thing stopping apricot game logic running in trunk.
Also added a function for GameObjects - getAxisVect(vec), multiplies the vector be the objects worldspace rotation matrix. Very useful if you want to know what the forward direction is for an object and dont want to use Blender.Mathutils which is tedious and not available in BlenderPlayer yet.
Cleared the python dictionary at the end of the game engine, should fix some issues,
also reverted the python controller changes, related to this
This should fix the following bugs:
[ #3789 ]
[ #3815 ]
possiblyy fixes:
[ #3834 ]
Armatures are back
Split screen
Double sided lightning
Ambient lighting
Alpha test
Material IPO support (one per object atm)
Blender materials
GLSL shaders - Python access
Up to three texture samplers from the material panel ( 2D & Cube map )
Python access to a second set of uv coordinates
See http://www.elysiun.com/forum/viewtopic.php?t=58057
Reenabled the setScript/getScript methods for python controller bricks.
Set the ray source point to MouseFocusSensor.getRaySource works.
Added: Python -> MT_Quaternion
MT_Matrix4x4, MT_Matrix3x3, MT_Vector3, MT_Point3 -> Python
Correct transform of frustum bound sphere centre point to world coordinates
[SCons] Build with Solid as default when enabling the gameengine in the build process
[SCons] Build solid and qhull from the extern directory and link statically against them
That was about it.
There are a few things that needs double checking:
* Makefiles
* Projectfiles
* All the other systems than Linux and Windows on which the build (with scons) has been successfully tested.
