event.timer

[funkyp]

Hi Pete

again a (simple?) question. I'm trying using the "event.timer" function. Is it correct that

1) the trigger of the callback function goes maximum with the framerate?

2) setting the timer period to "0" results in an (almost) frame-synchronous execution?

Is it allowed to use "0" to get something frame-synchronized function, or is there a risk of malfunction?

best regards,

Peter

[Pete Dowson]

again a (simple?) question. I'm trying using the "event.timer" function. Is it correct that

1) the trigger of the callback function goes maximum with the framerate?

No, it shouldn't do. It's using the Windows "SetTimer" function, which operates with a millisecond value. However, its granularity might limit it -- for instance, older Windows systems like Win98 did, I think, operate to 55mSecs (about 18 Hz), the "tick" count. But all recent versions do, I'm pretty sure, operate to 1 millisecond. Not that you could use anything so short in a Lua program, as that's being interpreted in any case at a max rate, maybe approaching one line per millisecond.

Also, timer callbacks are low priority things. You don't necessarily get control of the processor back until you next regular timeslice (or, these days, I should say "one of the processors, of course).

2) setting the timer period to "0" results in an (almost) frame-synchronous execution?

Theoretically 0 should result in an immediate callback -- or at least when you exit the program which sets that, as the interpreter won't re-enter the program till you exit.

Is it allowed to use "0" to get something frame-synchronized function, or is there a risk of malfunction?

There's no way to get a frame-synchronised function. In fact, on FSX, I don't think there's a way at all. On FS9 and before I could hook into a chain which was called once per visual frame (there are different concepts of "frame" -- the simulation rate in the Sim engine is usually much faster than the visual frame, i.e. the re-drawing of the screen image).

Regards

Pete

[funkyp]

Hi Pete,

thanks for the feedback. The question was raised by the observation, that the repetition rate of my LUA script resulted exactly in the FPS rate when I chose 0, and as long as I didn't use the ipc.display-function. With the latter, there was jitter in the rate which could be very well explained by skipping individual frames. Howeber, it did not happen this way that the the machine was locked up when 0 was the timer rate.

Different to that, using the sleep(ms) function immediately blocked FSX, when used with a parameter of 0. Yet, it might be a coincidence.

From your response I would conclude that it is not recommended using a call like "event.timer('F-Name',0)", or equivalent.

Indeed, frame-synchronised ("SimFrame" (60/s const.)and "VisualFrame") events are offered by SimConnect, but their precision and reliability is still poor in SimConnect clients.

best regards,

Peter

[Pete Dowson]

The question was raised by the observation, that the repetition rate of my LUA script resulted exactly in the FPS rate when I chose 0 ..

Interesting, but I think it must be just a coincidence.

it did not happen this way that the the machine was locked up when 0 was the timer rate.

I wouldn't really expect things to lock up. The timer system operates at a lowish priority. It would only mean that your Lua time function would be re-entered as soon as it exited, within the frame of Lua interpretation, bearing in mind that there's an interpreter-imposed delay (a hand-off to other threads) between each line to ensure full time-slicing cooperation. I would just think that any timer setting of less than about 20 mSecs would actually give an unpredictable rate, but it may well coincide with all the other demands which have a regular rhythm, like the visual frame rate.

Different to that, using the sleep(ms) function immediately blocked FSX, when used with a parameter of 0.

Sorry, can you clarify that? What blocked who and how? The sleep function actually does call the Windows Sleep API, and "Sleep(0)" merely tells Windows "if anyone else is ready to run, give him this time slice, but if not let me continue".

From your response I would conclude that it is not recommended using a call like "event.timer('F-Name',0)", or equivalent.

Assuming you mean "event.timer(0,"F-Name",)", then, no, because you've no knowledge of what that achieves. If you really want to re-execute the function immediate, just loop. Having a Timer do it seems superfluous.

Indeed, frame-synchronised ("SimFrame" (60/s const.)and "VisualFrame") events are offered by SimConnect, but their precision and reliability is still poor in SimConnect clients.

FSUIPC uses them, but they are not synchronised -- SimConnect interaction is too loose, too asynchronous. FSUIPC's interface with FS9 and before was rather different.

Regards

Pete

[funkyp]

Sorry, can you clarify that? What blocked who and how? The sleep function actually does call the Windows Sleep API, and "Sleep(0)" merely tells Windows "if anyone else is ready to run, give him this time slice, but if not let me continue".

I have rechecked it and found that the lock-up only occurs when using ipc.display in the loop:

while true do
	ipc.display("Something")
	ipc.sleep(0)
end

In this case FSX stopped to react on user input and was frozen.

Different to that, the next works without a problem (also when the commented line is activated):

function timerfunction(time)
	-- event.timer(0, "timerfunction")
	ipc.display("Something")
end

event.timer(0, "timerfunction")

BTW, for checking the actual execution rate I had included a call to "ipc.elapsedtime" in the loop for measuring the delay between two calls, retrieved the FPS from offset 0x274 to compare, and averaged both. In order not to introduce extra delays during the test, the display function was inactive and toggled active with a flag at the end to show the final result.

Cheers,

Peter

[Pete Dowson]

I have rechecked it and found that the lock-up only occurs when using ipc.display in the loop:

while true do
	ipc.display("Something")
	ipc.sleep(0)
end

In this case FSX stopped to react on user input and was frozen.

That's probably because you've got FSUIPC calling FS's window display routine as fast as it possibly can, and that doesn't leave time for anything else. To avoid re-entry to non-re-entrant functions, most of the FS routines used by FSUIPC, and therefore Lua, are called from within the main FS thread -- and if that does nothnig esle, nothing else looks like being done!

The same effect would occur with many other Lua facilities which invoke, directly or otherwise, FS functions.

Different to that, the next works without a problem (also when the commented line is activated):

function timerfunction(time)
	-- event.timer(0, "timerfunction")
	ipc.display("Something")
end

event.timer(0, "timerfunction")

Yes, I can understand that. As I said, the timer is a low priority facility.

Regards

Pete

[funkyp]

I think I got it now. Previously I had mistaken the sleep function as a timer, too, which is not.

Thanks for your help,

Peter

[funkyp]

Hi Pete,

I got a new problem with the event.timer today. After success with my first timer function I tried to add a second timed function in another Lua-plugin. To isolate the cicumstances I have prepared to timer-plugins, "timer1.lua" and "timer2.lua".

timer1.lua goes like this:

function timer1function(CurrentTime)
   ipc.display("Timer1="..CurrentTime)
end

event.timer(1000, "timer1function")

timer2.lua goes like this:

function secondtimer(CurrentTime)
    ipc.display("Timer2="..CurrentTime)
end

event.timer(100, "secondtimer")

I have mapped the scriptfiles on two keyboard keys by FSUIPC. When I trigger the first script it installs the event.timer for every second reaction, and the "Timer1=nnnnn..." shows up with the correct rate. When I trigger now the second function, "Timer2=nnn.." might be considered to show in between the updates of the first timer function.

However, all what happens is, that the update frequency of the "Timer1=nnn..." accelerates by a factor of 10. If I kill the second timer function, "Timer1=nnn..." ceases to update.

My understanding was that only one timer function can exist in one Lua-plugin. Therefore I made the two plugins, but apparently only the first function is being registered as a timer callback, while the event.timer call in the second function doesn't register its callback. Nevertheless it changes the update rate of the first function.

It happens also vice versa, i.e. if I start with the fast timer function, then "Timer2=nnnn" shows up and is slowed down by firing the timer1-script. The same effect happens if I try firing the two functions by "ipc.runlua()".

Did I misunderstand the timer thing or have I missed something in the documentation?

Cheers,

Peter

Edit: I'm using V4.661

[Pete Dowson]

My understanding was that only one timer function can exist in one Lua-plugin. Therefore I made the two plugins, but apparently only the first function is being registered as a timer callback, while the event.timer call in the second function doesn't register its callback. Nevertheless it changes the update rate of the first function.

It happens also vice versa, i.e. if I start with the fast timer function, then "Timer2=nnnn" shows up and is slowed down by firing the timer1-script. The same effect happens if I try firing the two functions by "ipc.runlua()".

Did I misunderstand the timer thing or have I missed something in the documentation?

No, they should be entirely independent. I'm not sure what's happening. I had a similar test setup and it worked exactly as it should. Something must have got changed more recently.

I'll check it out in the morning at let you know. It is getting late here now and I'm tired!

{IN THE MORNING]

Okay. Found it. Stupid typo in an unrelated section of code, overwrote the ID and gave all Lua timers the same ID. Grrr!

It'll be fixed in 4.662, later today.

Regards

Pete

[Pete Dowson]

It'll be fixed in 4.662, later today.

Fixed in FSUIPC 3.989x, 4.662 and WideClient 6.843, all now available in the Download Links subforum.

Regards

Pete

[funkyp]

Fixed in FSUIPC 3.989x, 4.662 and WideClient 6.843, all now available in the Download Links subforum.

Thanks a lot and :-D

Cheers,

Peter