ark1320

Could someone please confirm that Offset 60A4, GPS String ID of next waypoint, works in P3Dv4.5 or P3Dv5.1. I can get Offset 6048 (or 60EC), GPS Distance to next waypoint, and Offset 6081, String ID of previous waypoint, to work But not Offset 60A4. I get no response at all as if the code won't run, even if I test for a nil response. The simple test code I'm using (that does work with offset 6081) is: next_waypt = ipc.readSTR(0x60A4,10) if next_waypt == nil then next_waypt = "NIL" end ipc.writeSTR(0x3380, next_waypt); ipc.writeSW(0x32FA, 3); ipc.sleep(3000) The next waypoint for this test is just a VOR, or an airport ICAO code, so the actual waypoint String ID is 4 characters max. Thanks for any ideas, Al FSUIPC ver 6.0.12

Andreas -- In my view, FSUIPC tries to provide access to as many existing sim events and variables as possible. Note there is no TOD variable provided by the sim. However, third party add-on programs, such as SimCars (or Lua scripts) can calculate a TOD point based on sim variable information it gets via FSUIPC , and also likely from additional information (flight plan, WX, etc) that the user enters directly into the third party program. So FSUIPC is a utility, a tool, to facilitate such calculations and the subsequent TOD pause. My $0.02 . Al

I'm not familiar with SmartCars, but I can see that if SmartCars knows the flight plan and tracks the flight progress it could calculate a TOD point, and then use FSUIPC to pause the sim when that point is reached. It's calculating the TOD point that I don't think FSUIPC does. Al

Well, interesting. I think the earliest version of FSUIPC I've used is FSUIPC4. I just don't recall a FSUIPC "TOD feature", and when I search the current Offset Status documentation for FSUIPC6 I don't find any reference to TOD. There certainly is the ability to Pause the sim, or to detect that the sim is Paused (Offsets 0x0262 and 0x0264), but these offsets are not tied to the TOD. There are also events (controls) for Pause Off, Pause On, Pause Toggle, and Pause Set (not sure what this does -- maybe pauses or unpauses the sim based on the state (0 or 1) of a variable). Again, I don't see these events as necessarily tied to TOD. I expect John or Pete will comment at some point to make things clear. Al

John will have to answer that, but I don't think any previous version of FSUIPC had that feature. Seems to me FSUIPC would have to know or have access to some details of your flight plan (e.g., the desired BOD waypoint and desired BOD altitude). Al

That could be. At the moment FSUIPC7 cannot access MSFS Lvars or Hvars, but John Dowson has said he is looking into how FSUIPC7 might be able to do so some time in the future. Al

So using the above we can estimate the time to TOD as Time to TOD(hr) = [Current Total Dist to BOD point - Descent Dist]/ Ave Ground Speed =[Current total Dist to BOD point - 3 x Descent Alt Change]/Ave Ground Speed Al

BTW, a good estimate for the distance required for a 3 deg descent is Descent Dist(NM) = 3 x altitude change in 1000s of feet. So, for example, if you will need to lose 25,000 ft from the TOD to the BOD, we get Descent Dist = 3 x 25 = 75NM And the rate of descent that will be required is Descent rate(ft/min) = 5 x Ground Speed(NM/hr) This is a 'ballpark' estimate as well since chances are you ground speed will not be constant throughout the descent. Al

Just to clear, the pause Lua script has nothing to do with smartcars or any VA. If you can estimate the time until TOD, then you can manually set the sim to pause accordingly. But the script is time based; I'm not aware of anything inherent in FSUIPC that will calculate the TOD point in NM for you and then pause the sim based on that distance from a BOD waypoint. Al

You might find this Lua script useful. It lets you pick a future time to pause MSFS. https://forum.simflight.com/topic/91605-set-future-pause-for-msfs-or-p3d/ Al

The offset status spreadsheet that's included with the latest version 7.0.4 of FSUIPC7 shows offset 0E8E in red, Not Working. Al

The screen shot I added above shows how it looks on both a 24" and 32" screen with the "We are" replaced by two spaces to center things a bit. Al

Problem showed up on both 24" and 32" screens. It got my attention because I think it all fit OK at one point, so I wondered what had changed on my system. In any case, replacing the "We are" with two spaces in the bat file text line centers things so all fits fine -- at least for now! 🙂 Al

I noticed today the word cabin is cut off in the FSUIPC7 opening screen as shown below . While this is certainly not important in itself, it makes me wonder if I have a wrong setting somewhere that will cause a problem elsewhere. So I would like to know if anyone else sees this. I am using FSUIPC version 7.0.4. If this issue is unique to my setup I should probably try to figure out what changed. Thanks, Al

John recently said FSUIPC7 does not currently have the ability to read and write MSFS Lvars, but may be able to do so some time in the future. Al

SetPauseP3Dv4&5.lua can be used to pause P3Dv4.5 or P3Dv5.1 from 1 minute to days after the script is run. Put the script in the same folder as FSUIPC6.ini and assign a key or button to activate it in the usual way. When the script is first run you will see where here an example pause time of 135 minutes has been entered, and as a result you would see As the script runs the time will be counted down in minutes and displayed so after two minutes with the above example you would see Finally, just before the sim pauses you will see To cancel a pending (future) pause, just rerun the script and select the cancel option (*). You will see a brief cancel message. The sim pauses in the usual manner and can be unpaused with the standard "P" key. The sim pause function is a toggle operation. So if you set a future pause time, and then manually pause the sim using the P key, then when the pause time is reached the sim will be unpaused by the script. While this is somewhat interesting, I'm not sure how useful it is. The script SetPauseFSX.lua below is very similar to the above, but for FSX. SetPauseP3Dv4&5.lua SetPauseFSX.lua

Based on my experience with others sims, if the aircraft developer does not provide the needed key bindings, using FSUIPC to manipulate controls that are very specific (or unique) to a particular aircraft usually requires access to the associated sim Lvars (Local variables). Currently FSUIPC7 does not have access to MSFS Lvars so I think you may be stuck with operating these controls with the mouse, at least for now. Al

Just info for anyone who might be interested, I have found Offset 0x132C [NAV/GPS Switch or GPS Drives Nav1] works for reading and writing. Using this offset I am able to switch between GPS and VLOC (NAV) modes for default aircraft using the G3000 (with and without mods), the G1000 (with and without mods) and the GNS 530/430. Al

That explains the script behavior I observed - thank you. Al

I have noticed that activating log Lua Plugins with FSUIPC7 has a major impact on how quickly MSFS responds to a key input that triggers a Lua script. I have a Lua script that records the ipcPARAM value each time the script is called. The script is called by each of the numberpad num keys such that if called by the 4 key, it records the ipcPARAM value of 4, if called by the 2 key it records the ipcPARAM value of 2, etc. If the script is called when Lua Plugins logging is off I can 'enter' a data value like 245 by calling the script 3 times with the numberpad 2, 4, and 5 keys, and I can do this at a 'normal' typing rate. However, if log Lua Plugins is on, I have to pause for a few seconds between number key inputs (i.e., between successive calls of the script) or else the inputs (ipcPARAM values) are 'missed' for some reason -- perhaps the script does not have time to complete between calls because of an initial logging delay. What is particularly strange, however, is that if Log Lua Separately is on, I can again enter data (repeatedly call the script) at the normal rate -- no inputs (ipcPARAM values) are missed. So it seems something is significantly different in the logging process between logging Lua Plugins and Log Lua Separately, at least on my system. I don't know if this logging induced delay 'issue' is unique to my system for some reason, or is to be expected when logging Lua Plugins is on, or what. I'm just making what I observed known since I spent a considerable amount of time trying to figure out why I was having certain number entry problems when another user with the exact same plugin was not. It turned out I had log Lua Plugins on, and he didn't. So just FYI. Al

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

The SetPauseMSFS&P3D.lua script attached below makes use of the FSUIPC Lua event and wnd libraries (as suggested by John Dowson) and can be used to pause MSFS or P3Dv4.5/v5.1 from 1 minute to days after the script is run. When run, the script asks for a pause time and if none if provided within two minutes the script closes with a brief message. If a pause time is entered, for example 260 minutes until a Top of Descent, the user would see Then after hitting the Enter key the display would change to This display will change once per minute as the time to pause counts down towards zero. If the user decides to cancel the pending (future) pause with the Enter key, the display briefly changes to When the pause time is reached, the sim pauses and looks just like a pause had been initiated with the ESC key. To cancel a paused sim you just need to click on Resume. This script uses the wnd (Window ) library for display, so you can move the display window with the arrow keys and use the ctrl + arrow keys to resize the window. The window must have the focus to do this. The new window display position will be stored in your FSUIPC .ini file. As an alternative to using the arrow keys you can directly edit the window position and size coordinates in the FSUIPC7.ini file. Look for the entry under [ExtWindow]. It seems best to do this when FSUIPC7 is not running. You may also have to edit the window size and position in the lua file. The script requires a registered copy of FSUIPC. If using MSFS, at least FSUIPC7 version 7.0.4 is required, or at least FSUIPC6 version 6.0.12 for P3D. Al SetPauseMSFS&P3D.lua

The files ask_for_num() and get_asked_num() attached below are versions of the files ask_for_data() and get_asked_data() (post above) but only work for purely numerical values -- no letters -- and as a result there is less delay in detecting an input since each time called get_asked_num() does not require establishing events for all the lowercase and uppercase letters. Al ask_for_num_function_def.lua get_asked_num.lua

Below is a brief example of how to do what John has suggest above. Note however that this example uses the files ask_for_num() and get_asked_num() which are attached below. These are versions of the files ask_for_data() and get_asked_data() but don't work for letter characters, and as a result there is less delay in detecting an input since each time called get_asked_num() does not require establishing events for all the lowercase and uppercase letters. Using ask_for_data() and get_asked_data() would also work of course. Script get_asked_num() goes in the same folder as FSUIPC7.ini. Note that whether using ask_for _data() or ask_for_num() you will have to edit the function definition to insert the path to your Lua files location. Al -- Get_CRS&HDG.lua function ask_for_num(request_string) -- use for number only data ipc.set("NUM_REQUEST", request_string) ipc.set("NUM_ANSWER", request_string) ipc.runlua("C:\\Users\\... your path to Lua files...\\get_asked_num.lua") -- enter your path here repeat num_returned = ipc.get("NUM_ANSWER") ipc.sleep (100) until num_returned ~= request_string return num_returned end -- Example Main Program while true do CRS1 = ask_for_num("Enter 3 Digits for Course ") if CRS1 == "*" then -- * is error char ipc.sleep(100) else break end end ipc.writeUW(0x0C4E,CRS1 ) while true do HDG = ask_for_num("Enter 3 Digits for Heading ") if HDG == "*" then -- * is error char ipc.sleep(100) else break end end HDG = math.floor(HDG*65536/360) -- format for FSUIPC, no decimal places ipc.writeUW(0x07CC,HDG ) ask_for_num_function_def.lua get_asked_num.lua

I have a number of Lua scripts that make good use of ipc.ask(). Unfortunately, ipc.ask() does not work reliably in MSFS due to current limitations of the SDK. So with the significant help of Pete and John Dowson I developed the two attached Lua scirpts that work together to provide a temporary (hopefully) alternative to ipc.ask(). The ask_for_data_function_definition is a function that when invoked by an instruction asking for data in your main Lua script, in turn runs the get_asked_data.lua script that must be in the same folder with FSUIPC7.ini. The get_asked_data.lua script returns the requested data or an * (asterisk) indicating an error. Perhaps this is best explained by example. If you had a script that would normally use ipc.ask() it might look like this: -- Your Program code ........... alt = ipc.ask( "Enter the new desired altitude") ......... gs = ipc.ask("Enter ground speed") ........ -- end of Your Program code With the alternative to ipc.ask we have this. -- ask_for_data_ function function ask_for_data(request_string) ipc.set("DATA_REQUEST", request_string) ipc.set("DATA_ANSWER", request_string) ipc.runlua("C:\\Users\\..... insert path to your Lua scripts....\\get_asked_data.lua") --note Lua syntax requires the use of the double back slashes. repeat data_returned = ipc.get("DATA_ANSWER") ipc.sleep (100) until data_returned ~= request_string return data_returned end -- Your Program code ........... alt = ask_for_data( "Enter the new desired altitude") --ipc.ask() alternative function call ......... gs = ask_for_data("Enter ground speed") --ipc.ask() alternative function call ........ -- end of Your Program code So the major change is the ask_for_data(request_string) function has been added to the original program code. When the application program gets to an ask_for_data() request, the user has 2 minutes to provide the data (followed by the Enter key) or an * is returned to signal a data request timeout error has occurred. The returned data string can consists of upper and lower case letters, numbers, space, and Numberpad characters with NumLock on. At the beginning of the main ask_for_data code is the variable error_string, currently set to "*". If the asterisk is a valid value in your application, you can change this, e.g., error_string = "!ERR!", etc., that better fits your application. Whatever you use, you probably would want to test for it in your application. The data timeout time is set by the variable data_entry_time, also located at the top of the main get_asked_data code, and so can be easily changed as well. Once a request for data window is displayed, there is a slight delay (as second or two) before a key stroke will be recognized. I think this delay is caused by the time it takes the ask_for_data() script to establish all the key detection events each time it is run. Edit: See post below if only using purely numerical data. Al ask_for_data _function_def.lua get_asked_data.lua