Trigger overlaping other shapes prevents colisions from those shapes
by David Ezell · in Torque Game Builder · 03/18/2009 (9:40 am) · 10 replies
Example:
A player object is inside a triger that overlaps other objects that the player should colide with.
Moving into one of these objects, the player will penetrate up to the edge of the trigger more or less, and the collision between player and the object will not be processed.
A player object is inside a triger that overlaps other objects that the player should colide with.
Moving into one of these objects, the player will penetrate up to the edge of the trigger more or less, and the collision between player and the object will not be processed.
#2
--
Unfortunately for me, my project requires extensive use of triggers placed very close to "solid" objects.
--
If I find a work around I'll be sure to post it here. If anyone else has any suggestions as to a work around I'm all ears.
03/19/2009 (4:53 am)
That old bug does sound very similar.--
Unfortunately for me, my project requires extensive use of triggers placed very close to "solid" objects.
--
If I find a work around I'll be sure to post it here. If anyone else has any suggestions as to a work around I'm all ears.
#3
Think of the triggers as "spiritual force" while the object that interacts with the trigger as the "spirit". Normal everyday "bodies" can't interact with either.
03/22/2009 (12:21 pm)
Use differing graph groups for triggers and the objects inside them. Also create another object of the same graph group of the trigger that is linked to the object. Messy, but it gets the job done.Think of the triggers as "spiritual force" while the object that interacts with the trigger as the "spirit". Normal everyday "bodies" can't interact with either.
#4
Thanks for the suggestion :)
03/24/2009 (7:00 pm)
That is kind of grotesque Eric, but it may actually be better. Hitting these triggers is a good thing for the player, so having a larger collision area for that vs staby objects, and obstructions would be nice.Thanks for the suggestion :)
#5
This wouldn't be a problem but if you are overlapping an object, then that occurs at zero-time and so always "wins". Again, this is fine until you consider that the t2dTriggers are an oddity in that you expect to overlap them but you don't really want them to "win" in the collision-detection game.
In this sense, they're like a "special" collision that should still be processed as a priority but should not exclude the next in line.
I have already looked at this problem and am thinking about modifying the procedure for the "special" case where you collide with a t2dTrigger at zero-time (or first non-zero time). The new procedure will be to process the trigger but continue processing up the collision-chain until a non-t2dTrigger is found, at which point, the original procedure applies.
This change should result in t2dTriggers not absorbing collisions.
Ref: TGB-296
05/22/2009 (5:28 am)
The way the collision works is kind of complicated and hard to summarise but essentially, when an object sends collisions, it will result in a series of potentials which are reduced down to a set of actuals. The system then determines which one will occur first in time then process that one.This wouldn't be a problem but if you are overlapping an object, then that occurs at zero-time and so always "wins". Again, this is fine until you consider that the t2dTriggers are an oddity in that you expect to overlap them but you don't really want them to "win" in the collision-detection game.
In this sense, they're like a "special" collision that should still be processed as a priority but should not exclude the next in line.
I have already looked at this problem and am thinking about modifying the procedure for the "special" case where you collide with a t2dTrigger at zero-time (or first non-zero time). The new procedure will be to process the trigger but continue processing up the collision-chain until a non-t2dTrigger is found, at which point, the original procedure applies.
This change should result in t2dTriggers not absorbing collisions.
Ref: TGB-296
#6
I just wanted to add that this problem was because of the reason I highlighted above in that overlaps get a high priority (for obvious reasons) and only a single object is processed each iteration.
Ref: TGB-296
06/18/2009 (6:15 am)
This problem has been resolved and will be in the next release.I just wanted to add that this problem was because of the reason I highlighted above in that overlaps get a high priority (for obvious reasons) and only a single object is processed each iteration.
Ref: TGB-296
#7
07/02/2009 (7:36 am)
Thanks Melv. Great news that this is resolved! Is there any timeline when the fixed version will be available to us? We have a game coming out in about 6 weeks and could use this. 
#9
07/24/2009 (12:56 am)
A work around that may work is using a proxy sceneobject (sprite using a transparent png) with the collision boundary set how you need it. Then use it's collision callbacks. Not sure if this implementation would have the same issues as the trigger or not but would be easy to test to see. 
#10
Also triggers within triggers also are ignored.
Could we have an option in the trigger to say always process other objects or something?.
Can you point me in the right direction of where to start looking for the code to alter. Its been a long time since I did C++, but this is something I realy need for my latest behavior for lightmap blending.
05/01/2011 (10:45 am)
This still seems to be a problem in TGB 1.7.5Also triggers within triggers also are ignored.
Could we have an option in the trigger to say always process other objects or something?.
Can you point me in the right direction of where to start looking for the code to alter. Its been a long time since I did C++, but this is something I realy need for my latest behavior for lightmap blending.
Associate William Lee Sims
Machine Code Games
www.garagegames.com/community/forums/viewthread/46138
Must have reared its ugly head again.