According to the T3D doc the trigger tick is every 100ms so it might have more overhead than my schedule raycast every 300ms???
Okay that's a bit clearer, I see what you're up to now. You want that dynamic GUI dialog to automatically pop up. I took it to mean you wanted to walk up to the door, hit a button, and the door opens(no popup involved).
Well in any event constantly firing a raycast out in front of the player detecting stuff will surely keep things 'ticking', although I'd still approach it just a tad differently to reduce any additional overhead. Consider that the player may be out in the wilds someplace, far away from any potential door to be opened, yet he continues to cast rays out looking for doors that couldn't possibly exist. Here I'll try to address your implementation to the best of my understanding:
From old documentation
The defaultTrigger datablock defines its tick frequency at 100 ms.
So here we see that you can create your own trigger datablock, and instead define its tick frequency to whatever you want(i.e. 300ms that you currently use while raycasting). Alright, great, so you can use triggers at the same tick rate - how does that help?? Let's take a closer look at the Trigger class again.
In the same link provided above, check out the function DefaultTrigger::onTickTrigger
(near the bottom of the page, also referenced here
.) What this field allows you to do is enter in a command that you want to be executed while objects are inside the trigger
. So, not only can you have your raycast function be called by the trigger at the same rate, you can also have it only
fire off the raycast search while the player is close enough to the door for it to matter.
Meaning you can create a trigger area much larger than just a few feet across, say maybe 10 feet x 10 feet, and have that trigger call to your player's raycast function only while the player is within that range of the door. Now you have the same functionality you did before but it's a LOT more efficient.
Now, to be completely clear about the Trigger class, it should be understood that the Trigger itself will continue to tick at the rate you set it to even if nothing is in the Trigger's area. However, and this is the important part; the Trigger class's onTick() source code will immediately return and won't execute any code unless the criteria you set for the Trigger are met. So it will continue to 'listen' but it won't execute the raycast search code unless the player object is within the bounds of the trigger.
As usual bear in mind of course there are many ways to approach any given problem(be it in source or in script). For what you've got going, this seemed fairly appropriate, although I can see other paths as well if it isn't optimal to your needs. Personally I've spent a good deal of time and planning avoiding as many triggers and schedules as possible, but in some cases you just have to use the available classes to the best of your ability or craft up new ones
. Think it over, see if it helps, cheers!
Another thing to consider is that you could avoid the raycast code altogether. If you are going through all of that just to get a GUI control to pop up you might as well place a small trigger area in front of the door. Then when a player hits it, the GUI control pops up indicating the player is close enough to open the door. If the gameplay is of a type where clicky GUI navigation is happening to interact with stuff, whether or not the center target reticle is 'looking at' the door shouldn't matter. If you are standing on the door square you can open the door. Food for thought =)