Sensors and Triggers
by Kyle Harrison · in Torque 2D Beginner · 08/04/2014 (11:56 pm) · 39 replies
Ok, I've been spending way too much time on this and im reaching out for some help on this issue.
I'm using Torque2D 3.0, and I'm developing an Android game right this second.
I'm trying to setup a standard Trigger (or Sensor) that has the behaviour of when an object (Sprite ScenObject with a PolygonBoxCollisionShape) enters the Trigger object's space (or a ShapeVector SceneObject with a Sensor collision flag):
1. Physics do NOT happen
2. Callbacks are triggered on collision
The problem I have here is one of two scenarios:
1. With %myTrigger.Active set to true AND/OR CollisionShapeIsSensor set to false (or both properties ignored entirely), my Sprite SceneObject is being "pushed away" by the Trigger SceneObject as if it were a solid thing, BUT the Trigger or standard Collision callbacks (depending on the type of object) get triggered, and therefore allows my game to continue normally, but looks extremely awkward and horrible
(Demonstration of this effect: https://www.youtube.com/watch?v=W68IO6szjJw [placeholder graphics])
or
2. With %myTrigger.Active set to false AND/OR CollisionShapeIsSensor set to true, my Sprite and Trigger SceneObjects no longer push eachother away, but NONE of the collision callbacks ever get called. Therefore the game just ends immediately.
The gameplay is super simple at play: stay within the Trigger zone until a certain moment, as you enter or leave the trigger/sensor zone a global flag is set whether your safe or not. when that moment arrives to evaluate that flag and determins that you are safe, the Trigger/Sensor object and some visual elements are removed and respawned somewhere else, else end the game.
Everything I try, I get one of those two results. Either the game plays correctly (can enter the trigger zone with no resistance) but collisions never get triggered, OR the game has physics enabled and works against each-other but the collisions "kinda" work
Not sure how to proceed
I'm using Torque2D 3.0, and I'm developing an Android game right this second.
I'm trying to setup a standard Trigger (or Sensor) that has the behaviour of when an object (Sprite ScenObject with a PolygonBoxCollisionShape) enters the Trigger object's space (or a ShapeVector SceneObject with a Sensor collision flag):
1. Physics do NOT happen
2. Callbacks are triggered on collision
The problem I have here is one of two scenarios:
1. With %myTrigger.Active set to true AND/OR CollisionShapeIsSensor set to false (or both properties ignored entirely), my Sprite SceneObject is being "pushed away" by the Trigger SceneObject as if it were a solid thing, BUT the Trigger or standard Collision callbacks (depending on the type of object) get triggered, and therefore allows my game to continue normally, but looks extremely awkward and horrible
(Demonstration of this effect: https://www.youtube.com/watch?v=W68IO6szjJw [placeholder graphics])
or
2. With %myTrigger.Active set to false AND/OR CollisionShapeIsSensor set to true, my Sprite and Trigger SceneObjects no longer push eachother away, but NONE of the collision callbacks ever get called. Therefore the game just ends immediately.
The gameplay is super simple at play: stay within the Trigger zone until a certain moment, as you enter or leave the trigger/sensor zone a global flag is set whether your safe or not. when that moment arrives to evaluate that flag and determins that you are safe, the Trigger/Sensor object and some visual elements are removed and respawned somewhere else, else end the game.
Everything I try, I get one of those two results. Either the game plays correctly (can enter the trigger zone with no resistance) but collisions never get triggered, OR the game has physics enabled and works against each-other but the collisions "kinda" work
Not sure how to proceed
function spawnBird(%x, %y)
{
%sprBird = new Sprite(BirdPawn);
%sprBird.Position = %x SPC %y;
//%sprBird.setBodyType( static );
%sprBird.Image = "Bird:Bird";
%sprBird.Size = "7 8";
%sprBird.createPolygonBoxCollisionShape();
%sprBird.SceneGroup = 10;
myScene.add(%sprBird);
$birdObj = %sprBird;
}
function spawnWindow()
{
$SceneObjects[0] = null;
$SceneObjects[1] = null;
$windowActive = true;
// Purely aesthetic, a clear "window" is drawn, to be able to "fly through"
%window = new ShapeVector(Window);
%randomX = getRandom(-30, 30);
%randomY = getRandom(-30, 30);
%window.setPosition(%randomX SPC %randomY);
%window.setSize(0.1);
%window.setLineColor("0.5 1 1 1");
%window.setFillColor("0.5 1 1 0.5");
%window.setFillMode(true);
%window.setPolyPrimitive(4);
%window.setSceneGroup(4);
$SceneObjects[0] = %window;
myScene.add(%window);
// This should act as the implicit shape that the window ends up being at the time of the
// evaluation (size 20)
%trigger = new Trigger(WindowTrigger);
%trigger.setEnterCallback(true);
%trigger.setLeaveCallback(true);
%trigger.setPosition(%randomX SPC %randomY);
%trigger.setSize(20);
%index2 = %trigger.createPolygonBoxCollisionShape();
%trigger.setCollisionShapeDensity(%index2, 0);
%trigger.setCollisionShapeFriction(%index2, 0);
$SceneObjects[1] = %trigger;
myScene.add(%trigger);
}
/////////////////
//// This works only when the Trigger acts as a physics object.
//// That should not be...
/////////////////
function WindowTrigger::onEnter(%this, %object)
{
echo("================= OH EM GEE IT WORKS");
$inWindow = true;
}
function WindowTrigger::onLeave(%this, %object)
{
echo("================= HEY NO GET BACK HERE!");
$inWindow = false;
}
function Window::update(%this)
{
//echo("IN Window:" SPC $inWindow);
if(%this.getSize() < 20) {
%this.setSize(%this.getSize() + $speed);
} else {
// do evaluation check
if($inWindow) {
$windowActive = false;
$inWindow = false;
$score++;
echo("Score:" SPC $score);
if($score <= 3) {
$speed = 0.2;
} else if($score <= 6) {
$speed = 0.4;
} else if($score <= 8) {
$speed = 0.7;
} else if($score <= 10) {
$speed = 1.0;
} else if($score > 10) {
$speed = 2.0;
}
$SceneObjects0.safedelete();
$SceneObjects1.safedelete();
} else {
$gameState = "death";
}
}
}
#2
Thank you so much for a quick reply
In response to your first point: I understand that's how Torque wants to work, and that's fine, I get that. My initial headspace was like Flash with a standard HitTest Collision, where the only thing that happens is a callback. Once I got over myself on that, I tried both setting the collision shape as a Sensor, which disabled the callbacks entirely. Setting Active to false disabled the callbacks entirely.
Then I found "Trigger", which ALL the documentation told me was exactly what I wanted out of setting the original objects collision shape as a Sensor: I wanted a Trigger Brush, something that won't be treated as a "physical object" on the stage but has collision detection. So I disabled all the collision shapes for the original object (Window) so the Bird can pass through, then I set up the Trigger object (WindowTrigger) expecting that it would allow the Bird to still pass through (like a Trigger should) but enable collision callbacks so I can set my global flags.
But as you can see in my video, even the Trigger (which is invisible, not the blue thing) is reacting like a physical object.
Why? Does that not go against everything a Trigger should be?
I should be able to create scene objects that are invisible and have no physical capacity to affect the game world objects (aka: a Trigger)
I have not yet tried CollisionSuppress, but I have a sneaking suspicion im going to get behaviour behaviour 2: no callbacks will be triggered. But I will give it a shot.
*whew*
The global SceneObjects is just a quick hack at the moment while I figure out the collisions problem. It's definitely not a good implementation, and will be corrected when I can put my attention to it. I just needed something to clean up the two important objects without spending too much time on it. I use an implementation of getCount() and getObject() in main.cs which manages all the objects in the scene :)
I will continue trying out some things based on your response.
But.. it's not possible this is an Android specific bug is it??
edit
I grabbed your implementation verbatim , here were the results:
http://youtu.be/08fZZ1LWJ8Y
08/05/2014 (8:45 am)
Hi Simon!Thank you so much for a quick reply
In response to your first point: I understand that's how Torque wants to work, and that's fine, I get that. My initial headspace was like Flash with a standard HitTest Collision, where the only thing that happens is a callback. Once I got over myself on that, I tried both setting the collision shape as a Sensor, which disabled the callbacks entirely. Setting Active to false disabled the callbacks entirely.
Then I found "Trigger", which ALL the documentation told me was exactly what I wanted out of setting the original objects collision shape as a Sensor: I wanted a Trigger Brush, something that won't be treated as a "physical object" on the stage but has collision detection. So I disabled all the collision shapes for the original object (Window) so the Bird can pass through, then I set up the Trigger object (WindowTrigger) expecting that it would allow the Bird to still pass through (like a Trigger should) but enable collision callbacks so I can set my global flags.
But as you can see in my video, even the Trigger (which is invisible, not the blue thing) is reacting like a physical object.
Why? Does that not go against everything a Trigger should be?
I should be able to create scene objects that are invisible and have no physical capacity to affect the game world objects (aka: a Trigger)
I have not yet tried CollisionSuppress, but I have a sneaking suspicion im going to get behaviour behaviour 2: no callbacks will be triggered. But I will give it a shot.
*whew*
The global SceneObjects is just a quick hack at the moment while I figure out the collisions problem. It's definitely not a good implementation, and will be corrected when I can put my attention to it. I just needed something to clean up the two important objects without spending too much time on it. I use an implementation of getCount() and getObject() in main.cs which manages all the objects in the scene :)
I will continue trying out some things based on your response.
But.. it's not possible this is an Android specific bug is it??
edit
I grabbed your implementation verbatim , here were the results:
http://youtu.be/08fZZ1LWJ8Y
#3
Edit : Obviously not since you modify the code afterwards. I guess the onEnter, onLeave callbacks still don't work?
08/05/2014 (9:30 am)
Erm. not sure what result you're trying to get exactly? From what I understand the first test run in your video does what it's supposed to do, no?Edit : Obviously not since you modify the code afterwards. I guess the onEnter, onLeave callbacks still don't work?
#4
08/05/2014 (9:53 am)
What does it do in Windows? If it behaves as expected in Windows but not in Android then it's likely that something is different in the Android environment that needs to be addressed....
#5
Yeah, that's exactly what's going on. The onEnter and onLeave callbacks get completely ignored.
haha, I COULD have elaborated on what's supposed to be going on (chalk it up to frustration in that I'm not thinking too clearly)
The bird isn't supposed to disappear if "inside of the blue square". These are supposed to represent windows that you "fly through" (The game is supposed to be looking behind the bird, not to the side. The graphic is insanely misleading and only represents a placeholder whilst I worked out the gameplay), while the rest of the stage represents a big ol' wall that you will "crash into" if not within the vicinity of a window. I'm relying super heavy on Trigger Brushes/zones to drive the core gameplay experience here, and Torque's collision system has made my life a living nightmare so far.
@Richard
I haven't tried this on Windows no, the original executable is still running the Toybox Modules. I will attempt this when I get home. I hadn't thought of doing this, as to me (on the outside looking in) it's the same instance of Torque interpreting TorqueScript the same way, just running on a different platform. Is there platform specific discrepancies between how TorqueScript is interpreted? (I mean, outside of enabling Touch specific actions)
08/05/2014 (10:03 am)
@SimonYeah, that's exactly what's going on. The onEnter and onLeave callbacks get completely ignored.
haha, I COULD have elaborated on what's supposed to be going on (chalk it up to frustration in that I'm not thinking too clearly)
The bird isn't supposed to disappear if "inside of the blue square". These are supposed to represent windows that you "fly through" (The game is supposed to be looking behind the bird, not to the side. The graphic is insanely misleading and only represents a placeholder whilst I worked out the gameplay), while the rest of the stage represents a big ol' wall that you will "crash into" if not within the vicinity of a window. I'm relying super heavy on Trigger Brushes/zones to drive the core gameplay experience here, and Torque's collision system has made my life a living nightmare so far.
@Richard
I haven't tried this on Windows no, the original executable is still running the Toybox Modules. I will attempt this when I get home. I hadn't thought of doing this, as to me (on the outside looking in) it's the same instance of Torque interpreting TorqueScript the same way, just running on a different platform. Is there platform specific discrepancies between how TorqueScript is interpreted? (I mean, outside of enabling Touch specific actions)
#6
08/05/2014 (11:44 am)
Not in how TorqueScript is interpreted, but there may be differences in internal implementations between different operating systems. In other words, calling alxPlay() to play a sound "means" the same thing regardless of which OS you're on, but the OS may handle some things differently - resulting in different behavior. The very essence of why we have to port software between different platforms....
#7
The only thing I see might be that the createPolygonBoxCollisionShape function will require you to specify a width and height. If your Trigger had an Image, it would automatically size itself to the image size but in the current case, I think your trigger is of size 0!
Android implementation of Box2D should be the same as the other platforms' just as OpenAL is.
08/05/2014 (12:00 pm)
@Kyle : The only thing I see might be that the createPolygonBoxCollisionShape function will require you to specify a width and height. If your Trigger had an Image, it would automatically size itself to the image size but in the current case, I think your trigger is of size 0!
Android implementation of Box2D should be the same as the other platforms' just as OpenAL is.
#8
Just to help clear up a few things. Sensors are a property of collision shapes. Any scene object can be a sensor - a Sprite, ImageFont, Trigger, SceneObject, etc. A Trigger is nothing more than a glorified SceneObject that has a few additional callbacks available for onEnter, onStay, and onLeave. For a Trigger to work properly - it absolutely needs an active collision shape assigned to it. To prevent a physics response but to still allow a callback response, a collision shape needs to be made a sensor.
It's a bit difficult to see from the video, I'll have to try watching them again a few times - but turning on the collision shape debug mode to show the shapes would help. If a sensor is resulting in a physics response, then something is wrong in the engine somewhere.
08/05/2014 (12:31 pm)
@Simon - the collision shape sizes itself to the size of the AABB, it is not related to an image.Just to help clear up a few things. Sensors are a property of collision shapes. Any scene object can be a sensor - a Sprite, ImageFont, Trigger, SceneObject, etc. A Trigger is nothing more than a glorified SceneObject that has a few additional callbacks available for onEnter, onStay, and onLeave. For a Trigger to work properly - it absolutely needs an active collision shape assigned to it. To prevent a physics response but to still allow a callback response, a collision shape needs to be made a sensor.
It's a bit difficult to see from the video, I'll have to try watching them again a few times - but turning on the collision shape debug mode to show the shapes would help. If a sensor is resulting in a physics response, then something is wrong in the engine somewhere.
#9
08/05/2014 (12:46 pm)
@Mike : Well goshdarn, you are right.
#10
I can understand what you mean, but the actual Trigger itself has the correct dimensions to it. I can tell because the moment the bird icon gets anywhere close to what the resulting blue windows size will end up being, the bird icon starts freaking out trying to get to the spot but the Trigger wont let it, constantly pushing it away.
All im trying to do here, is exactly how a regular old Trigger Brush would be implemented. Pretend this is a sidescrolling game for a moment. Your running to the right, and then when you get to a certain spot you want to spawn in an enemy. You'd do this by having an invisible Trigger brush/entity/sceneobject/whatever-you-want-to-call-it that your player can seamlessly go in and out of without interference, and then the first time the onEnter callback is called, you spawn the enemy and set a game flag that says you've already spawned this enemy, do not spawn more.
That "Trigger" is extremely traditional in event driven games, and I stand here refusing to believe that something with as much history as Torque would allow their dedicated Trigger SceneObject to behave the way it's behaving in my app (allowing it to physically affect other SceneObjects just by being in the scene)
Between this: http://docs.garagegames.com/tgb/official/content/documentation/Game%20Builder/Tr...
and
https://github.com/GarageGames/Torque2D/wiki/Trigger-Guide
It's practically telling me and showing me that this is exactly what im looking for, and exactly what I want to use. But when implemented, acts just like it's standard physics object that can't be rendered to screen.
08/05/2014 (12:52 pm)
@SimonI can understand what you mean, but the actual Trigger itself has the correct dimensions to it. I can tell because the moment the bird icon gets anywhere close to what the resulting blue windows size will end up being, the bird icon starts freaking out trying to get to the spot but the Trigger wont let it, constantly pushing it away.
All im trying to do here, is exactly how a regular old Trigger Brush would be implemented. Pretend this is a sidescrolling game for a moment. Your running to the right, and then when you get to a certain spot you want to spawn in an enemy. You'd do this by having an invisible Trigger brush/entity/sceneobject/whatever-you-want-to-call-it that your player can seamlessly go in and out of without interference, and then the first time the onEnter callback is called, you spawn the enemy and set a game flag that says you've already spawned this enemy, do not spawn more.
That "Trigger" is extremely traditional in event driven games, and I stand here refusing to believe that something with as much history as Torque would allow their dedicated Trigger SceneObject to behave the way it's behaving in my app (allowing it to physically affect other SceneObjects just by being in the scene)
Between this: http://docs.garagegames.com/tgb/official/content/documentation/Game%20Builder/Tr...
and
https://github.com/GarageGames/Torque2D/wiki/Trigger-Guide
It's practically telling me and showing me that this is exactly what im looking for, and exactly what I want to use. But when implemented, acts just like it's standard physics object that can't be rendered to screen.
#11
Thank you SO MUCH for the sanity check! The moment I saw "CollisionIsSensor" stuff, I knew exactly that that's what needed to be done. But when the callbacks (especially the special callbacks for the Trigger SceneObject) wern't being called when setting the collision shapes as sensor, I was starting to lose my mind! spending hours upon hours just tweaking values and trying little hacks and things everywhere. I've now spent countless days from the moment I get home from work in front of this tiny little torque script trying to get this stuff working until 3 or 4 in the morning...
How does one turn on the debug lines? That would help me a LOT in visualizing what's going on...
That said, a Sensor isn't eliciting a physics response. That parts working fine. The problem being is that when a collision shape is set to be a sensor (like my Trigger), the callbacks NEVER get called
08/05/2014 (12:59 pm)
@MikeThank you SO MUCH for the sanity check! The moment I saw "CollisionIsSensor" stuff, I knew exactly that that's what needed to be done. But when the callbacks (especially the special callbacks for the Trigger SceneObject) wern't being called when setting the collision shapes as sensor, I was starting to lose my mind! spending hours upon hours just tweaking values and trying little hacks and things everywhere. I've now spent countless days from the moment I get home from work in front of this tiny little torque script trying to get this stuff working until 3 or 4 in the morning...
How does one turn on the debug lines? That would help me a LOT in visualizing what's going on...
That said, a Sensor isn't eliciting a physics response. That parts working fine. The problem being is that when a collision shape is set to be a sensor (like my Trigger), the callbacks NEVER get called
#12
To turn on Debug modes, type in
08/05/2014 (1:02 pm)
I wish I could help you more but it works as expected on my PC with the script provided before.To turn on Debug modes, type in
Scene.setDebugOn("fps collision AABB joints");and setDebugOff will turn off the specified Debug modes.
#13
I'm also curious to see how it responds in Windows. I wish I had thought of that before.
But the problem with that, if it's an Android specific bug.. this is the platform I've been commissioned to build this game on (exclusively), how fast is the turnaround for bugs like this? (if it is a bug)
08/05/2014 (1:04 pm)
Thank you @Simon! I'm stoked to try this out. I'm also curious to see how it responds in Windows. I wish I had thought of that before.
But the problem with that, if it's an Android specific bug.. this is the platform I've been commissioned to build this game on (exclusively), how fast is the turnaround for bugs like this? (if it is a bug)
#14
But the intent was for the new Trigger to behave essentially the same way as the old t2dTrigger.
I'm starting to think that the Trigger should just create and maintain its own collision shape. So you just size the Trigger and it re-creates it's collision shape - and forces it to a sensor while we're at it. It shouldn't be necessary to fiddle with it. While destroying and creating collision shapes is a relatively expensive operation it shouldn't matter for most cases in this application.
08/05/2014 (1:12 pm)
As a historical note, I'd like to point out that there is almost no actual relation between the t2dTrigger object from TGB and the Trigger object in T2D. The new Trigger object was actually added because the Three Step Studio team asked for it - we were wanting some built-in stuff that was removed when the t2dTrigger object went out the window (during the transition from TGB's simple physics to Box2D). I think the only thing that they really have in common is that they are both descended from SceneObject....But the intent was for the new Trigger to behave essentially the same way as the old t2dTrigger.
I'm starting to think that the Trigger should just create and maintain its own collision shape. So you just size the Trigger and it re-creates it's collision shape - and forces it to a sensor while we're at it. It shouldn't be necessary to fiddle with it. While destroying and creating collision shapes is a relatively expensive operation it shouldn't matter for most cases in this application.
#15
Honestly, to me, it would make a ton of sense to me to have the Trigger SceneObject manage it's own collision shape (based on itself), and automatically be a sensor. Otherwise why are you using a Trigger, right? If your building something like a Coin pickup, you'd probably want a Sprite SceneObject with a manual sensor collision shape instead (Just a guess, this project being my first project, but that'd how I'd imagine you'd want something like a pickup item built)
08/05/2014 (1:21 pm)
@RichardHonestly, to me, it would make a ton of sense to me to have the Trigger SceneObject manage it's own collision shape (based on itself), and automatically be a sensor. Otherwise why are you using a Trigger, right? If your building something like a Coin pickup, you'd probably want a Sprite SceneObject with a manual sensor collision shape instead (Just a guess, this project being my first project, but that'd how I'd imagine you'd want something like a pickup item built)
#16
08/05/2014 (1:43 pm)
Yeah, and just tell it what shape to use - rect to match its own area, circle to inscribe its area.
#17
Also a comment to the trigger managing its own shape discussion - one thing to keep in mind with Box2D is that all objects can have multiple collision shapes attached to them. The shape(s) don't even have to be inside the bounding box of the object - you can create some pretty strange overall shapes using multiple collision shapes if needed. Limiting a trigger to just a single rectangle or circle would be a bit of a downgrade in that respect.
08/05/2014 (3:01 pm)
Just for info, I modified the MoveTo toy by adding the WindowTrigger code plus onEnter and onLeave callbacks, and creating a collision shape on one of the crosshairs. Everything works fine with triggers on OSX - it's set as a sensor so there's no physics response but the callbacks get fired off as they should.Also a comment to the trigger managing its own shape discussion - one thing to keep in mind with Box2D is that all objects can have multiple collision shapes attached to them. The shape(s) don't even have to be inside the bounding box of the object - you can create some pretty strange overall shapes using multiple collision shapes if needed. Limiting a trigger to just a single rectangle or circle would be a bit of a downgrade in that respect.
#18
I suppose that since the default behavior is to make the collision shape a box that matches the object's size on creation it is probably sufficient in that respect. I don't know - the original t2dTrigger was very simple, either a box or circle that matched its scene size. This simple behavior is usually sufficient for triggers.
Maybe I'll fiddle with this course and see how it feels. I'll share it when I get it figured out and everyone can decide if they like it or not.
08/05/2014 (3:14 pm)
As a compromise, how about a SimpleTrigger child of Trigger (and no jokes about "slow children at play")? I think that the majority of triggers will not be complex/multi shapes, but you never know. Still, if all collision shapes associated with a Trigger are forced to sensor that would help as well. That way they don't mistakenly become "solid."I suppose that since the default behavior is to make the collision shape a box that matches the object's size on creation it is probably sufficient in that respect. I don't know - the original t2dTrigger was very simple, either a box or circle that matched its scene size. This simple behavior is usually sufficient for triggers.
Maybe I'll fiddle with this course and see how it feels. I'll share it when I get it figured out and everyone can decide if they like it or not.
#19
So I grabbed my compilers/android/assets/modules folder and pasted it in my root t2d folder, and ran the windows executable.
Im happy to say that the conversion happened nicely.
Except that the problem is happening here too. So it's not an android thing.
However, I AM in a position at the moment to provide a small download containing all my torquescript for the game, in an effort to try and get this thing resolved.
https://dl.dropboxusercontent.com/u/16000224/modules.zip
I warn that the code may be a little unconventional though (but it IS small so there shouldn't be a whole lot to wade through), but if there's something I'm doing that's causing this, it's a problem that needs to be fixed
08/05/2014 (10:48 pm)
Hey GuysSo I grabbed my compilers/android/assets/modules folder and pasted it in my root t2d folder, and ran the windows executable.
Im happy to say that the conversion happened nicely.
Except that the problem is happening here too. So it's not an android thing.
However, I AM in a position at the moment to provide a small download containing all my torquescript for the game, in an effort to try and get this thing resolved.
https://dl.dropboxusercontent.com/u/16000224/modules.zip
I warn that the code may be a little unconventional though (but it IS small so there shouldn't be a whole lot to wade through), but if there's something I'm doing that's causing this, it's a problem that needs to be fixed
#20
@Kyle - thanks for posting a module, that is the best way for us to help you. I quickly ran it on my Mac, and I see the same problem happening as well. So it's probably something with your script. I will dive into it when I get the chance.
08/05/2014 (11:16 pm)
@Richard - I agree, most use cases for trigger will probably be a simple rect or circle shape. It would make the class slightly more complicated, but perhaps have what you propose be the standard behavior and then add some sort of "explicit mode" where you have the ability to kill the default sensor shape and can then build custom collision shapes just like you can now with the object.@Kyle - thanks for posting a module, that is the best way for us to help you. I quickly ran it on my Mac, and I see the same problem happening as well. So it's probably something with your script. I will dive into it when I get the chance.
Associate Simon Love
A few points of note, however.
1- Box2D physics are integral to how the engine calculates positioning, velocities and contacts. There is no way to bypass it. Doing so would imply having a secondary engine to calculate how shapes overlap, which would be a tad innefficient.
2- The best way to ignore collisions so that objects do not bounce off each other is to call Sceneobject.setCollisionSuppress(true). An alternative would also be to disable the onEnter, onLeave callbacks by calling %trigger.setEnterCallback(false);.
At all times, the trigger would have its Active and isSensor properties set to true.
Bonus
You also have an "onStay" callback which will be triggered every tick when an object has entered the trigger until it leaves.
Using global variables to keep track of sceneobjects ($SceneObjects[0]) works but I don't know why you would go about it in such a way. Your objects already have object names ( WindowTrigger, Window, BirdPawn )which identifies them throughout your code.
You could also use Scene.getCount(); and Scene.getObject(%i); or add the objects to a Simset.
Bear in mind that these are only suggestions based on personal preference. As long as it works, it's a valid way to do it!