Event.Timer() Questions

[ark1320]

Hello Pete,

I'm using FSUIPC 4.949 on a Win7 64bit system with FSX.

 

I'd like to use event.timer() within a Lua script to periodically call a function that is testing for a specific condition during a flight. Once the condition is found I want to exit the script thus preventing any further function calls. My questions are:

 

- If the function called by event.timer returns a value, how do I get access to that value? My intent is to test the return value as a basis for exiting the script, or is there a better way to stop the event timer and exit the script once the desired condition is found?

 

- What is the consequence on other processing of using a large number for the event.timer msec parameter? For example, if I only want event.timer to call the function every minute (thus using a 60000 msec value) does that significantly eat up CPU time and slow down overall processing?

 

- In your documentation for event.timer there is the following: 

 

         Your processing function:
         function-name(time)

 

Could you please briefly explain what that is trying to tell me. For some reason I can't seem to get it.  Finally, and perhaps related to  this, the documentation also says

 

   The time provided is NOT the same as the one returned by the ipc.elapsed time function.

 

Does this mean the event.timer function returns a time provided value of some kind  -- perhaps the time of the last function call?

 

-- Finally, does Event.Timer make use of the ipc.sleep function?

 

Thanks for your help,

 

Al

[aua668]

Hi,

 

A lot of your questions are answered in the global description of events, which is also valid for the event.timer function:

 

 

Events allow you to build plug-ins which rather than running continuously in a loop in order to interrogate things

can be set to stay loaded but dormant waiting for those things to occur. Almost anything which can be done in a

continuously running loop can be done more tidily and pleasingly using events instead.

 

Events rely on you specifying two things: what it is you want to monitor, and which pre-defined function, in your

program (or called up byRequire) you want to run when the monitored event occurs. There is no specific

restriction on how many different events you can monitor in one program, nor how many times you can trap the

same event for different functions. But note that, whilst FSUIPC does keep track of separate events, it does not

queue multiple identical events. If a button is pressed 20 times before you process it, you only see it once. Therefore

if you are monitoring things which can happen repetitively you will need to keep your processing short enough if

you hope to catch them all.

 

The function name provided as a string in the Lua event function calls can now be functions in tables. This enables

functions in Modules, brought in by the require function, to be used for event processing, because Modules so

enabled provide tables of functions (and other values) for access in the current program. The format of the function

reference string must be <table>.<function>, so if the Module is named (or equated to) "M", say, then function "fn"

inside it would be referred to as "M.fn" in the event function. (The alternative form "M[fn]" is not allowed). The

facility is actually extended to handle tables within tables, to no set limit other than the entire string name must be

less than 64 characters (between the "").

 

A Lua plug-in with any events being monitored stays running (or rather dormant, awaiting those events) until it

either explicitly terminates (via ipc.exit), fails through some error, or cancels its last outstanding event monitor.

 

 

So the LUA plugin is waiting/dormant until the event occurs - so no CPU factor. And the exit can be realized via ipc.exit function. From my personal experience I can tell you, that this comcept is working perfectly and without any impact on performance.

 

Rgds

Reinhard

[ark1320]

Hi Reinhard,

 

Thanks very much for the info. I had read the above but somehow missed the significance of the ipc.exit function which I see is the key when using the event timer, at least in my application.  Can I assume, as for the event.timer function, the ipc.sleep function also has little impact on other processing while "sleeping"?

And for both of these functions, can the time (msec) parameter be a variable as long as it is determined before the function is first called?

 

Finally, do you happen to know the answers to my other questions concerning the event.timer function documentation regarding  the meaning of Your processing function:  function-name(time) and The time provided is NOT the same as the one returned by the ipc.elapsed time function?  I think understanding this will help me with other function documentation.

 

Thanks again,

Al

[Pete Dowson]

Can I assume, as for the event.timer function,  the ipc.sleep function also has little impact on other processing while "sleeping"?

 

Yes. The thread is simply suspended for (at least) the specified time. The Sleep is actually a Windows function.

 

Lastly, do you happen to know the answers to my other questions concerning the event.timer function documentation regarding  the meaning of Your processing function:  function-name(time) and The time provided is NOT the same as the one returned by the ipc.elapsed time function?

 

It simply means that the two times are not comparable, they are not from the same source. You can use the time supplied by the event.timer function to compare with previous such times -- for instance to determine how long it really was since the last timer event. It might not be exactly the number of milliseconds requested in the call because the resuscitation of the thread might be delayed by the loading on the system -- even possibly by quite a lot with some things FS does.

 

The actual time difference might be important for those applications wishing to do stuff in a time-related way, maybe computing speeds, distances, frequencies of things, and so on.

 

Pete

[ark1320]

You can use the time supplied by the event.timer function to compare with previous such times ...

 OK, I think I get it now. It is not that the event.timer function returns a specific time value somehow ( in the sense a function can return a parameter value), but rather you can mark a time based on when the event.timer function has "fired".  I just had the wrong mindset.

Thanks for the help.

Al

[Pete Dowson]

 OK, I think I get it now. It is not that the event.timer function returns a specific time value somehow ( in the sense a function can return a parameter value)

 

Er ... sorry. This is surely clear from the definition of the function you declare to receive the event?  You quoted the words yourself earlier:

 

Your processing function:  function-name(time) 

 

YOUR processing function, i.e. the one YOU write to process the event, is declared as "function-name(time)". The function-name and the parameter name ("time" here) are up to you to choose, but it certainly means that the time is provided TO the processing function as a parameter? How else could you possibly interpret it? I'm trying to find what on Earth is wrong with the documentation here.

 

If "time" was returned by the event.timer call itself it would be documented as

 

time = event.timer(time, "function-name")

 

just as it is for all the other descriptions of functions which return a value.

 

Look through the other event function descriptions. Different parameters, as appropriate to the type of event, are provided to each. Whether you choose to use them or not is up to you.  If you don't use them you don't even need to declare them -- Lua is very flexible (unlike most languages) in this regard.

 

Pete

[ark1320]

Er ... sorry. This is surely clear from the definition of the function you declare to receive the event?  You quoted the words yourself earlier:

 

Your processing function:  function-name(time) 

 

YOUR processing function, i.e. the one YOU write to process the event, is declared as "function-name(time)". The function-name and the parameter name ("time" here) are up to you to choose, but it certainly means that the time is provided TO the processing function as a parameter? How else could you possibly interpret it? I'm trying to find what on Earth is wrong with the documentation here.

 

 

Pete,

I am not an experienced programmer (as you can tell) but I do understand that time is a parameter being passed to the function. In my event.timer application I am just using the timer to call my function periodically, there is no parameter that I need to pass to it. So that has been my mindset.  Apparently in a typical use of the event timer there would be a time parameter passed to the user's function, and so that is why you named the parameter time in your documentation. I think I was reading more into that then I should have.

 

And in no way was I criticizing your documentation. I fully realize the problem is on my side.

 

Thanks for your time,

 

Al