[Bf-committers] Feedback on BGE Collision API

[Jim Williams]

Why not on collision try calling each object's on_collision method if
it exists, and handle events like every other modern system?  I thought
there was some way in python of getting an object's methods.

I'd suggest looking for on_collision_start, and on_collision_continuing
methods to call.....

(I'm new to both python and Blender....)

On Sun, Mar 20, 2011 at 2:12 AM, Alex Fraser <alex at phatcore.com> wrote:
> Hi Mitchell,
>
> On Sun, Mar 20, 2011 at 12:39 PM, Mitchell Stokes <mogurijin at gmail.com> wrote:
>> I'm getting tired of not having access to collision information from
>> the BGE Python API, so I've decided to address this.
>
> Great! I would love to have such a feature in the BGE.
>
>> However, I'm uncertain as to how the user should access this events.
>
> I prefer the list (obj.collisions), but it would be very useful to
> know when that list changes, like what we already get from the Near
> sensor - a list and an impulse.
>
> Maybe this is a good opportunity to add other events, too? Things I
> would be interested in registering callbacks for are:
>  - Collisions
>  - End object
>  - Property change
>  - Parent set
>  - Children added/removed
>
>> Other events like keyboard and mouse events are done by checking some
>> sort of list.
>
> If we wanted to get really fancy, we could add callbacks for mouse events too.
>
>> A callback example would look something like:
>>
>> def col_bomb(self, ce):
>>        if ce.object.name == "Bomb":
>>                self.endObject()
>>
>> obj.register(col_bomb)
>
> That looks good, but I have a couple of suggestions. Firstly, if in
> that example self == obj, I would prefer it to be a member of ce:
>
> | def col_bomb(ce):
> |        if ce.other.name == "Bomb":
> |                ce.owner.endObject()
>
> And to allow registration of other event handlers, let's rename
> 'register' to 'add_collision_callback'.
>
> | obj.add_collision_callback(col_bomb)
>
> What if the callback is a method? You might try using a closure, like this:
>
> | class Foo:
> |     def add_object(self, obj):
> |         def col_bomb(ce):
> |             if ce.other.name == "Bomb":
> |                 self.whatever(ce.owner)
> |
> |         obj.add_collision_callback(col_bomb)
>
> However keeping a reference to self in the inner function will prevent
> it from being deleted (so weak references won't work). I guess you
> could keep a weak reference to self in the inner function instead.
>
> Alternatively we could allow class instances to be passed in as
> handlers, and standarise on the method names for callbacks:
>
> | class Foo:
> |     def on_collision(self, ce):
> |         if ce.other.name == "Bomb":
> |             self.whatever(ce.obj)
> |
> |     def add_object(self, obj):
> |         obj.add_collision_handler(self)
>
> But then you have the same problem - add_collision_handler would have
> to have an option to only keep a weak reference. So maybe it's better
> to just accept a callback function, and let class methods use a
> closure if they need it.
>
> I see you have CollisionEvent.force in your proposal in the wiki - great idea!
>
> Cheers,
> Alex
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
No essence.  No permanence.  No perfection.  Only action.