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 <[email protected]> wrote: > Hi Mitchell, > > On Sun, Mar 20, 2011 at 12:39 PM, Mitchell Stokes <[email protected]> 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- No essence. No permanence. No perfection. Only action. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
