[Bf-committers] BGE API - was 2.49 release proposal

blender at erwincoumans.com blender at erwincoumans.com
Wed Feb 18 21:30:24 CET 2009


Good to see there is some interest in BGE development. 

Whenever possible, can you please make sure to make your changes backwards 
compatible, so the scripts don't break? 

I like Benoits proposal to use Blender 2.49 as a bridge to 2.50 (that breaks 
all backwards compatibility?), so 2.49 can still run all demos including in 
the latest BGE books etc. 

So please avoid changing functionality for an existing method without 
changing its name. It would be better to add a new method under a different 
name that returns an actual object instead of name, or skipping the prefix 
OB/MA/ME etc. 

Thanks a lot,



On Feb 18, 2009, at 7:08 AM, Campbell Barton wrote: 

On Wed, Feb 18, 2009 at 6:21 AM, Mitchell Stokes <mitchell at daboys4u.com> 
These are some good suggestions. I'll what I can do (or who I can poke :P )
about them. However, I think a few points need to be made. 

On 1. This makes sense for most actuators. But a few should return a name,
like Add Object's object property since there is no object for it until it's
actually added (at which point you can use GetLastCreatedObject()). 

Theres no need for it to return the name. The add object actuator has
2 pointers...
SCA_IObject*	m_OriginalObject;
SCA_IObject*	m_lastCreatedObject; 

So both can be accessed as attributes act.object, act.objectLast
(readonly), if no object added yet then return None. 

On 2. This may be used since there is an identifier for things besides
objects, there's also IM (image), MA (materials), and such. I don't know if
removing the prefix will cause issues, but probably not since Blender should
already be smart enough to know which to look for. 

Your right but I don't think this is a problem since the BGE dosnt
have lists that mix images/materials/objects etc in one place.
Its also not a problem for blender's UI or though the python api from
my experience since all commands are clear about what type there
dealing with. 

On 3. This would make things a whole lot nicer, and simpler. 

Thanks again for your suggestions and interest in the topic! 

 --Mitchell "Moguri" Stokes 

On Wed, Feb 18, 2009 at 3:52 AM, Campbell Barton <ideasman42 at gmail.com>

Hey there, not sure if these changes would be appropriate for 2.49 or
2.5  BGE api but will suggest them anyway and see what ya think. 

1) return Objects, Meshes, not their names. 

BGE api by default will return an Object/Mesh name when running
actuator.getObject() and similar. Its much more useful to return the
object or mesh its self, since I found in many cases I needed to
lookup the scenes for the object name since I wanted to check the
objects location or a property on it.
I added an optional argument for some of the actuators to get the data
rather then the name, but with attributes there are no arguments so
for existing scripts...
act.getObject() -> act.object.name
...If we decide to return Objects/Meshes rather then just names. 

there is a reason id.name+2 is used throughout blenders code. Not sure
why nobody picked this up in the BGE before a release.
For those of your who are not aware "Suzanne" is known as "OBSuzanne"
in the BGE, Having to do  'ob.name[2:]'  is annoying. 

3) return Mathutils types Vector(), Matrix() etc.
Its annoying that in C++ you can do vec1+vec2 but in the python API
you have do this one axis at a time or convert to Mathutils types.
We switched some parts of Blender.* api to use Mathutils types and
surprisingly few scripts broke because in most cases they can be used
interchangeably with tuples/lists. 

1) and 2) I'm quite keen on having,  3) is just a nice touch.
For the changes I mentioned scripts will need updating and this will
break more then the proposed get/set -> attributes change.
Otherwise all these changes are quite easy to do, I can probably find
the time in the next few weeks.
I'll also update scripts in YoFrankie's SVN repo. 

 - Campbell 

On Tue, Feb 17, 2009 at 4:37 AM, Benoit Bolsee <benoit.bolsee at online.be>
I'm strongly in favor of a 2.49 release. There has been significant
improvements on the BGE side that deserve an official release:
VideoTexture, BGE API cleanup, bug fixes. 

For the BGE API cleanup, we plan to have a transition phase where the
old API will still be supported but will produce deprecation warnings on
the console. A 2.49 release will allow us to propose a smooth transition
from 2.4x to 2.50 by introducing the new API in 2.49 and dropping the
old in 2.50.
Then the procedure to upgrade the scripts will be as follow: run your
game under 2.49 with warnings enabled, fix the scripts until there is no
warning, the game is ready for 2.50! 

Without a 2.49 we will have to do the transition between 2.50 and 2.51,
which looks a bit odd, or worse between a unofficial release and 2.50. 

Of course if we decide to go for a 2.49 release, I'll make sure that the
new API and VideoTexture and fully ready for the release. 


Bf-committers mailing list
Bf-committers at blender.org

Bf-committers mailing list
Bf-committers at blender.org

Bf-committers mailing list
Bf-committers at blender.org



 - Campbell
Bf-committers mailing list
Bf-committers at blender.org

More information about the Bf-committers mailing list