Alternative to ipc.ask() ?

[Pete Dowson]

When you detect the return character just cancel all events and do a ‘return’. Didn’t John’s do that?

Pete

[ark1320]

1 hour ago, Pete Dowson said:

When you detect the return character just cancel all events and do a ‘return’. Didn’t John’s do that?

Pete

Yes, John's script does that and it works fine as a stand alone Lua program. It is when I try to incorporate it into the form of a function to be called from a main program,  the function 'completes' before any key presses can be detected and returns to the calling program which then of course 'continues on'. 

You have been more than generous with your time on all this, I will continue to think about it and see what I can figure out. 

Many thanks,

Al

[ark1320]

Just to clarify, I just realized that I was not quite correct above in that John's script does not use a discrete return instruction since it is not written as a function, but when a return character is detected, all events are cancelled and the program just ends.

Al

 

[Pete Dowson]

1 hour ago, ark1320 said:

I just realized that I was not quite correct above in that John's script does not use a discrete return instruction since it is not written as a function, but when a return character is detected, all events are cancelled and the program just ends.

Okay.  It might be more logical for the function to exit (by virtue of the 'end', or a 'return' -- it makes no difference), and should then continue to execute the rest of the program. If so then the event function calls would have to come beforehand.

I think FSUIPC is programmed to keep track of events outstanding for the plug-in and terminate it when they are all removed.

If you need to force-terminate a plug-in, whether any events are outstanding or not, you can use

ipc.exit()

Since that would automatically remove all events the code could just make use of that function instead of the list of event cancellations.

Pete

 

Pete

 

[ark1320]

3 hours ago, Pete Dowson said:

Okay.  It might be more logical for the function to exit (by virtue of the 'end', or a 'return' -- it makes no difference), and should then continue to execute the rest of the program. If so then the event function calls would have to come beforehand.

I think FSUIPC is programmed to keep track of events outstanding for the plug-in and terminate it when they are all removed.

If you need to force-terminate a plug-in, whether any events are outstanding or not, you can use

ipc.exit()

Since that would automatically remove all events the code could just make use of that function instead of the list of event cancellations.

Pete

 

Pete

 

Pete, your patience is quite amazing. I think I have done a poor job of explaining what I see as the problem, or I’m not astute enough to fully understand what you are telling me, or maybe both. In any case, if the ipc.ask() function worked, I might have a main program script like this:

-- main program

new_alt = ipc.ask(“enter altitude”)

code here to process altitude input

new_hdg = ipc.ask(“enter heading”)

code here to process heading input

new_gs = ipc.ask(“enter ground speed”)

code here to process ground speed input

-- end main program

What I ‘m trying to do is write a new function (not stand alone program) called get_input() that is based on John’s stand alone askTest script. This new function would be defined at the top of the program above and then I could call it in place of the three ipc.ask() functions, e.g., new_alt = get_input (“enter altitude”), etc. The challenge I have is that while each ipc.ask() function would in essence stop program execution and wait for the user to enter the requested data (followed by a return character), I can’t figure out how to make the replacement get_input() function based on John’s work do that –as a called function it executes in a ‘flash’ and returns to the main program before the user has time to enter any data. How to add that ‘wait for input feature’ that ipc.ask() has to the replacement get_input() function is what I’m struggling with.

 Stated more generally, the issue is how do you prevent a called function from returning to the main program until a particular character is detected if , as you explained above, you can't use 'loop' constructs (repeat-until, while-do, etc) that don't relinquish control because the called function makes use of event type operations such as event.key().

Hope that clarifies the problem as I see it.

Thanks you,

Al

 

 

 

[Pete Dowson]

7 hours ago, ark1320 said:

Stated more generally, the issue is how do you prevent a called function from returning to the main program until a particular character is detected if , as you explained above, you can't use 'loop' constructs (repeat-until, while-do, etc) that don't relinquish control because the called function makes use of event type operations such as event.key().

Okay.

I can think of two ways of doing what you want.

First one s to keep the "asking" plug-in almost as it is, but run it from your main program using ipc.runlua, first placing your question into a global variable (maybe called QUESTION), using ipc.set. Have the asking plug-in to display your question by reading it via ipc.get, and place the result into another global variable, say ANSWER for the main plug-in to retrieve.

Then your main plug-in can use event.timer to see if the reply has yet arrived. You'd need to initialise the global ANSWER to, something not possible to be a reply so you can see when it has changed.

You'd need to do this for each answer you want, maybe using a set of different timer functions. Note that each time you use event.timer it replaces the previous event.timer -- no need to cancel it.

The second way would be to work it like that but in one large program. i don't think that would be so neat a solution, though, and easy to make errors in, so I''m not going to attempt to do so.

Pete

 

[ark1320]

17 hours ago, Pete Dowson said:

Okay.

I can think of two ways of doing what you want.

First one s to keep the "asking" plug-in almost as it is, but run it from your main program using ipc.runlua, first placing your question into a global variable (maybe called QUESTION), using ipc.set. Have the asking plug-in to display your question by reading it via ipc.get, and place the result into another global variable, say ANSWER for the main plug-in to retrieve.

Then your main plug-in can use event.timer to see if the reply has yet arrived. You'd need to initialise the global ANSWER to, something not possible to be a reply so you can see when it has changed.

You'd need to do this for each answer you want, maybe using a set of different timer functions. Note that each time you use event.timer it replaces the previous event.timer -- no need to cancel it.

The second way would be to work it like that but in one large program. i don't think that would be so neat a solution, though, and easy to make errors in, so I''m not going to attempt to do so.

Pete

 

Pete -- very clever!

Here's what I came up with. The definition of the calling function as an alternate to ipc.ask() is  ask_num_data(request_string). I used  the repeat - until because John's askTest() uses an event.timer.

function ask_num_data(request_string)
         ipc.set("DATA_REQUEST", request_string)
         ipc.set("DATA_ANSWER", request_string)
         ipc.runlua("C:\\Users\\Al\\Documents\\....\\FSUIPC7\\Modules\\get_num_data.lua")
         repeat
          data_returned = ipc.get("DATA_ANSWER")
          ipc.sleep (100)
         until data_returned ~= request_string
         return data_returned
 end 

So a user would use something like this when requesting data.

gs = ask_num_data(" Enter Ground Speed ")

The accompanying get_num_data.lua script that is called, as you suggested, by ask_num_data(request_string) is below (the few changes I made to John's script are in purple). The script returns an * that can be tested for to indicate a timeout or error condition.  It all seems to work but I'm certainly open to any suggestions. This script will get much smaller when John fixes the bug in FSUIPC7 that he mentioned so one event.cancel() below will cancel all the same pending events.

Thanks for ALL the help,

Al

get_num_data.lua

-- get_num_data.lua   Script works with function call ask_num_data(request_string) as an alternate to standard ipc.ask() for getting numerical input in MSFS
-- Script is a slight modification of the askTest.lua script by John Dowson
-- 2Jan2021
     
    -- Adjust the numbers here to set your Window position and size
    --   (x, y, sizex, sizey), w is the window's 'handle' (identifier)
    local w = wnd.open("Get Num Input", WND_FIXED, 800,100,425,60)   -- Window size and location       
    wnd.show(w, WND_TOPMOST)                     -- keep window on top of screen

    -- These set the colours and font to be used.
    -- The size "-4" means the largest to fit 4 lines in the window
    wnd.backcol(w, 0x000)
    wnd.textcol(w, 0x6c0)
    wnd.font(w, WND_ARIAL,-3)

    -- Update the display at 500 msec intervals (see event at end)
    local interval = 500                                                         -- 1/2 second
    local closeafter =  120000                                            -- 2 minutes to provide data before timeout     
    local enteredText = ""                                                    -- init enteredText by user to nothing (cleared)
    local data_request = ipc.get ("DATA_REQUEST")
    local displayText = data_request
    wnd.text(w, displayText)                                               -- display message requesting input
    function mytimer(time)                                                -- close window after 2 minutes        
        closeafter = closeafter - 500
        if closeafter <= 0 then
            ipc.set("DATA_ANSWER", "*")                               -- * indicates timed out or an error condition (see below)
            wnd.close(w)
            w = 0
            event.cancel("mytimer")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")  
        end
    end
 
    function keyPressed(keycode, shifts, downup)                       -- close window after CR (Enter) key and display enter text (e.g., number)
        if keycode == 0x0D then
            if enteredText == "" or enteredText == nil then
               enteredText = "*"                                                               -- * indicates timeout (see above) or error condition
            end   
            ipc.set("DATA_ANSWER", enteredText)   
            wnd.close(w)
            w = 0
            event.cancel("mytimer")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")
            event.cancel("keyPressed")            
        else                                                                                           -- else display next char entered
            enteredText = enteredText .. string.char(keycode)
            newDisplayText = displayText .. enteredText                 -- newDisplayText = original window message + user entered text
            wnd.clear(w)
            wnd.text(w, newDisplayText)
        end
    end
 
    -- Adjust timing to taste: 500 = 1/2 second
    event.timer(interval, "mytimer")                                                 -- call function "mytimer" every 'interval' in time
    event.key(0x30 , 0, "keyPressed")   -- 0                                       -- call "keyPressed" function if 0 key pressed
    event.key(0x31 , 0, "keyPressed")   -- 1
    event.key(0x32 , 0, "keyPressed")   -- 2
    event.key(0x33 , 0, "keyPressed")   -- 3
    event.key(0x34 , 0, "keyPressed")   -- 4
    event.key(0x35 , 0, "keyPressed")   -- 5
    event.key(0x36 , 0, "keyPressed")   -- 6
    event.key(0x37 , 0, "keyPressed")    --7
    event.key(0x38 , 0, "keyPressed")    --8
    event.key(0x39 , 0, "keyPressed")    --9
    event.key(0x0D , 0, "keyPressed")    -- return
     

 

[ark1320]

Pete,

Here is a version of the above  "events" lua script that on one hand is more compact code-wise and on the other was expanded to include letters and the numpad digits. The numpad digits don't work (they actually provide the  ' char and the lower case letters a - j for num0 to num9. I think this is because of what John had to do to make the numpad keys work through SimConnect. The letters do work, although they are all returned as upper case for some reason. So this script is using 47 event.key events -- what are some of the considerations regarding the practical limit on the number of events the system can monitor at one time?

    -- Adjust the numbers here to set your Window position and size
    --   (x, y, sizex, sizey), w is the window's 'handle' (identifier)
    local w = wnd.open("Get Num Input", WND_FIXED, 800,100,425,60)   -- Window size and location       
    wnd.show(w, WND_TOPMOST)                     -- keep window on top of screen

    -- These set the colours and font to be used.
    -- The size "-4" means the largest to fit 4 lines in the window
    wnd.backcol(w, 0x000)
    wnd.textcol(w, 0x6c0)
    wnd.font(w, WND_ARIAL,-3)

    -- Update the display at 500 msec intervals (see event at end)
    local interval = 500                                                         -- 1/2 second
    local closeafter =  120000                                            -- 2 minutes to provide data before timeout     
    local enteredText = ""                                                    -- init enteredText by user to nothing (cleared)
    local data_request = ipc.get ("DATA_REQUEST")
    local displayText = data_request
    wnd.text(w, displayText)                                               -- display message requesting input
    function mytimer(time)                                                -- close window after 2 minutes        
        closeafter = closeafter - 500
        if closeafter <= 0 then
            ipc.set("DATA_ANSWER", "*")                               -- * indicates timed out or an error condition (see below)
            wnd.close(w)
            w = 0
            ipc.exit()                                                                              --  cancel all event.key events and event.timer event and exit script
        end
    end
 
    function keyPressed(keycode, shifts, downup)                       -- close window after CR (Enter) key and display enter text (e.g., number)
        if keycode == 0x0D then
            if enteredText == "" or enteredText == nil then
               enteredText = "*"                                                               -- * indicates timeout (see above) or error condition
            end   
            ipc.set("DATA_ANSWER", enteredText)   
            wnd.close(w)
            w = 0
           ipc.exit()                                                                               --  cancel all event.key events and event.timer event
        else                                                                                         -- else display next char entered                                              
           if keycode >= 65 and keycode <= 90 then                    -- convert keycodes to char codes
                  charcode = keycode + (1 - shifts)*32                           -- convert keycode to lower case if shifts = 0 by adding 32 to keycode, shifts = 1 for uppercase         
             elseif keycode >= 96 and keycode <= 105 then          -- for Num0 to Num9
                   charcode = keycode - 48
             elseif keycode >= 106 and keycode <= 111 then          -- Numpad *  +  -  .  and /   (note there is no 108 keycode)
                  charcode = keycode - 64                
             else
               charcode = keycode
           end
            enteredText = enteredText .. string.char(charcode)       -- else display next char entered    
            newDisplayText = displayText .. enteredText                 -- newDisplayText = original window message + user entered text
            wnd.clear(w)
            wnd.text(w, newDisplayText)
        end
    end
 
    -- Adjust timing to taste: 500 = 1/2 second
    event.timer(interval, "mytimer")                                                 -- call function "mytimer" every 'interval' in time
    -- valid data characters
    i = 48
    while i <= 57 do                                     -- digits 0 to 9
      event.key(i , 0, "keyPressed")
      i = i + 1
    end
    j= 65
    while j <= 90 do
      event.key(j, 0, "keyPressed")             -- Lower case letters a to z
      event.key(j, 1, "keyPressed")             -- Upper case letters A to Z
      j = j + 1
    end
    k= 96
    while k <= 111 do                                   -- number pad keys with numlock on
      event.key(k , 0, "keyPressed")            
      k = k + 1
    end
   -- additiona virtual keycodes, see FSUIPC Advanced User's Guide pages 19-20  
    event.key(8, 0, "keyPressed")               -- Backspace
    event.key(13, 0, "keyPressed")              -- Enter
    event.key(32, 0, "keyPressed")              -- space bar
    event.key(135, 0, "keyPressed")             -- Numpad Enter key

 

 

Edited January 5, 2021 by ark1320
Code updated to handle upper and lower case letters and Numpad keys

[Pete Dowson]

6 hours ago, ark1320 said:

Here is a version of the above  "events" lua script that on one hand is more compact code-wise and on the other was expanded to include letters and the numpad digits

Very neat.

6 hours ago, ark1320 said:

The numpad digits don't work (they actually provide the  ' char and the lower case letters a - j for num0 to num9. I think this is because of what John had to do to make the numpad keys work through SimConnect. The letters do work, although they are all returned as upper case for some reason.

Not sure what you think John 'had to do', but the values returned are correct and are the KEYCODES, as documented, not the ASCII code for the graphic characters. Please see the table in the Advanced Users guide, pages 17-18. You will see that the A-Z keys are 65-90 and the numerals on the NumPad are, indeed, 96-105. Key codes are used to represent every key on the keyboard which couldn't be done sticking to the standard ASCII encoding.

Pete

 

 

 

[ark1320]

6 hours ago, Pete Dowson said:

Not sure what you think John 'had to do', but the values returned are correct and are the KEYCODES, as documented, not the ASCII code for the graphic characters. Please see the table in the Advanced Users guide, pages 17-18. You will see that the A-Z keys are 65-90 and the numerals on the NumPad are, indeed, 96-105

Pete,

I don't know why with the script above the numberpad keys, with numlock on, are returned and displaying incorrectly, e.g., num1 to num9 display as the lower case letters a to i. I am using the keycodes per the table in the Advanced Users guide. There was some issue, now resolved I believe, with FSUIPC7 getting wrong numpad key codes through SimConnect, and John provided some kind of temporary work-around.

I also don't understand why with the script above keys a to z display as UPPER case using keycodes 65-90 since I'm not using the Shift option in event.key().  Maybe that is just how wnd.text() works?  The little file attached which displays the keycode of a pressed key shows the lower case letter keycodes as 65-90 with Shift off. If 65-90 were in fact upper case keycodes, what are the lower case keycodes for a to z?

Thanks to you and John this certainly has been a useful and interesting learning experience for me.

Al

KeyCodes3.exe

[Pete Dowson]

7 hours ago, ark1320 said:

don't know why with the script above the numberpad keys, with numlock on, are returned and displaying incorrectly, e.g., num1 to num9 display as the lower case letters a to i. I am using the keycodes per the table in the Advanced Users guide. There was some issue, now resolved I believe, with FSUIPC7 getting wrong numpad key codes through SimConnect, and John provided some kind of temporary work-around.

You seem to misunderstand. The KEYCODES are not ASCII character codes, they are numbers representing the physical key. The numbers 96-105 ARE the ASCII codes for a-j. If you try to display them as characters that is what you will see! You need ot convert them in your program if you want the characters 0-9.

7 hours ago, ark1320 said:

I also don't understand why with the script above keys a to z display as UPPER case using keycodes 65-90 since I'm not using the Shift option in event.key()

For exactly the same reason! The KEYCODES for the A-Z keys (and they are marked like that) are 65-90, which are the ASCII codes for A-Z, not a-z.

Please read my previous explanation again. You persist in thinking that Keycodes are ASCII character codes when they are not. Check for yourself -- compare an ASCII table (on the Internet, probably wikipedia) with the Keycode list I referred you to.

Pete

 

[ark1320]

OK, I think I get it now; event.key() only works with virtual key codes, and there doesn't seem to be any virtual key codes for lower case letters in the list in the Advanced User's Guide. I guess my thinking (or lack thereof) was skewed by my experience with ipc.ask() which works with both upper and lower case letters, etc.

Sorry for my confusion on this.

Thanks,

Al

[Pete Dowson]

11 hours ago, ark1320 said:

OK, I think I get it now; event.key() only works with virtual key codes, and there doesn't seem to be any virtual key codes for lower case letters in the list in the Advanced User's Guide.

You'd have to process the Shift key as well to decide whether it is upper or lower case. Check the definition of event.key. You'll see you can specify which shift keys you are wanting, and the value of the Shift settings is supplied to your function.

Pete

 

[ark1320]

 

 

17 hours ago, Pete Dowson said:

You'd have to process the Shift key as well to decide whether it is upper or lower case. Check the definition of event.key. You'll see you can specify which shift keys you are wanting, and the value of the Shift settings is supplied to your function.

Pete

 

I now generate events for both the upper and lower case letter keys

 j= 65
    while j <= 90 do
      event.key(j, 0, "keyPressed")             -- Lower case letters a to z
      event.key(j, 1, "keyPressed")             -- Upper case letters A to Z
      j = j + 1
    end

and process the keycodes like this:

        if keycode >= 65 and keycode <= 90 then                             -- convert keycodes to char codes
                  charcode = keycode + (1 - shifts)*32                           -- convert keycode to lower case if shifts = 0 by adding 32 to keycode, shifts = 1 for uppercase         
             elseif keycode >= 96 and keycode <= 105 then               -- for Num0 to Num9
                   charcode = keycode - 48
             elseif keycode >= 106 and keycode <= 111 then             -- Numpad *  +  -  .  and /   (note there is no 108 keycode)
                  charcode = keycode - 64                
            else
               charcode = keycode
         end
         enteredText = enteredText .. string.char(charcode)            -- else display next char entered   

With this I get upper and lower case letters and all Numpad key working as I expected.  I now better understand the difference between key codes which refer to a physical key on the keyboard, and char codes which represent an ASCII character.

I updated the script code posted above and also attached it here along with the calling function in case anyone might be interested.

Best, and many thanks,

Al

ask_for_data _function_definition.lua

get_asked_data.lua

[John Dowson]

Hi Al,

could you create a post in the User Contributions section, and add your lua scripts to that - they will have more visibility there.

I fixed the event.cancel() function yesterday but still need to test. Once I've done that, I'll post a copy here for you to test and adjust your scripts.

John

[John Dowson]

Here's FSUIPCv7.0.4d containing the event.cancel() fix. I hope to release this version officially in the next day or two:  FSUIPC7.exe

John

[ark1320]

4 hours ago, John Dowson said:

Hi Al,

could you create a post in the User Contributions section, and add your lua scripts to that - they will have more visibility there.

I fixed the event.cancel() function yesterday but still need to test. Once I've done that, I'll post a copy here for you to test and adjust your scripts.

John

Sure -- be glad to do a brief writeup and put the 'ask' scripts into the Contributions section.  I also have a TOD_PauseMSFS.lua that will pause MSFS at a user set Top of Descent time that makes use of your basic script, so will also put that into the Contribution section.

Al

[ark1320]

4 hours ago, John Dowson said:

Here's FSUIPCv7.0.4d containing the event.cancel() fix. I hope to release this version officially in the next day or two:  FSUIPC7.exe

John

Great - thanks.

The get_asked_data.lua script uses ipc.exit() to cancel all the pending events since the script ends when the data is entered, but the TOD_PauseMSFS.lua script mentioned above will make good use of the event.cancel() fix since the script may run for hours (until TOD) after the TOD time is entered. So can't use ipc.exit() to cancel events.

I would like to clarify something about the mytimer() function in your original askTest.lua script.

function mytimer(time)                            
    closeafter = closeafter - 500
    if closeafter <= 0 then
        wnd.close(w)
        w = 0
        event.cancel("mytimer")
       .............

         event.cancel("keyPressed")
        ipc.log("No number entered: timed-out")
    end
end

My understanding is you use event.timer(500, "mytimer") to call this function every 500 ms (milliseconds) to check if data has been entered within the allowed time period of 3600000 ms or 60 minutes, and if not all events are cancelled.  My question is, if in a request for data application we were to set the allowed time for data entry to a much smaller time, say 5 minutes (300000 ms) could we just use a 5 minute interval, e.g. event.timer(300000, "mytimer')?  What I'm asking is why check repeatedly if data has been entered instead of just checking once at the end of the total allowed data entry time? Does this perhaps have something to do with the max allowed value for the interval in ms?

Thanks,

Al

[Pete Dowson]

25 minutes ago, ark1320 said:

What I'm asking is why check repeatedly if data has been entered instead of just checking once at the end of the total allowed data entry time? Does this perhaps have something to do with the max allowed value for the interval in ms?

In the case of the "ask" substitute, you' wouldn't want to delay the supply of the reply and the termination of the plug-in. So check at the sort of period you would allow for the reply to be entered, whether long or short. And terminate as soon as done so it can be invoked again if needed rather than wait for the expiry of the time allowed.

In your new one i assume you'll want to check for the arrival at TOD more often than 5 minutes or you could be 5 minutes late in detecting it.

I don't know of any specific limit on the timer -- it is using a facility in Windows  Looking at that it says:

Quote

Type: UINT

The time-out value, in milliseconds.

If uElapse is less than USER_TIMER_MINIMUM (0x0000000A), the timeout is set to USER_TIMER_MINIMUM. If uElapse is greater than USER_TIMER_MAXIMUM (0x7FFFFFFF), the timeout is set to USER_TIMER_MAXIMUM.

so the max timer works out at 2,147,483 seconds, or nearly 25 days.

Pete

 

[John Dowson]

1 hour ago, ark1320 said:

My understanding is you use event.timer(500, "mytimer") to call this function every 500 ms (milliseconds) to check if data has been entered within the allowed time period of 3600000 ms or 60 minutes, and if not all events are cancelled.  My question is, if in a request for data application we were to set the allowed time for data entry to a much smaller time, say 5 minutes (300000 ms) could we just use a 5 minute interval, e.g. event.timer(300000, "mytimer')?  What I'm asking is why check repeatedly if data has been entered instead of just checking once at the end of the total allowed data entry time?

Sure. It is what it is as I based the script on an existing script and I didn't modify the timer interval. You can just set it to your time-out value, not decrease the timer and cancel both timers and exit the script when the timer function is called, as indicated by Pete's comment:

40 minutes ago, Pete Dowson said:

So check at the sort of period you would allow for the reply to be entered, whether long or short.

 

41 minutes ago, Pete Dowson said:

And terminate as soon as done

This is already implemented on the event.key() function for the return/enter key.

John

[ark1320]

1 hour ago, Pete Dowson said:

In the case of the "ask" substitute, you' wouldn't want to delay the supply of the reply and the termination of the plug-in. So check at the sort of period you would allow for the reply to be entered, whether long or short. And terminate as soon as done so it can be invoked again if needed rather than wait for the expiry of the time allowed.

With the "ask" substitute the reply happens as soon as the data is entered assuming the data is followed by the required Enter key, so it seems a simple 'one-time' timeout check at the end of the allowed data entry time will work fine.  (Edit: I see John just said the same above)

1 hour ago, Pete Dowson said:

In your new one i assume you'll want to check for the arrival at TOD more often than 5 minutes or you could be 5 minutes late in detecting it

 

1 hour ago, Pete Dowson said:

so the max timer works out at 2,147,483 seconds, or nearly 25 days.

With the current TOD pause script I check the time every 10 sec using a timing loop based on ipc.sleep(10000). I thought 10 sec was plenty accurate even for short times while not putting any significant load on the PC.  But, based on your event.timer info (25 days, WOW!) , I might as well do away with the timing loop and just use a "one time check" timer like event.timer(TODtime,  "pause_sim"). As I understand it, this TOD event timer will replace the event.timer() used to get the TOD pause time value from the user since you can have only one event timer active at a time per Lua script.  Pending (future) TOD pauses can be cancelled by simply rerunning the script -- i.e, the script works in a toggle TOD pause on - TOD Pause off manner.

Thanks for the timer info,

Al

[Pete Dowson]

1 hour ago, ark1320 said:

With the current TOD pause script I check the time every 10 sec using a timing loop based on ipc.sleep(10000). I thought 10 sec was plenty accurate even for short times while not putting any significant load on the PC.

Yes, sounds reasonablye. You can then only be 10 secs late detecting TOD.  In fact, assuming a speed of, say, 500 knots cruise, you could use 100 seconds and still only be about 1.5 nm late at max (less than 1 nm on average).

2 hours ago, ark1320 said:

As I understand it, this TOD event timer will replace the event.timer() used to get the TOD pause time value from the user since you can have only one event timer active at a time per Lua script.  Pending (future) TOD pauses can be cancelled by simply rerunning the script -- i.e, the script works in a toggle TOD pause on - TOD Pause off manner.

Sorry, you've lost me there. i didn't understand any of that. 😞

Pete

 

[ark1320]

5 hours ago, Pete Dowson said:

Sorry, you've lost me there. i didn't understand any of that. 😞

Pete

 

Sorry, my fault, let me try to be clearer. I have rewritten the TOD pause script. When run it first displays an "Enter time to TOD" message in the wnd window and a data entry event.timer() starts which gives the user 2 minutes in which to enter the desired time until TOD pause.  If there is no entry within the time limit the script closes with a timeout message.

If a TOD time is entered successfully, a TOD event.timer() is started which, as I understand it, will automatically cancel the data entry event timer. A TOD Pending message is displayed until the TOD event timer times out and the called timer function pauses the sim.

As for cancelling a pending pause, I've changed things so once a TOD pause is pending, hitting Enter exits the script thus cancelling the pending pause. 

I wanted to ask if I am correct that rerunning a running script automatically cancels all the events in the first instance of the script?

Best,

Al

 

[John Dowson]

8 hours ago, ark1320 said:

If a TOD time is entered successfully, a TOD event.timer() is started which, as I understand it, will automatically cancel the data entry event timer.

Yes, thats the case. Only one timer per lua plug-in.

8 hours ago, ark1320 said:

I wanted to ask if I am correct that rerunning a running script automatically cancels all the events in the first instance of the script?

Yes, as re-running a script kills the thread in which the original was running.

John

[ark1320]

On 1/5/2021 at 4:13 AM, John Dowson said:

Here's FSUIPCv7.0.4d containing the event.cancel() fix. I hope to release this version officially in the next day or two:  FSUIPC7.exe

John

John -- does the latest FSUIPC6 version have the event.cancel() bug? I'm asking because I want to use event.key() functions in a pause script for both MSFS and P3Dver4.5/5.1.

Al