[Bf-committers] A patch to add an addObject() method to KX_Scene
ideasman42 at gmail.com
Mon Feb 23 15:17:59 CET 2009
On Sun, Feb 22, 2009 at 5:40 AM, Benoit Bolsee <benoit.bolsee at online.be> wrote:
>> +1 since its really useful.
>> Though I wonder if this is a good direction to head - where
>> python replicates actuator functionality for convenience. -
>> Benoit? - what do you think?
> I have no problem with Python function replicating actuator
> functionality for convenience. In fact many game designers would like to
> be able to develop a full game without logic bricks. I had a plan some
> time ago to make that possible by providing a framework to augment the
> KX_GameObject class with python methods and give access to actuator and
> sensor functions through an API.
> That's a big project but giving convenience functions to access actuator
> functions is a step in that direction.
> To come back on the BGE API change, we don't intend to break any of the
> old functions, we are just adding new attributes to replace the get/set
> method and create new methods when it is missing. Regarding the methods
> that operate oddly, we will fix them by adding new methods or new
> attributes, whichever makes more sense.
> We plan to remove the old methods for 2.50 but actually I like the idea
> of keeping them much longer and making them accessible through a
> GameLogic.compatibility=248 attribute. Keeping the old method in the
> code is just making the blender executable a bit bigger. They won't be
> difficult to maintain, at least until we rework the BGE internals so
> much that we have to redesign the API entirely anyway - but there is
> nothing like that in preparation for the moment.
Hey Benoit, justed looked at making the "OB" prefix optional (with some others)
On second thought this can't be done at runtime with
"GameLogic.compatibility=248" since this needs to set before the data
If the prefix is removed internally but added and removed for the
python api it will work in most cases, except where the user renames
their objects while the BGE runs.
As for keeping deprecated functions, both ways have pros/cons but I'd
We didn't remove deprecated API's/functions for BPY and while being
nicer for lazy scripters it means there is more duplicate Py/C-API
functions that are alredy not well maintained
- (its quite easy to find bugs in the existing BGE C/Python api).
With doubling up on some obscure functions - errors in the API more
easily slip through the cracks and the task of maintenance is more of
I posted the original mail in the BGE forum and nobody is complaining
that scripts will need updating.
(even requests for more disruptive changes)
More information about the Bf-committers