Adding a UI to set the type on startup can be added easily.
# ----
class myPlayer(GameTypes.KX_GameObject):
def die(self):
# ... do stuff ...
self.endObject()
# make an instance
player = myPlayer(gameOb) # gameOb is made invalid now.
player.die()
# ----
One limitation (which could also be an advantage), is making the subclass instance will return that subclass everywhere, you cant have 2 different subclasses of the same BGE data at once.
Remove the last of the odd C++/python wrapper code from http://www.python.org/doc/PyCPP.html (~1998)
* Use python subclasses rather then having fake subclassing through get/set attributes calling parent types.
* PyObject getset arrays are created while initializing the types, converted from our own attribute arrays. This way python deals with subclasses and we dont have to define getattro or setattro functions for each type.
* GameObjects and Scenes no longer have attribute access to properties. only dictionary style access - ob['prop']
* remove each class's get/set/dir functions.
* remove isA() methods, can use PyObject_TypeCheck() in C and issubclass() in python.
* remove Parents[] array for each C++ class, was only used for isA() and wasnt correct in quite a few cases.
* remove PyTypeObject that was being passed as the last argument to each class (the parent classes too).
TODO -
* Light and VertexProxy need to be converted to using attributes.
* memory for getset arrays is never freed, not that bad since its will only allocates once.
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r19820:HEAD
Notes:
* Game and sequencer RNA, and sequencer header are now out of date
a bit after changes in trunk.
* I didn't know how to port these bugfixes, most likely they are
not needed anymore.
* Fix "duplicate strip" always increase the user count for ipo.
* IPO pinning on sequencer strips was lost during Undo.
- initialize pythons sys.argv in the blenderplayer
- ignore all arguments after a single " - " in the blenderplayer (like in blender), so args can be passed to the game.
- add a utility function PyOrientationTo() - to take a Py euler, quat or 3x3 matrix and convert into a C++ MT_Matrix3x3.
- add utility function ConvertPythonToMesh to get a RAS_MeshObject from a KX_MeshProxy or a name.
- Added error prefix arguments to ConvertPythonToGameObject, ConvertPythonToMesh and PyOrientationTo so the error messages can include what function they came from.
- deprecated brick.getOwner() for the "owner" attribute.
- comments to PyObjectPlus.h
- remove unused/commented junk.
- renamed PyDestructor to py_base_dealloc for consistency
- all the PyTypeObject's were still using the sizeof() their class, can use sizeof(PyObjectPlus_Proxy) now which is smaller too.
This changes how the BGE classes and Python work together, which hasnt changed since blender went opensource.
The main difference is PyObjectPlus - the base class for most game engine classes, no longer inherit from PyObject, and cannot be cast to a PyObject.
This has the advantage that the BGE does not have to keep 2 reference counts valid for C++ and Python.
Previously C++ classes would never be freed while python held a reference, however this reference could be problematic eg: a GameObject that isnt in a scene anymore should not be used by python, doing so could even crash blender in some cases.
Instead PyObjectPlus has a member "PyObject *m_proxy" which is lazily initialized when python needs it. m_proxy reference counts are managed by python, though it should never be freed while the C++ class exists since it holds a reference to avoid making and freeing it all the time.
When the C++ class is free'd it sets the m_proxy reference to NULL, If python accesses this variable it will raise a RuntimeError, (check the isValid attribute to see if its valid without raising an error).
- This replaces the m_zombie bool and IsZombie() tests added recently.
In python return values that used to be..
return value->AddRef();
Are now
return value->GetProxy();
or...
return value->NewProxy(true); // true means python owns this C++ value which will be deleted when the PyObject is freed
Use each types dictionary to store attributes PyAttributeDef's so it uses pythons hash lookup (which it was already doing for methods) rather then doing a string lookup on the array each time.
This also means attributes can be found in the type without having to do a dir() on the instance.
- 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.
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.
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.
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
* bugfix for BGE python api - SetParent actuator getObject would segfault if the object was not set.
* Added utility function ConvertPythonToGameObject() that can take a GameObject, string or None and set the game object from this since it was being done in a number of places.
* allow setObject(None), since no object is valid for actuators, Python should be able to set this.
* added optional argument for getObject() so it returns the KX_GameObject rather then its name, would prefer this be default but it could break existing games.
Certain actuators hold a pointer to an objects: Property,
SceneCamera, AddObject, Camera, Parent, TractTo. When a
group is duplicated, the actuators that point to objects
within the group will be relinked to point to the
replicated objects and not to the original objects.
This helps to setup self-contained group with a camera
following a character for example.
This feature also works when adding a single object
(and all its children) with the AddObject actuator.
The second part of the patch extends the protection
against object deletion to all the actuators of the above
list (previously, only the TrackTo, AddObject and
Property actuators were protected). In case the target
object of these actuators is deleted, the BGE won't
crash.
Keyboard sensors can now hook escape key. Ctrl-Break can be used from within blender if you've forgotten an end game actuator.
Fixed a stupid bug preventing some actuators working (like TrackTo).
Certain actuators (Add Object/Replace Mesh/Scene/Track To) used to always require a target, or they would not influence the scene. If the actuator target is always set from Python, this could be annoying.
