ark1320

I put the scripts called P3D_Flt_Params.lua and MSFS_Flt_Params.lua in the User Contribution area. Post is called Display P3D and MSFS Aircraft Flight Parameters Al

Here are two small Lua scripts I call P3D_Flt_Params.lua (for P3D) and MSFS_Flt_Params.lua (for MSFS2020) that display trim values, the flaps setting, and landing gear position in a small window. The possible landing gear values are Up, Down, and Transit (when gear is moving). The scripts can be expanded to include other parameters if desired. Note at the top of the scripts you have to enter a value for flaps_max. Since the max flaps value can be different for different aircraft, if you have a few aircraft with different values for this, you can simply just have a few copies of the script with different names, e.g., Learjet_Params.lua. C402_Params.lua, etc., or of course you can change the value in the script as needed (setting the max flap value based on the aircraft name in the aricraft.cfg file is another but more involved approach for this). Note however, the total number of characters in the script name to the left of the .lua cannot be more than 16. You can also make changes at the top of the scripts to resize or reposition the windows. Assign a key or button to a script to toggle the window on and off. Al P3D Window MSFS Window P3D_Flt_Params.lua MSFS_Flt_Params.lua

Hi John, I reinstalled FSUIPC7 and all is now working. I should have thought of trying that before bothering you with this -- sorry. Al

John, It seems under SU11 FSUIPC7 no longer will auto-start luas when FSUIPC7 is started/restarted when MSFS is running and has an aircraft loaded, at least not on my system. Al

Just as another data point, so far all my key and button assignments seem to work with today's SU11 update. Al

Great info, thanks John. A delta of 0.009 radians equates to a bearing change of about 1/2 degree. And do subsequent event.offset function calls kill the previous call if it is still running? I'm asking because I have a delay [ ipc.sleep() ] in the called function. Al

Hi John, I have an application using the code event.offset(0x6050, "DBL","gps_course_fcn"). My question is, with a high precision ( I assume) data type like DBL, is there some tolerance you use to determine if the value has changed, or will any change in the "DBL" value trigger event.offset? Also, will a subsequent event.offset call to the function gps_course_fcn kill an existing instance of that function? Thanks, Al

John, Works as advertised! Thank you, Al

What are the definitions of Frame and VisualFrame? I ran some experiments with the little test program above. Could not get consistent results, however, perhaps other issues such as the loading time of the script, etc played a role. Does Frame refer to the basic rate at which the sim is running-- maybe around 18Hz (55ms), at least that was what P3D ran at I believe. Or does Frame refer to the FPS you happen to be getting at that time? Does VisualFrame relate to the refresh rate of your monitor, or maybe that is what is related to the FPS? My sim FPS is locked at 30Hz (33.3ms). Btw, I assume whatever delay is needed, it is also needed after the ipc.createLvar() command before the value being set by that command is available -- true? Thx, Al

I did a little more testing. In summary in case others are interested, my understanding is: If an Lvar is created using ipc.createLvar(), the reload WASM command is not needed. If an Lvar is created with calculator code you need to reload WASM, but only once for that Lvar within that Lua script. I suppose once FSUIPC "knows" about that Lvar, it knows for the whole script. Follow the WASM reload with a 200MS delay. If an Lvar is updated with calculator code, that needs to be followed by a delay of about * 200ms (something greater than 166ms) if that Lvar will subsequently be used in an ipc command. Lvars used only within calculator code commands, or only within calculator presets (I assume), do not need either WASM reloads or 200ms delays. Thanks again, Al * EDIT: See posts below for delay time options.

So if I update an Lvar using calculator code, and subsequently only use that Lvar in more calculator code, I don't need to reload WASM. But if subsequently I will use that updated Lvar in some type of ipc command, I do first need to reload the WASM followed by a suitable delay like 200ms. And this is true whether or not the Lvar was previously "created" by the code or already existed in the sim code. So the sequence reload WASM followed by a delay may be needed a number of times throughout a Lua script if the Lvar is repeatedly updated in calculator code and then used with ipc commands. I think I got it. Thank you very much for the explanations and developing this capability to execute XML within a Lua script. Al

In XML the first use of an Lvar "creates" it if it does not exist which can be very useful. In the little test example below, the Lvar (L:AE_FD, Bool) is created by the Lua script -- i.e., it does not exist prior to the script running. In the third line I try to update the value of (L:AE_FD, Bool) but this does not work and the if statement fails (if I display fd_val it shows as 0). However, if after running the script I open FSUIPC and List the Lvars (without first doing a manual reload,) the Lvar AE_FD is listed with a value of 1. So I don't understand why the if statement failed. If I leave out the ipc.reloadWASM() command the script also does not work. So I assume I don't understand how the ipc.reloadWASM() command works. Ideas anyone? Thanks, Al ipc.execCalcCode(" 0 (>L:AE_FD, Bool) ") -- create Lvar ipc.reloadWASM() -- make Lvar known ipc.execCalcCode(" 1 (>L:AE_FD, Bool) ") -- update Lvar fd_val = ipc.readLvar("L:AE_FD") if fd_val == 1 then ipc.control(66288) -- toggle FD end

Ok, thanks for the info John. I wasn't asking you to change anything. I thought there might be a special EOL character or string concatenation character that would work with the current implementation. Thanks again for this calculator XML code capability -- very useful! Al

FSUIPC7 calculator code is a wonderful capability! The examples I've seen always express the XML code on a single line. XML code can get "long" ( which I assume is why up to 1023 characters can be used) and I was wondering if there might be a way to use multiple lines like in the example below. What I've tried has not worked. ipc.execCalcCode (" (L:AP_PFT_COUNTER, number) 21 >= if{ 1 (>L:AP_PFT_POWER,bool) 0 (>L:AP_PFT_COUNTER_ENABLE,bool) 0 (>L:AP_PFT_COUNTER, number) } els{ (A:CIRCUIT ON:9,bool) 0 == if{ 0 (>L:AP_PFT_POWER,bool) 0 (>L:AP_PFT_COUNTER, number) 0 (>L:AP_PFT_COUNTER_ENABLE,bool) 0 (>L:AP_MEM,bool) 0 (>L:YAW_DAMPER_MEM,bool) (>K:YAW_DAMPER_OFF) (>K:AUTOPILOT_OFF) (A:AUTOPILOT FLIGHT DIRECTOR ACTIVE,Bool) 1 == if{ (>K:TOGGLE_FLIGHT_DIRECTOR) } } } ")

John, If I exit FSUIPC7 while the sim is running, say to make a change in a Lua script that is listed under [Auto], and then restart FSUIPC7 by directly running the FSUIPC7.exe file (e.g., double click it), it seems the Lua scripts listed under [Auto] are not reloaded. So the sim has to be restarted to get the [Auto] scripts restarted. Is there a way to trigger the automatic restart of the [Auto] scripts without restarting the sim? Thanks, Al

John -- with the new beta 7.3.9h all axes continue to work as I reported above, and a brief test showed I'm able to read and write Lvars and activate Hvars. Al

Just as another data point, all my axes, including toe brakes, are working as expected when I fly using Send direct to FSUIPC Calibration, although I'm not sure if the Send direct to FSUIPC Calibration is grayed out or not. I don't recall how it normally looks. Aircraft is the Flysimware C414, using Fulcrum throttle, Saitek rudder pedals, and Saitek TQ. FSUIPC7 ver 7.3.9f. For example, this is what I see: Al

Thanks John, beta 7.3.9f works for me. Al

Ignore or delete this post. I just saw on another FSUIPC subforum John is working on a fix for Lvars and Hvars. Al I would appreciate it if someone would confirm Hvar activation is working in SU10 with FSUIPC ver 7.3.8. Thanks, Al

Great -- thanks very much!

Q1. Is there a way to insert a timed delay into a multi-line macro? I thinking of something like using ipc.sleep() in a Lua script. So you might have: [Macros] 1= Name 1.1=action1 1.2=action2 ;a delay 1.3=action3 Q2. In the Advanced users guide in reference to a multi-line Lvar macro it says, "However, unlike the usual multi-line macros, those using an L:Var cannot be mixed with any other parameter types or other L:Vars". I take this to mean that the multi-line Lvar macro can only take different actions with the same Lvar, e.g, you could set the Lvar in one line, and then maybe Inc that value in the next, and then maybe toggle the lvar, etc. So all (any) actions have to be on the same Lvar. Or do I misunderstand the line from the Advanced users guide? Thanks, Al

Yes, I noticed that as well. 🙂 Al

I was able to get the script working by adding the line below in the double push code section. For some reason after a double button push was detected and the AP turned off, apparently an additional push was detected and the AP turned right back on. I have to wonder if there might be some kind of "delay" due to how MSFS responds to a button push such that the 2nd push of a double push sequence shows up "again" outside the 500ms window. I looked at the log files and they show the AP was turned off, and then back on about 875 msec later. I did try using a button on a different controller in case the yoke button was noisy, but the results were the same. Thanks for the help, John. So in case if helps someone else here is what I ended up with. One button push to turn on the AP and YD, and a double push to turn them off. I am not using the "long push" option. function timebutton(test) while true do time2 = ipc.elapsedtime() if (time2 - time1) > interval then ignorepress = false return false end if ipc.testbutton(joy, btn) == test then time1 = time2 return true end ipc.sleep(20) end end function buttonpress(j, b, du) -- ipc.control(66375) --toggles GPS/VLOC and NAV for testing purposes if ignorepress == true then ignorepress = false return end -- Note time button was pressed time1 = ipc.elapsedtime() time2 = 0 if timebutton(false) then -- First press / release counts: see if there's another if timebutton(true) then -- got another press in time, look for release if timebutton(false) then -- this was a double press, AP and YD OFF ipc.control(65791) -- turn AP off ipc.control(66070) -- turn YD off. Button on yoke should turn YD off when same button turns AP off. ignorepress = true -- added this line end else -- This was a single press, AP and YD on ipc.control(65792) -- turn AP on ipc.control(66069) -- turn YD on ignorepress = false end -- else -- This was a longer press, this is not used. -- do something here for long press end end -- ************************ Main Program ********************************** joy = "Y" -- Fulcrum yoke btn = 0 -- red button on yoke interval = 500 -- 1/2 second (500ms) press , gap, press limits ignorepress = false -- Enable event on button being pressed (only) event.button(joy, btn, 1, "buttonpress")

Well, after cleaning out some of my apparently not so brilliant test code (☹️), the basic script works, but with a bug. I am using the script to turn the AP on and off -- one push of the yoke button to turn the AP on, a double push to turn the AP off. The single push does turn the AP on, but the double push first turns the AP off and then immediately turns if back on. So I seem to have a timing issue that I need to figure out. Thanks. Al

Hi John, Yes, the script is running from an [Auto] section. In addition to the [Auto] section, for testing I assigned a 2nd button to call the script, and when the script is called either initially by [Auto] or by the 2nd button, the uncommented control near the bottom of the script does work. However, when uncommented, the control inside the buttonpress function does not work when the button that is to be detected by event.button() is pushed (I only uncomment one of the controls at a time to see what is happening). I will get the files you requested. Thanks, Al