Hi Zerochen,
I greatly appreciate you reporting these findings to me so that I could fix them.
These are quite surprising as they are not things that I would do in a normal state-of-mind, but I've worked a lot on IrrBullet when I was tired, hurrying, or concentrating on deep implementations or big changes so I guess that is probably how they weaseled their ways in there. Also, these oddities are in code that dates back to the start of IrrBullet, so I haven't worked with them in quite some time; in fact, I haven't worked on IrrBullet much in quite some time, either.
With that said, all of the things you mentioned have been fixed. Update from the IrrBullet trunk to get the new code.
Now on to your question about UniqueID:
I chose not to let the user handle UniqueID so that it can never be -1 and there can never be any duplicates. It should never be -1 because the IrrBullet system uses UniqueID to identify collision objects.
About the collision loop:
"<-2.1 is an obj that is non static only gets the colide attribute?"
The "collide" attribute was only used in the collision example for special types of objects. It is not added by IrrBullet.
"<-2.2 is this the right way to bounce the body away from the sec? is a effektor here better?"
If you want to apply a single instantaneous impulse to something, use applyImpulse() or internalApplyImpulse().
If you want to bounce the object away from where it collided, use something like this:
Code: Select all
SManifoldPoint point = info->getContactPoint(i);
irr::f32 speed = 10.0f;
static_cast<IRigidBody*>(info->getBody0())->internalApplyImpulse(point.getNormalWorldOnB().normalize()*speed, ERBTS_WORLD);
I wrote this code directly in my reply, so it hasn't been tested, but it should work just fine. Note that you must loop through all of the contact points in the collision callback.
Make sure you check that point.getDistance() is equal to 0 to make sure it is an actual physical collision and not just an AABB intersection.
Also, don't use an affector for something like this. Affectors are for behaviors that are meant to persist for an object's lifetime or for special cases where an affector would be useful.
"<-2.3 is this the right way to clear & delete the info?"
Yes, that is the correct way to delete the info. I might end up renaming the function "getCollisionCallback()" to "createCollisionCallback()" so that it's more obvious that the returned pointer must be manually deleted.
I hope that covers all that you need to know. Thank you for using IrrBullet, and thank you for being an important part of its progress (by reporting bugs and oddities).