T3D MIT Trigger Bug
by Jack Stone · in Torque 3D Professional · 01/21/2014 (7:53 pm) · 25 replies
I am having some unusual problems with the Triggers in the current release of T3D MIT.
When creating triggers in the mission editor as usual, only some of them are working. My triggers are all the exact same, with the exception of the position. Same datablock, same scale values, etc etc.
I have six triggers in the level, and I can only get four of them to work, at best.
Implementing the fix described here: (in post 4)
https://www.garagegames.com/community/forums/viewthread/135658
Did nothing until I also made the same change in the "ConsoleSetType" function here:
This cause the two triggers that were previously not working to start working again, but... the four that were working stopped working...
This is clearly an issue with the winding order of the polys being used to build up the trigger object. What seems to be happening is that sometimes a trigger is created with reversed polys, causing it to fail.
I have tried creating the triggers in script, copying working triggers, etc, but to no avail.
My trigger code is very simple:
As I said, there are six triggers, all identical to the one above except for the position, only four (or two) work.
I'm not sure where to go to solve this, but I'm fairly confident in calling it a bug, I can't see anything I could have done that would cause this.
When creating triggers in the mission editor as usual, only some of them are working. My triggers are all the exact same, with the exception of the position. Same datablock, same scale values, etc etc.
I have six triggers in the level, and I can only get four of them to work, at best.
Implementing the fix described here: (in post 4)
https://www.garagegames.com/community/forums/viewthread/135658
Did nothing until I also made the same change in the "ConsoleSetType" function here:
U32 numArgs = dSscanf(argv[0], "%g %g %g %g %g %g %g %g %g %g %g %g",
&origin.x, &origin.y, &origin.z,
&vecs[0].x, &vecs[0].y, &vecs[0].z,
&vecs[2].x, &vecs[2].y, &vecs[2].z,//here
&vecs[1].x, &vecs[1].y, &vecs[1].z);//and hereThis cause the two triggers that were previously not working to start working again, but... the four that were working stopped working...
This is clearly an issue with the winding order of the polys being used to build up the trigger object. What seems to be happening is that sometimes a trigger is created with reversed polys, causing it to fail.
I have tried creating the triggers in script, copying working triggers, etc, but to no avail.
My trigger code is very simple:
datablock TriggerData(LowCoverTrigger)
{
tickPeriodMS = 100;
};
function LowCoverTrigger::onEnterTrigger(%this,%trigger,%obj)
{
echo("ENTER: " @ %obj);
}
function LowCoverTrigger::onLeaveTrigger(%this,%trigger,%obj)
{
echo("EXIT: " @ %obj);
}
new Trigger() {
polyhedron = "-0.5000000 0.5000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 -1.0000000 0.0000000";
dataBlock = "LowCoverTrigger";
position = "8.38168 0.249492 238.899";
rotation = "1 0 0 0";
scale = "4 1 5";
canSave = "1";
canSaveDynamicFields = "1";
triggerOff = "0";
};As I said, there are six triggers, all identical to the one above except for the position, only four (or two) work.
I'm not sure where to go to solve this, but I'm fairly confident in calling it a bug, I can't see anything I could have done that would cause this.
#2
01/24/2014 (8:22 am)
Quote:Some triggers work, others don't, even if these are exact copies (different position) of the ones that do work. The triggers that have been created before T3D 3.5 are working without any issues.So, copies of triggers that were created pre-3.5 also don't work? Or are they subject to the "sometimes they work, sometimes not" condition? Something about this situation doesn't sit right - it just seems very strange.
#3
01/24/2014 (8:50 am)
They sometimes work! It's not logical!
#4
01/24/2014 (11:08 am)
It is bizarre, it's made triggers essentially unusuable for me, I've had to implement a solution using raycasts. It's surprising that something like this has gone unnoticed, surely triggers are widely used? Maybe it only occurs on some systems? I'm using Win7 64, AMD Phenom 2 X6, with an ATI Radeon HD 5900.
#5
01/24/2014 (12:10 pm)
If I have time this weekend I'll diff between 1.2, 3.0 and 3.5 to see if there were any changes that might be causing this. I can't recall anyone mentioning work on triggers so I can't imagine that they'll be different, but I guess you don't know until you look, eh?
#6
Just as a matter of interest, what diff tool do you use?
01/24/2014 (4:52 pm)
That would be great Richard, thanks! I don't remember which build I was using when I last used triggers, but it was probably fairly recent?Just as a matter of interest, what diff tool do you use?
#7
01/31/2014 (2:05 pm)
I just found out that sometimes the datablock part of the trigger isn't saved when saving a mission. When you quit T3D and start it up again, loading that mission, the trigger isn't working. This seems especially the case when you copy a trigger in the editor.
#8
02/11/2014 (11:39 am)
Did anybody found a solution to this yet? it happens also on my machine... 
#9
Unfortunately, while this change does make the trigger polyhedron's get and set methods consistent with each other, based on your reports it has broken triggers overall.
I was going to revert this change and merge it into the development branch, and release this change with v3.5.1. Unfortunately, it is likely that any triggers that were created with v3.5 will then no longer work, but triggers in missions made with previous versions of T3D should go back to working.
Thoughts about this? Concerns?
- Dave
02/11/2014 (12:23 pm)
The only change I see to trigger.cpp is this one: github.com/GarageGames/Torque3D/commit/3d153e5fdc13cfd3f3a361061413200dfd8b18aa, which was done for v3.5. You can see the full effect of the change here: github.com/GarageGames/Torque3D/blame/master/Engine/source/T3D/trigger.cpp#Unfortunately, while this change does make the trigger polyhedron's get and set methods consistent with each other, based on your reports it has broken triggers overall.
I was going to revert this change and merge it into the development branch, and release this change with v3.5.1. Unfortunately, it is likely that any triggers that were created with v3.5 will then no longer work, but triggers in missions made with previous versions of T3D should go back to working.
Thoughts about this? Concerns?
- Dave
#10
02/11/2014 (12:28 pm)
Just to understand it correctly: With 3.5 as it is now, any Triggers created with this Version of the engine work within 3.5, "only" Triggers created in previous Version do not work? If so, then I would prefer to leave the code as it is and not revert the code.
#11
I think problem is that even triggers made with 3.5 don't always work.
02/11/2014 (2:25 pm)
@AndyI think problem is that even triggers made with 3.5 don't always work.
#12
At this point I'm using onTickTrigger as the only stable method to know if an object is intersecting the trigger.
02/11/2014 (7:05 pm)
The behaviour of the triggers is very inconsistent. Like not calling onEnterTrigger or calling onLeaveTrigger multiple times. I can't find the logic behind that and have no idea what broke it. I did revert the 3.5 changes in trigger.cpp.At this point I'm using onTickTrigger as the only stable method to know if an object is intersecting the trigger.
#13
At the moment I am having to "fake" triggers by iterating through all of the players in the game and getting their distance from an object placed where the trigger should be.
02/11/2014 (10:49 pm)
Yes, It seems that triggers in 3.5 are effectively not working. Since almost every game needs triggers of some kind, I would think reverting the code to the previously working state would be the best solution?At the moment I am having to "fake" triggers by iterating through all of the players in the game and getting their distance from an object placed where the trigger should be.
#14
Here is the long version. It looks like the original "fix" was put in place because someone didn't like that the vertex indices for the original get method of the trigger's polyhedron were in a different order than the set method of the polyhedron.
Well, it turns out that original index order is indeed important, and that the Point3F vecs[3]; variables used in each method are completely unrelated other than have the same names. These variables aren't even shared between these methods, so I'm not sure what issue the original change was trying to fix, other than someone thinking they could make the code easier to read I suppose.
By doing this index ordering swap you end up changing the winding order of a trigger's polyhedron each time you save your mission. So you put a trigger in a mission and test it out. It works fine so you save your mission. But the next time you load in the mission the winding order is incorrect and the trigger now fails. Now, if you were to resave the mission again, the winding order would swap, causing the trigger to function again upon the next play through. The act of saving flip-flops between working and not working.
There are two ways to fix this. We could modify the code in ConsoleGetType( TypeTriggerPolyhedron ) so that the modified vertex indices no longer flip the winding of the polyhedron each time. This will require tracing the code, determining what it is doing, and then modify it. Or, we revert back to the way things were done before v3.5.
I'm going to push for going back to the way things were before v3.5. I don't want to spend any more time on v3.5.1 so that I can get it out real soon, and there doesn't appear to be any real benefit to the change anyway. If someone really wants the vertex indices to match between these get/set methods, then they can rewrite the whole get method properly and submit it for the next release. :)
- Dave
02/12/2014 (11:39 pm)
OK, I've spent time tonight going over this issue and I now understand what is going on. In summary, we'll need to revert the change and go back to the way it was, and unfortunately some or all of your triggers could be broken, due to a case of unnecessary optimisation.Here is the long version. It looks like the original "fix" was put in place because someone didn't like that the vertex indices for the original get method of the trigger's polyhedron were in a different order than the set method of the polyhedron.
Well, it turns out that original index order is indeed important, and that the Point3F vecs[3]; variables used in each method are completely unrelated other than have the same names. These variables aren't even shared between these methods, so I'm not sure what issue the original change was trying to fix, other than someone thinking they could make the code easier to read I suppose.
By doing this index ordering swap you end up changing the winding order of a trigger's polyhedron each time you save your mission. So you put a trigger in a mission and test it out. It works fine so you save your mission. But the next time you load in the mission the winding order is incorrect and the trigger now fails. Now, if you were to resave the mission again, the winding order would swap, causing the trigger to function again upon the next play through. The act of saving flip-flops between working and not working.
There are two ways to fix this. We could modify the code in ConsoleGetType( TypeTriggerPolyhedron ) so that the modified vertex indices no longer flip the winding of the polyhedron each time. This will require tracing the code, determining what it is doing, and then modify it. Or, we revert back to the way things were done before v3.5.
I'm going to push for going back to the way things were before v3.5. I don't want to spend any more time on v3.5.1 so that I can get it out real soon, and there doesn't appear to be any real benefit to the change anyway. If someone really wants the vertex indices to match between these get/set methods, then they can rewrite the whole get method properly and submit it for the next release. :)
- Dave
#15
For me it's no problem to put it all back to the previous version. In fact I already did, but the triggers might be faulty as you described by saving the mission files. Tomorrow I'll delete all the triggers and put back manually the old ones from the backup files (prior to the change). See how that goes and will let you know!
Thanks again!
02/13/2014 (12:00 am)
Many thanks @Dave for looking into this!For me it's no problem to put it all back to the previous version. In fact I already did, but the triggers might be faulty as you described by saving the mission files. Tomorrow I'll delete all the triggers and put back manually the old ones from the backup files (prior to the change). See how that goes and will let you know!
Thanks again!
#16
02/13/2014 (6:16 am)
+1 for revert - drop a note there to remind everyone why they should just leave it alone.... 
#17
02/13/2014 (8:39 am)
My fault for not fully testing that one. It originally came from one of those "ignored" pull requests that was submitted incorrectly. This definitely shows why it is good to take the time to be 100% certain about even the simplest of changes.
#18
02/13/2014 (9:22 am)
@Mike - No worries, I remember there being a pretty lengthy discussion on the forums so no blame. None of us caught it.
#19
02/13/2014 (12:34 pm)
Thanks Dave for checking it out! 
#20
I had done the Revert of trigger but was having issues with all but the
first Trigger I created...
Heres what occured and what I had to do to fix it:
Create a Trigger with a class name and custom Datablock
Scale it out to fill the area properly leaving the poly untouched.
Now copy it and paste it to another spot on the map with a dif name
same datablock / class
(I have 5 of these total with it setup to add dynamically as many as
I want/need on just this map alone).
The Issue:
First Trigger works fine, all other Triggers fail to trigger doesn't
even trigger in c++ debug mode. I didn't dig all the way back into
the collision code, but the trigger.cpp file is never access on the
copies.
Heres one of the triggers:
FIX:
Do not copy/paste the triggers, had to do each by hand for each
location and now they work fine. This is a Flag capture system where
I catch the OnAdd() for the class for setting up the flags so it was
important that the class name worked.
Just to be safe I also reloaded the Mission and modified one of the
many triggers (scaled it a bit and moved it a little), saved mission
and exited/reloaded. They function properly now. So it looks like
the copy function for objects is causing issues with the triggers.
02/28/2014 (6:11 pm)
I ran into further issues with this....I had done the Revert of trigger but was having issues with all but the
first Trigger I created...
Heres what occured and what I had to do to fix it:
Create a Trigger with a class name and custom Datablock
Scale it out to fill the area properly leaving the poly untouched.
Now copy it and paste it to another spot on the map with a dif name
same datablock / class
(I have 5 of these total with it setup to add dynamically as many as
I want/need on just this map alone).
The Issue:
First Trigger works fine, all other Triggers fail to trigger doesn't
even trigger in c++ debug mode. I didn't dig all the way back into
the collision code, but the trigger.cpp file is never access on the
copies.
Heres one of the triggers:
new Trigger(Base0_trigger) {
polyhedron = "-0.5000000 0.5000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 -1.0000000 0.0000000 0.0000000 0.0000000 1.0000000";
dataBlock = "FlagTriggerDB";
position = "2287.06 2423.35 549.856";
rotation = "1 0 0 0";
scale = "16.0801 10.8006 2.7289";
class = "FlagTriggerObj";
canSave = "1";
canSaveDynamicFields = "1";
BaseID = "0";
enabled = "0";
};FIX:
Do not copy/paste the triggers, had to do each by hand for each
location and now they work fine. This is a Flag capture system where
I catch the OnAdd() for the class for setting up the flags so it was
important that the class name worked.
Just to be safe I also reloaded the Mission and modified one of the
many triggers (scaled it a bit and moved it a little), saved mission
and exited/reloaded. They function properly now. So it looks like
the copy function for objects is causing issues with the triggers.
Torque Owner Nils Eikelenboom
Studio DimSum
I agree to call this a bug!