Collision Callback with receive collisions only

#1 I was having a similar problem -- have you tried using triggers? That provided the functionality that I needed, without physics interference.

#2 No I haven't. I'll look into that if I can't figure out anything else. I guess what I really want to know is how does the whole send/receive thing affect the callback. When its explained in the reference the callback really isn't considered. It just assumes you're using the built in reactions and that it.

#3 I agree that using triggers may be your best option depending on what you're trying to accomplish. But if the two objects you're tracking need to be movable sprites then triggers are not going to be the best choice.

If it's simply the physics that you're wanting to eliminate (i.e., CLAMP, BOUNCE, etc) but you still want the callback, then set your response mode as:

collisionResponseMode = "CUSTOM";

This will prevent any physics from taking place and allow you to handle the reaction as you wish be it with movement or just a specific function call. For example, the game I'm currently working on uses a custom response mode for every object in the scene because I don't need or want any of the standard responses.

If this isn't what you're trying to accomplish, explain in more detail and I'm sure I (or someone else) can clear it up for you.

#4 Actually I only need one of the objects to move so triggers might be the way to go. However, I forgot that the response mode could be set to custom. So that might be what I needed. I try it out and put it here if it works for me. Thanks!

-Peter

#5 I don't think that a custom response mode will work since I want the moving object to use the clamp mode by default for other objects. I've been looking into triggers and they really look like the way to go for me. Is there a good example of triggers in one of the demos?

-Peter

#6 @Peter, no, I don't believe there is.

Triggers are fairly simple, they have three callbacks onEnter, onLeave and onStay (not sure if OnStay is the name of it though, check the references)

You simply code the callbacks you want to acknowledge, and perform your logic in there.

#7 Can I choose which objects can activate the trigger, like with the layer or group masks?

#8 Not sure, but you can check the objects when they enter the trigger and decide to ignore them if you want.

#9 Yes, you can mask what activates the trigger, the same exact way you can mask what other objects collide with each other.

What I often do is to create a trigger that I mount to my sprites that lets them know before they run into other things -- this lets them know what's close to them, what they can attack, etc.

#10 That sounds like a great method, Clint. I'm using triggers now and they work great. Does anyone know if they're lighter on the system then the collision engine? They should be, right? They work as a great alternative to collisions if you don't need something so exact and you want custom responses anyway. One thing I should mention that I learned before I masked the triggers, once an object enters the trigger, no other object will cause an onEnter callback until the first object leaves. So triggers work like a floor switch I guess (for those of you who compare everything with old RPGs). This behavior is great if you mask everything right. Anyway, I'm really happy with triggers and would suggest them to anyone who needs a light alternative to collisions.

-Peter

#11 I would imagine that triggers use the same collision code that regular collisions use, the only difference being that it doesn't have a custom polygon assigned to it --

I see no reason why the trigger would have different code, 'onEnter' -is- a collision ... and I would actually think that triggers use more calcs that collisions since collisions don't check to see if the object is 'entering', 'staying' or 'leaving' ... collisions would just register the 'staying' method and call it 'onCollision'.

So, I would not call triggers a light-weight solution to collisions ...

If your looking for a 'light-weight early collision detection' ... I would think that an invisible scene-object with 'full' collision set to a scaled size larger then your actual object, and mounted to it ... would be less CPU Intensive then a trigger.

Triggers give the ability to check if something is 'entering' and 'leaving' a specified area though ... which is great for doing many many things ... but calling them a light-weight alternative to collisions, I believe is incorrect.

Granted, I could be wrong, and I just woke up ... so I might not be thinking all too clearly, but without looking at the C++ I'd have to assume that the triggers use the same collision detection that regular collisions use, but they simply extend (add onto it) by keeping track of the 'enter' and 'leave' states as well as the simple 'object is touching me' code.

#12 Yes, but collisions make several passes right? So triggers could just use the first pass where the engine tests with rects. But I don't really know. You're guess is as good as mine.

#13 Triggers can have collision poly's just like other t2dSceneObjects can ... so, the 'test with rects' concept is most likely incorrect since you can create an octagonal trigger ...

I just reviewed the code for t2dTrigger.h/cc and the 'onCollision' callback simply overrides the t2dSceneObject 'onCollision' callback which actually performs the TorqueScript "onCollision" call ... ie; Triggers do not generate 'onCollision' callbacks when a collision is found, instead, it simple adds the object to a 'colliders' stack, then at a later point sifts through the stack and generates 'onEnter', 'onLeave' etc callbacks ...

So ... using triggers instead of objects, makes no difference in actual performance, from what I just saw in the code after like 2 minutes of browsing ...

#14 Thanks David. I didn't know that triggers could use collision poly's. That's pretty cool. So yeah, I guess that means that they aren't really lighter after all. I guess you could say they're just a different kind of collision. Nifty.

#15 I too have had a few problems recently regarding this in the collision/physics system. I would like to know more about what Dennis Harrington is referring to with the collisionResponseMode property, as I cannot find a way to achieve the effect he is speaking of. When I set this property to "CUSTOM" in the level file, it still restricts the movements of my character.

This may be unrelated, but I have been unable to get any of the other non-default collisionResponseMode properties to work either aside from Kill. Just another piece of information for those who might know my problem.

In my game, I am attempting to make a collectible that will pass through the character, but will not be obtained unless the player is holding a certain key. Am I going about this the wrong way?

Thanks.

#16 @Sean: I'm not 100 percent sure what you're trying to achieve but it sounds like you need the collectible item to send you a callback when it collides with the player. From there you can then determine whether or not the player is in the correct state to obtain it. Is that correct?

If so, then you'd want to set the Send/Receive Physics properties on the collectible to off and also set the response mode to custom as well as enabling collisions and a callback. Then you could just do a quick little test in the callback to verify if the player should obtain the item or not.

Let me know if you need a specific example and I can post back or if I've totally missed what you're looking for.

#17 @Dennis: Yes, I believe you understand what I'm trying to do. It shouldn't be any harder than a normal collectible, just an addition of the conditional statement testing for a keypress.

However, I have already tried the method you described here (and tested it again just now to be sure), and still the player object will not pass through the collectible. Both of the physics properties are not checked, and the collision and callback are enabled, yet it appears to make no difference. If either of the collision properties are checked, it will block my character's motion. If they are disabled, the character will pass through the object, but of course nothing is then returned as a collision.

I'm not sure what the problem could be. I'm running TGB v1.1.3, if that's of any help.

#18 I have a collision test project that I use whenever I have collision issues in TGB since it's sometimes helpful to have a totally clean project to do tests of this sort to verify functionality. So I've modified it slightly in order to test this scenario and everything worked as it should.

I've also zipped up the project folder so you can test it for yourself and verify that all of your settings are similiar. However, I just realized that you literally meant the player is "holding a key". LOL, I thought you meant that the game character had a "key" and my example reflects that. I added a dynamic field to the player called hasKey that can be set to 0 or 1 to change whether or not the objects will pass through each other or whether the collectible will dissappear. However, the logic is the same. You'd want to set a flag when the player holds down a key and clear it when he lets the key up. That would function the same as the hasKey property I'm using here.

In any event, here's the project. Just extract it to the games folder in the TGB directory. Just change the playerShip's hasKey property to 0 if you want to simulate the user NOT holding a key and you'll see that the sprites pass through each other.

Let me know if this doesn't make sense or if you have any other problems.

#19 Lol, I can see how you made that mistake. I could have been a tad clearer. ;)

Anyway, I tried your program and it worked for the most part, with the object passing through the ship when that flag is toggled. However, I noticed that the ship did not have any physics affecting it, and our character needs these properties enabled. When I activated the physics for the ship sprite, it simply runs into the collectible and then proceeds to be pushed to the left by it.

How are collectibles normally done in TGB with a physics-enabled character?

Thanks for your help.

#20 Ah, I see what you're saying. Hmm, I can't get that to function properly either. As a workaround the approach I would take would be to disable collisions for the collectible if the user is not holding the key since you shouldn't have to be checking for it anymore, right?

So you can set this property like this:

%dstObj.setCollisionActive(0,0);

So in the onCollision function for the playerShip the code would be:

if(%dstObj.class $= "collectible") {
      if(%srcObj.hasKey) {
         echo("collectable taken");
         %dstObj.safeDelete();
      } else {
         echo("no key");
         %dstObj.setCollisionActive(0,0);
      }
   }

Now if you need to continue to check for the collectible colliding with the player then of course, this won't work.