Collision to collect objects

#1 I'm assuming that you want to use the player collision for the ground etc.

There are different ways of doing this but a couple of ways are:

1) Use a surrogate object mounted to the player that acts as the "catcher". It can have the identical collision polygon (if you wish). In this way you can disable its collision physics response and also only tell it to collide with coins etc.

2) You can use the pick-functions like "pickRect()" or more preferably "castCollision()" and you'd perform these in the players "onUpdate" callback.

The first one is the most preferable. There are other ways involving triggers but they can get expensive.

Even though I wrote TGB I'm nowhere near as experienced as others around here at actually using it so others may have funkier suggestions. :)

Melv.

#2 What is your player's collision response mode, and is he sending/receiving physics?

Anyhow, it might clear up the problem if you set your "coin" to NOT send/receive physics.

#3 Thank you for the responses. Here are a few more details.

The Player object is set to send collision and send physics. No receiving. The coin is set to receive collision and physics. If I turn off the coin receive physics, although the collision still happens and I can see that through some debug in the callback, the "kill" response does not occur. The coin is only killed with the receive physics on.

Now with the physics turned off on the coin, the player still runs into it and stops as if they had run into a wall. I can only assume this is because the player is set to send physics?

I just need the coin to do the kill on the collision, but for the player to not physically be hitting anything.

Thanks again for your time!

#4 Rather than using the collision response mode to kill the coin, instead just do a safedelete within the collision callback. Then you can disable physics altogether for that object.

#5 Maybe I am doing something fundamentally wrong. If I turn everything "off" for the coin, leaving it only with receive collision (which seems to be necessary for it to know something has hit it), as well as callback, the player controlled object still "hits" the coin.

The only way I can get it to pass though the coin but still register the collision is if I turn the send physics off for the player controlled object. If I do that then the player passes though all the objects. Am I just missing something that is making this more complicated then it probably really is?

#6 Oh crud, well try this...

Make your player both send and receive collisions. Then have your coin send collisions. Then keep your player send-physics but not receive physics.

The bad thing is having all your coins sending collisions is expensive. There might be another way to do this by having another invisible object mounted to your player which never does physics and have it be your "coin-collector". That is, your player does not actually collide with them at all, your collector does.

Oh now I understand what Melv was saying all along '-)

#7 After thinking it through, I also understand Melv! This solution works well thus far. I've attached an invisible circular object to my player object. This special object now hits the coins before the player object does and using the safeDelete() as suggested works perfectly.

Thanks to both of you for helping me with this!

#8 You're most welcome.

Melv.

#9 I'm going to bring this topic up again, because after a couple of iterations in code, I find myself back to a similar situation and am thinking again about solutions.

My question is this. If Object A is sending and receiving physics and collisions and it collides with Object B which is only receiving collisions and NOT sending physics, why does Object A still have a physical response to Object B?

The way I would think of it is that Object A is sending physics for objects that are receiving physics and it is receiving physics from other objects that are sending them.

Hope that makes sense.

One last example. If I place a crate on the ground that only receives collisions, NO physics. I would expect that all objects would pass though it. Still colliding in a sense, but no physical response. This does not seem to be the case. Could somebody set me clear so this makes more sense to me?

Thanks!

#10 The way I look at it the sender/receiver naming-scheme ... it does not imply anything about "who moves who" or "how" although it sounds a lot like it might. Instead all it is used for is detecting when a collision occurs.

Eg. the criteria for a collision is there is an overlapping sender and receiver.

The "how" part of the collision is specified on each object as a collision response mode, which is used whether that object is a sender or a receiver (I'm pretty sure thats right, on the last part).

#11 If there was a collision response mode such as "None" or "Off". Then that would make perfect sense to me. However, if I simply want an object to use the collision call back should some other object hit it. i.e a sender overlaps it as a receiver that does not seem to be possible.

It seems like I should be able to tell an object to not be impacted by any physical collisions. For instance, lets say I wanted to have a game with a ghost. I want the player to be able to walk on the floor and not fall though. I also want the player to pass through the ghost as if it isn't even there. However, when the player passes though the ghost, I want the ghost to play a different animation.

I just made that up, but I think it illustrates what I am trying to understand. I want the ghost to receive collisions, just not in a physical way. They way I would think to do that would be to have the ghost receive collisions, but not physics, and check the callback option. The player I would set to send collisions and physics. However from what I have been learning this is not how this should be approached.

Thanks for continuing the discussion. This is all very helpful to me, understanding the ins and outs of TGB.

#12 Hmm, isn't there a "custom" option in the collision response dropdown? Assuming you haven't actually added a custom response in C++ that will equate to a "None" response. If that isn't there anymore for some reason it should be!

Alternatively, heres a possible solution for that example... If your ghost does not need collision at all then disable send/receive physics. But keep receive collisions on and callback on. Then assuming your player sends collisions you can handle the ghost/player collision in the ghosts callback and switch the animation -- and no physics response will occur for either player or ghost.

#13 There is no custom option in the collision response, its only available in the collision detection. Although there are options like NULL and OFF when you are setting the response for world limit collisions.

Going back to the ghost example. Your solution seems to be exactly the thing that I cannot seem to do.

Here is a simple test.

1. Take a blank level and add a single object. I'm using a small yellow ball. Set it to receive collisions only. CLAMP still being the default response.

2. Insert a new object directly above the first one. Set it to send collisions and send physics. Also give it a constant downward force of say 10.

What happens when the object falls and collides with the other object? Do you expect it to fall straight through or stop?

It stops. It physically hits the other object. Now if you change the falling object to only send collisions and not send physics it will fall straight through.

This is why i get so confused. So back to the ghost example, it would seem like the player cannot be sending physics in order to pass though the ghost.

#14 Wow, I guess I've been working in TGEA for too long and totally got the TGB collision system switched around in my head (again).

Try setting your objects CollisionResponse field = "CUSTOM"; by modifying your level file. It may not be an option in the editor but I'm willing to bet its still there. Here is a quote from the TGB docs, in the collision feature tutorial:

Quote:
Response Modes

Now that the block and the asteroids respond to each other, we can play with some of our other options. The Response Mode dropdown contains the possible responses that objects can have to collisions. Select the asteroid and take a look at the Response Mode options. Notice that we were using CLAMP. Here is a brief description of the possibilities:

BOUNCE: A simple, pong-style bouncing effect.

CLAMP: The colliding object slides along the surface it hits. This is good for surfaces that the player moves along.

STICKY: The colliding object completely stops.

KILL: The colliding object is deleted.

CUSTOM: No built-in response. This is used when you want to write your own collision response into the C++ engine code. Note that if you want to script your own collision response using TorqueScript in an onCollision function, rather than write it in C++, you need to select the Callback checkbox.

#15 Just a little bit of a further explaination on that, let's have a look at your example:

Quote:1. Take a blank level and add a single object. I'm using a small yellow ball. Set it to receive collisions only. CLAMP still being the default response.

2. Insert a new object directly above the first one. Set it to send collisions and send physics. Also give it a constant downward force of say 10.

What happens when the object falls and collides with the other object? Do you expect it to fall straight through or stop?

In this case you expect it to stop if it hits a flat surface. The clamp response will prevent the object from moving through it.

Quote:It stops. It physically hits the other object. Now if you change the falling object to only send collisions and not send physics it will fall straight through.

Again this is expected. Think of it this way, when an object is sending collisions the system asks the object if it would like to affect it's physics as well using the sendPhysics property (Eg velocity etc). So in the case above your saying that the object should be sending collisons but not physics so when it does collide with something it ignores the collision physics response, in the case the CLAMP response.

Quote:This is why i get so confused. So back to the ghost example, it would seem like the player cannot be sending physics in order to pass though the ghost.

This is where custom comes in. Lets say you have a player object using a behavior to control movement etc as per the following:

if (!isObject(PlayerBehavior))
{
   %template = new BehaviorTemplate(PlayerBehavior);
   
   %template.friendlyName = "Player Velocity";
   %template.behaviorType = "Player Object";
   %template.description  = "Sets up the player for use";

   <Player code here>
}

Now what you would need to do here is attach an onCollision call back to handle any custom collision response. For instance:

function PlayerBehavior::onCollision(%srcObject, %dstObject,%srcRef, %dstRef,%time, %normal, %count, %points)
{
   <custom code here>
}

You could then test to see if the object you collided with is a ghost, and if it was do nothing. If it wasn't a ghost you could modify the velocity appropriately. Does this make more sense ?

#16 Thank you for the detailed response.

Quote:
Again this is expected. Think of it this way, when an object is sending collisions the system asks the object if it would like to affect it's physics as well using the sendPhysics property (Eg velocity etc). So in the case above your saying that the object should be sending collisons but not physics so when it does collide with something it ignores the collision physics response, in the case the CLAMP response.

Correct me if I'm reading this wrong. If my player is set to send collisions and send physics, are you saying that the send physics relates to if I want physics to be applied to my player, or the objects my player collides with?


Like I believe you were saying. If I could say, I don't want the collision to effect anybody's physics AND I do not want to CLAMP as a result of the collision. I simply want to get a callback when these objects come into contact and I'll take care of everything. Sounds like a straightforward request.

But there is no CUSTOM option for the response. In fact it appears the collisionResponse field is left out of the level file if CLAMP is chosen as it appears to be a default. If I add it and set it to "CUSTOM" as James had suggested, it still acts like clamp.

#17

Quote:
Correct me if I'm reading this wrong. If my player is set to send collisions and send physics, are you saying that the send physics relates to if I want physics to be applied to my player, or the objects my player collides with?

No, think of it like this, there are normally two parts to a collision, the first part is the test.

If I have send Collisions active on Object A then Object A will always test to see if it collided with something. If I have receive Collisions active on Object A then Object A will always generate collisions when other objects hit it.

The second part of the collision is the response, and generally speaking a response from any collision will be a physics response.

If I have send physics active on Object A then Object A will always feed a collision response into the physics system if it has collided with something. If I have recieve physics active on Object A then Object A will always feed a collision response into the physics system when another objects hit it.

So what exactly does this mean ? If Object A collides with Object B and Object A has both send collisions and physics active then object A will generate a collision and feed the response into the physics system. So if Object A's physics response is "CLAMP", that is what the collision test will feed into the physics system.

Quote:
Like I believe you were saying. If I could say, I don't want the collision to effect anybody's physics AND I do not want to CLAMP as a result of the collision. I simply want to get a callback when these objects come into contact and I'll take care of everything. Sounds like a straightforward request.

But there is no CUSTOM option for the response. In fact it appears the collisionResponse field is left out of the level file if CLAMP is chosen as it appears to be a default. If I add it and set it to "CUSTOM" as James had suggested, it still acts like clamp.

Ok, I just loaded up the level editor and selected a sprite and went to the edit properties rollout and looked into the Collisions tab and you are right, there is no CUSTOM. However, you probably don't want to use this anyway as writing a custom Physics response to do what you need is a little bit overkill. In this case, you have an object that you don't want a standard collision response to be used each time the player collides with an object. Because you don't have a standard response for all collisions, you need to turn off sending and receiving physic responses as you don't want to use the standard physic response.

You will also need to turn on the callback function so that you can use onCollision to handle any collision tests for this object.

Does that make more sense now ?

#18 This has been very helpful. I took a couple of days to try to digest this before I responded. I think the bottom line here is that you can't have an object have a physical response to some collisions and a non physical response to others.

I was under the mistaken impression that this could be controlled by the "receiving" of the physical collisions on the other object.

So I think my next I will try to make some modification to my project to remove the need for the physical collisions. The more I think about it, I think that is a real possibility. Assuming I can use castCollision to basically stop the movement of the player when they are about to hit something, I should get the effect I'm looking for.

Thanks again for everybody's help and patiences in this thread. Without the support of the community I'd have made very little progess on my project.

#19 If you want a player to collide, then stop. Just use the "onCollision" callback option and do something like:

%dst.setLinearVelocity("0");

I didn't look up the actual function but it would be very similar to this.

#20 I've been trying to do this same exact thing. Melv, it seems that it would be a handy feature to be able to control which objects/layers/groups have "physical" reactions to each other in the same way that we now have control over "collision" reactions (by clicking/unclicking the 32 layers/groups). An easier alternative would be to have a NULL response as was mentioned above. Either way would fix a lot of workarounds I have to put in place to get this to work.