Handing collisions without physics

#1 James it's even better than that!

Select object > Edit > Scripting > Class > fill in a class like MyThing
Select object > Edit > Edit > Collision > Callback =yes
Then in script somewhere write:

MyThing::onCollision( %this, %srcObject, %dstObject, %srcRef, %dstRef, %time, %normal, %contacts, %points)
{
//note: the 1st parameter is %this
}

Much easier than catching onCollision at a higher level than you are doing.

#2 Cool! I guess you can do the same thing with all of the callback functions, mmmhhmm.

But, The player is the only object sending collisions, and everthing else is recieving. So... I can give every object that recieves collisions their own onCollision function!

Horray, goodbye switch.

#3 Problem, %dstobject is showing up blank in objectclass::oncollision(etc)

Maybe its a typo, ill keep looking

#4 Check your function arguments agains the info in the reference documentation. You may have left something out. It's easy to do for that callback because it has so many arguments.

#5 Not sure, but I think I've noticed the same think as James. Is it possible that %this is the source object and %srcObject is really dstObject? Can't test it right now tho.

#6 I didnt leave anything out, but %this is never mensioned in the documents. What does %this point to? It doesnt seem to be the dstobject either.

Something odd happend, The dstobject has a "tag" I set when it is created. In oncollision when i echo(dstobj.tag) it is the correct tag, like dst IS the right object, but then when I try dstobject.getposition or .getanimationname or any other sceneobject function i get the error--object "" attempting to call function setpostion/etc not found. And when I echo(dstobject) I get a blank string, not the 4 integers that are like an objects id, that I normally would. So its like dstobj is blank, but something is still there because the .tag data is there.

One idea, my object is not registering as a sceneobject anymore, thats why it cant use sceneobject functions, where .tag is just a custom data field. When I created the said object I did

%obj = new t2danimatedsprite() {
scenegraph = scenegraph2d;
position, other stuff, etc...;
tag = "obj";
class = "obj";
};

Could having the same name for tag/class/obj be a problem? I wouldnt think so. Do I need to set t2dsceneobject as the superclass or something? Is class = "obj"; overriding something? Are you sure we need %this ? Ill do some testing.

#7 My mistake about using %this parameter in onCollision. There I go again ASSUMING that torquescript is object oriented when it really is not. Unlearning.

For example in scrollerDemo missile.cs in the demo, they use this technique in several places:

Quote:function playerMissile::onCollision( %srcObj, %dstObj, %srcRef, %dstRef, %time, %normal, %contactCount, %contacts )

No idea what's causing your malfunction James- maybe start with the code in scrollerDemo and see if that works for you.

#8 James, what if name your objects & then you put this in your script for debugging?

warn("MyClass::onCollision" SPC %srcObject SPC %dstObject );
   if(isObject( %srcObject) )
      warn( "src:" SPC %srcObject.getName() );
   if(isObject( %dstObject) )
      warn( "dst:" SPC %dstObject.getName() );

You will see that srcObject should always be an instance of MyClass.

#9 I took out %this and I'm not having the wierd problems I was before, but..

when I echo srcobj and dstobj every oncollision I found that srcobj is sometimes an object (of mine) that can only receive collisions and dstobj is sometimes an object that can only send collisions... like srcobj / srcobj are in the wrong order. But it is not backwards all the time.

One consistent way to describe what the first two paramenters are giving me are

function myclass::oncollision(%this_obj, %other_obj, etc..)

The first parameter is always the other object in the collision, and the second is always the object who's oncollision function we are in.

There is noway to tell which is the sender and which is the reciever unless you test getcollisionactive

is this a bug? I don't see why else I would be getting an object for the first parameter that cannot send collisions...

#10 I moved this to the bug forum, although im not getting much feedback anymore '-(

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

#11 In your onCollision callback (or any class method for that matter) the first argument will always be an ID (or 'handle') to the instance of the class the method is called on. It is a little confusing that onCollision() uses %srcObj rather than %this, however it's actually the same thing. You could do the following and it would be entirely valid:

function MyObjectClass::onCollision(%this, %dstObj, %srcRef, %dstRef, %time, %normal, %contactCount, %contacts)
{
   if(%this.class $="MyObjectClass")
      echo("Yep, it's 'this'!");
}

I hope this clears up any possible confusion.

#12 Umm...sorry if my post seems a little stupid. Perhaps it is. But for collision detection, I've always used a virtual x/y in changes for position then calculated collision based on those. If that virtual x/y collides, then find a space in between the virtual and current xy which does not collide and apply a position outside the wall. Perhaps that is supposed to be done automatically with the built in collision detection?

#13 @Thomas- not sure... have you read this doc ? documentation\tutorials\Feature Tutorial\Collisions.pdf

#14 Well considering the problems Ive had with the built in collision detection your way might be pretty smart, just experiment I guess.

#15 The built in collision detection works great for me.

#16 James, the onCollision gets called for both objects if a collision takes place. I think there is a way to have it send to one object only but I forgot the variable name for that one.
Second, if you want to switch off physics for both objects you have to set them both to receive physics only and fix the bug I posted in the bug forums.

#17 I was able to get things working properly by just making sure there were never any overlapping, colliding objects. Just letting people know.