onCollision callback
by Bojan Vukojevic · in Torque Game Builder · 03/18/2011 (7:31 am) · 9 replies
Hello all,
Collisions are giving me some hard time would appreciate any help. I have an asteroid floating around in space. It has both collisions and both physics turned on and response is KILL. There is an another object that has receive collision on, send physics and callback. OnCollision looks something like this:
Echo is there just for test. Problem is whenever this collision happens it is called 3 times ie 3 echoes. Asteroid gets destroyed but it acts like it hit the object 3 times instead of only once, at least i expect it to hit only once. Can someone explain me this behavior? One more thing. Time, normal, contacts and points are all blank. I do not need them now but maybe later i will need %normal so would be great to know how to enable them. I tested with everything on, both physics and both collisions but still empty.
Thanks
Collisions are giving me some hard time would appreciate any help. I have an asteroid floating around in space. It has both collisions and both physics turned on and response is KILL. There is an another object that has receive collision on, send physics and callback. OnCollision looks something like this:
function GarbageCollectorClass::onCollision(%srcObject, %dstObject, %srcRef, %dstRef, %time, %normal, %contacts, %points)
{
if (%dstObject.getClassNamespace()$="Asteroid")
{
echo("HIT");
}
}Echo is there just for test. Problem is whenever this collision happens it is called 3 times ie 3 echoes. Asteroid gets destroyed but it acts like it hit the object 3 times instead of only once, at least i expect it to hit only once. Can someone explain me this behavior? One more thing. Time, normal, contacts and points are all blank. I do not need them now but maybe later i will need %normal so would be great to know how to enable them. I tested with everything on, both physics and both collisions but still empty.
Thanks
#2
03/22/2011 (6:01 am)
I've run into situations where an object is suppose to Bounce off of another, but instead it gets stuck to the object repeatedly bouncing. The only way I have found to fix this is that when the object collides with another object the first thing I do is turn it's collision off, and set a timer for 50 to 100 milliseconds to turn it back on. This fraction of a second is long enough for the object to Bounce free of the other object. Turning the Collision off first thing may help to resolve your problem.
#3
What bothers me is this expected behavior on torque side? Is it supposed to trigger 3 collisions always, is this a bug or error in my program? If it is an error i would like to know what i'm doing wrong so i can avoid it in the future or if it is intended maybe use it for something who knows. And why are other onCollision variables empty?
Anyhow, thanks for the answer i'll use that for now.
03/22/2011 (6:14 am)
In theory this is not a big problem. I will tag the object with some variable for the first time it hits, do what ever i need to do once, and when i get the second and third collision i will just check the tag variable and skip doing the same thing 3 times. But i think i will go with your suggestion i think it will work perfectly for my situation. I just need to disable collision because the response is KILL so no need to enable it again. What bothers me is this expected behavior on torque side? Is it supposed to trigger 3 collisions always, is this a bug or error in my program? If it is an error i would like to know what i'm doing wrong so i can avoid it in the future or if it is intended maybe use it for something who knows. And why are other onCollision variables empty?
Anyhow, thanks for the answer i'll use that for now.
#4
As for KILL response, I believe it just doesn't destroy an object at the same exact moment, and object has enough time to collide two more times. If you expect your asteroid to do something special on collision, like destroy itself, it should be done within it's onCollision() callback.
03/22/2011 (8:14 am)
I've seen someone here complaining about CodeWeaver not showing variable content, so you may want to echo your variables to make sure they are actually empty.As for KILL response, I believe it just doesn't destroy an object at the same exact moment, and object has enough time to collide two more times. If you expect your asteroid to do something special on collision, like destroy itself, it should be done within it's onCollision() callback.
#5
This is a perfect example of how being mindful to the scientific process and adherence to the rules of logic can not solve the problem of Ignorant Design. Ignorant Design being the most insidious of fallacies, is the mutation of a complex system to the point of convoluted functionality.
"What bothers me is this expected behavior on torque side?" : "And why are other onCollision variables empty?"
Expected? Acceptable? No, Computer Science mandates comprehension and adherence of a logical naming convention and consistency of design to fulfill desirable function. What should truly bother you is how easy it is to forget the fundamental protocols as a complex system is under progressive evolution.
"Is it supposed to trigger 3 collisions..."
Expressing the scientific laws of physics, using the only language capable to universally communicate action/reaction as a consistently predictable truth( ambiguously know as MATH to homework suffering youth worldwide) is fundamentally a termindusly complex concept, regardless of linguistic ability.
To maintain the illusion of 'realistic' causality in a simulated system, much of the complicated redundancy of 'real world' laws of physics calculations are essentially estimations, a much smaller consideration of the essential information. All 'physics' simulators compromise erratic behavior in favor of simulation 'speed'. The game designer must find optimal solutions to the manifestation of this erratic behavior, because this is not a 'bug' in the code but abnormalities by proxy of small dataset mathematical simulations.
03/22/2011 (10:53 am)
My reply is motivated by how thoughtfully crafted you appeal to logical expectations.This is a perfect example of how being mindful to the scientific process and adherence to the rules of logic can not solve the problem of Ignorant Design. Ignorant Design being the most insidious of fallacies, is the mutation of a complex system to the point of convoluted functionality.
"What bothers me is this expected behavior on torque side?" : "And why are other onCollision variables empty?"
Expected? Acceptable? No, Computer Science mandates comprehension and adherence of a logical naming convention and consistency of design to fulfill desirable function. What should truly bother you is how easy it is to forget the fundamental protocols as a complex system is under progressive evolution.
"Is it supposed to trigger 3 collisions..."
Expressing the scientific laws of physics, using the only language capable to universally communicate action/reaction as a consistently predictable truth( ambiguously know as MATH to homework suffering youth worldwide) is fundamentally a termindusly complex concept, regardless of linguistic ability.
To maintain the illusion of 'realistic' causality in a simulated system, much of the complicated redundancy of 'real world' laws of physics calculations are essentially estimations, a much smaller consideration of the essential information. All 'physics' simulators compromise erratic behavior in favor of simulation 'speed'. The game designer must find optimal solutions to the manifestation of this erratic behavior, because this is not a 'bug' in the code but abnormalities by proxy of small dataset mathematical simulations.
#6
Disabling collisions and/or deleting object does not help, still 3 collisions. The thing is i know what simulations are and what the limitations are, i even have some professional background in that field (very limited but i definitely know what are you talking about). When i created my simulations and heuristics i always knew what the limitations are and what i sacrificed for speed. I just wanted to know a little bit more about this simulation. I've read collision details by Melvyn May and found no details about a number of collision responses in different situations. Do you have any details about this?
03/22/2011 (1:08 pm)
I appreciate your answer Caylo but i think you are over analyzing this. I tested what Rpahut suggested and actually the debugger is not displaying them in watches. If i echo them they are there. Thanks for that Rpahut. And thats not a complex real world physics simulation its just the way debugger displays it. Maybe i need to activate some options in torsion not sure i will check that. Disabling collisions and/or deleting object does not help, still 3 collisions. The thing is i know what simulations are and what the limitations are, i even have some professional background in that field (very limited but i definitely know what are you talking about). When i created my simulations and heuristics i always knew what the limitations are and what i sacrificed for speed. I just wanted to know a little bit more about this simulation. I've read collision details by Melvyn May and found no details about a number of collision responses in different situations. Do you have any details about this?
#7
03/22/2011 (2:01 pm)
My reply is not the product of over analyzed observations, but the mistake of assuming the motivation behind your thoughtful questions are the actions of a Inquiry Based Learning technique. So for the convolution to the scope of what your thread is directed, I am sorry.
#8
03/22/2011 (2:20 pm)
Tbh any input is very useful to me at this moment. I am a programmer for a long time, but i made a long pause because i wanted to change a little and went to networking and decided to enjoy programming in my spare time as i do now. I'm used to strict programming as i did some assembler for a while and i must admit that maybe i still do not get torque and whole game programing as i should. But sometimes everyone needs to ask some questions even if it looks unnecessary. We are all humans after all :)
#9
03/22/2011 (8:20 pm)
Yes, indeed most of us are indubiously human.
Bojan Vukojevic
Default Studio Name