Game Development Community

RC3, oncollision parameters not clearly labeled

by James Ford · in Torque Game Builder · 06/17/2006 (9:08 pm) · 6 replies

This was originally a question from the following thread, but I now believe it is a bug

www.garagegames.com/mg/forums/result.thread.php?qt=46024

I have several objects all with oncollisioncallback true. Only one object can send collisions, the player, all the others only receive collisions and physics is off for everything, so I resolve all collisions in oncollision, mostly in the receiving objects' oncollision functions.

I have an obj_class::oncollision for each object, but the thing is... the first parameter is NOT necessarily the object sending the collision (as the documents say), and the second is not allways the receiver.

I assumed if an object received a collision and had callback true, then in its "obj_class::oncollision" function, the first parameter would be the sender/other object, and the second would be the receiver/this object.

And likewise, if an object sends a collisions and has callback true, then in its "obj_class::oncollision" function, the first parameter would be the sender/this object, and the second would be the receiver/other object.

However, what I am seeing is, the object that triggered the callback, sender or receiver, the object whos oncollision function we are in, is always the first parameter, and the other object involved in the collision is always the second parameter.

So, if i want to findout the real sender/receiver I have to use getcollisionactive.. Which is not necessarily a big deal, but from everything I read its suppose to be "oncollision(srcobj,dstobj, etc)" and that is not what im seeing and it took a while to figure out what was going on.
NextNext Thread
PrevPrevious Thread
More from Torque Game Builder


Associate James Ford
Sickhead Games
#1
06/18/2006 (9:59 pm)
I'm working around this without difficulty, but the documentation is just wrong...

its oncollision(%thisobj, %otherObj, etc...)

Torque Owner Jason McIntosh
#2
06/19/2006 (6:16 am)
I think it's because they chose to list those function arguments differently than the expected convention of naming the "this" object %this. Dunno why for that function, probably to help clarify, but it obviously is causing a ruckus.

You can change %this to %anythingYouWant in any of the namespace functions. For example: 
function myClass::myFunc( %me, %foo )
Using %this as the first argument is just a convention, it's not a compiler rule. Might be useful to keep that in mind.

Associate James Ford
Sickhead Games
#3
06/19/2006 (9:41 am)
Yes, this is probably not a *bug* but they mislabeled the parameters and have it incorrect in the documentation.

Torque 3D Owner Matthew Langley
Torque
#4
06/19/2006 (11:09 am)
I agree that this is not a bug. I also agree that the documentation inadequately describes the %srcObject and %dstObject parameters. Though I disagree that the params on the callback are mislabeled.

%srcObj and %dstObj are exactly what I would've guessed them to be. To me it makes perfect sense that in the callbacks for each of the objects involved the other object would be the second param and the object themselves would be the first object. They both should trigger a callback response (when you check callback) if involved in the collision.

I agree the documentation allows for a lot of confusion... "The object sending the collision" and "The object receiving the collision". I think the concept behind this wasn't the Send/Receive collision options on the object, but the concept behind them... Thanks for sharing how confusing the definition is though.

Torque Owner Vern Jensen
#5
06/19/2006 (2:18 pm)
Speaking of this, I was unable to add collision detection in the shooter tutorial the way the tutorial told me to do it. I got it working, however, by putting an onCollision method in the enemy.cs file, rather than adding similar code to the playerMissile.cs file as the tutorial suggests. Here's my addition to enemy.cs:
function enemyShip::onCollision( %srcObj, %dstObj, %srcRef, %dstRef, %time, %normal, 
%contactCount, %contacts ) 
{ 
    if(%dstObj.class $= "playerMissile") 
    { 
         %srcObj.explode(); 
         %dstObj.explode(); 
    } 
}

Maybe it's just me doing something stupid, or maybe it's that the tutorial isn't correct. Not sure.

-Vern

Torque Owner Anthony Fullmer
#6
06/19/2006 (11:20 pm)
As far as i know, the tutorial is correct, people have tested it over and over and this is the first time i have heard that this didnt work...so naturally i would assume that it was a slip of the keystroke.