simple timers in the EDx?

now that it is easier to call a timer function by making it an eventhandler persay, does the removeTimer() command now become defunct and we have to use disableTimer or deleteTimer?

I was reading your online help last night Tvig and I could see a reference to the old removeTimer command. Is it still applicable when writing timers using the simpleTimer method?

Cheers

MD

If you are using ofp timers use OFP:removeTimer. For simple edx timers use EDX:deleteTimer.

Cheers

cheers mate, I wasn't too sure what to do about it. I'll change what I have at the moment then to deleteTimer().

Do you need to delete serialTimers() or manage them as not to have too many build up in memory?

It was explained to me that they expire on their own - however, I would not force the issue by having timers spawn timers spawn timers. Though it might make for a nice theoretical test script.

Ahh... JS, it must be cold and your about to hunker down?

It turns out, there is a limit to how many EDX:serialTimers() you can initiate from timers firing and re-setting more timers.

I too was under the impression that they self managed. And for the best part they do. However when you create a timer loop of sorts, the limit is around 400-500 and vary's by how many instances you have running.

At first, I tried setting up a loop count to control the duration of the loop. But re-triggering the timer loop again and again eventually results in a CTD.

To fix the issue, I had to incorporate recording the timer ID into the loop and use EDX:deleteTimer() to delete the previous instance. This appears to have solved the limit issue. Somewhat similar to OFP:removeTimer(), however instead of a limit of 14-16 running at once it's between 400-600. I remember Tvig expressing a belief of a limit, but didn't know what it was.

You'll appreciate this John,
There is a file to downloaded here...
https://operationflashpoint.forummotion.com/t112p15-better-lighting#697
in the version above the problem exists.

This version the problem appears to be solved...
http://filebeam.com/eae5db7fd5e58ac6a4826baeb1801155
However it also highlights a triggerzone nuance. Entering the second triggerzone inside the first fails on the first attempt. Re entering will fire from then on.

Cheers,

Here's the deal.

Every time you create a serial timer using EDX:serialTimer, you create a new instance of a timer that stores into the timer table with a completely new entry. To reset a serial timer you must use EDX:setTimer passing the timer id that was generated when the timer was created. This ID number is also passed as the last variable in the function you are triggering with the timer.

When you create a simple timer using EDX:simpleTimer, it creates a single instance of the timer and can be reset using EDX:simpleTimer again, calling the timer by name. You can also reset the timer by using EDX:setTimer, also calling the timer by name. The primary difference is when you reset a simple timer by recalling EDX:simpleTimer, it will reinventory all of the scripts in an attempt to find the scripts that contain the function called by the timer. This adds overhead to the process, so it is better to use EDX:setTimer when resetting a simpleTimer as well.

You have no option when resetting a serial timer other than to use EDX:setTimer as EDX:serialTimer will create a new instance of the timer that calls the same funciton. If you start to stack these timers up, it is best to try to delete them along the way. Each of them occupies some space in memory and even when they expire and fire their given functions they lie dormant in memory unitl reset or deleted.

In a scenario where you are firing the same timer over and over again feeding it the same information over and over again, you want to use simple timers. In a scenario similar to the parachute script when we wanted to be able to use the same functions to handle multiple choppers, you would want to use serial timers in order to have a timer for each chopper being handled by the script.

There is no need to record the timer ID to a variable when using serialTimers because the timer ID is passed to the function automatically.

Code:


myTimer = EDX:serialTimer("myFunction", 1000, variable1, variable2)
--creates a new instance of a serialTimer assigning the timerID to myTimer

function myFunction(var1, var2, timerID)
--note that I added timerID to the function variables because it is automatically passed to
--the function, but you must tack this variable to the end of your variable list so it can
--handle the info and pass it into the function, this is important!

if var1 == "this" then
  --do that
end

if var2 == "that" then
  --do this
end

EDX:setTimer(timerID, 1000)
--this line resets this instance of the serial timer without using any more memory
--In this scenario the variable timerID = myTimer... so there is no need to record
--the timer ID using the variable myTimer... it is already recorded and passed to
--the function as illustrated by this example.

end


It is also worthy of mention that when I reset the timer, I didn't reset var1 and var2 as unless the values change, there is no need to do this. Each timer will retain the value of all of the variables passed to it until they are declared again. Please note that if you redeclare any of the variables, you must redeclare the entire list as they are stored in the timer as a list and changing one of them will overwrite the previous list of stored variables. This entire process is entirely independent of the EDX:setTimerVar and EDX:getTimerVar process which operates outside of the list of variables passed directly into the function by the timer. They are stored in another area of the timer entry and are unaffected by the information passed to the timer using EDX:simpleTimer, EDX:serialTimer or EDX:setTimer.

Hope this helps clear things up.

Cheers

that helped a lot (really) - just so I understand
"Now I throw the ball to first base, whoever it is drops the ball, so the
guy runs to second. Who picks up the ball and throws it to What. What
throws it to I Don't Know. I Don't Know throws it back to Tomorrow—a
triple play."

JohnStevens wrote:that helped a lot (really) - just so I understand
"Now I throw the ball to first base, whoever it is drops the ball, so the
guy runs to second. Who picks up the ball and throws it to What. What
throws it to I Don't Know. I Don't Know throws it back to Tomorrow—a
triple play."

WTF! lmao! good to see you back anyway dude! hehehe! that post tickled my gibblets!

Thank for the info Tvig. It makes perfect sense to me. Which even I find surprising. It explains why I was encountering the problem and why my fix worked.
Now I just need to tweak what I have for efficiency and then to go through all my modules and apply this little lesson.

Q. Who's on first?
A. That's right.