ark1320

While waiting for John's help, here's a few things you could try if you haven't: - In the Lua script, add in some additional sound.play("bong.wav",x) lines (separated with delays) but all with different sound device #s ( none, 1, 3, 4 etc) "just in case" to see if one of them works. - Put a copy of the sound file in the same location as your Lua script, adjust the sound path accordingly, and see if that works (I'm assuming that won't be the F drive). - If you double click the wave file, an app should open and play it -- does that work? In other words, are you sure the wav file is good? - If your Lua script calls different functions, etc, make sure the sound code part of the script is actually being executed. You could make a separate Lua script just with a sound path, sound play and delay instructions and see if that works. - try a different wav file. Al

No, rephrase it for what purpose at this point? It was just a beginner's mistake and maybe seeing that will help someone else. I'm brand new to both Stream Deck and Pilot's Deck, and as a start for a couple of days had been assigning "hot keys" to buttons using the standard Stream Deck capability. So that was my first thought with Pilot's Deck. As I learn more both about Stream Deck and Pilot's Deck I get a little "smarter" in how to use them. 😉

OK, I understand. I'm familiar with sim XML coding, so I used calculator code with a simple button to either toggle autopilot Approach (short press) or BC (long press) on and off. Thanks, Al

Seems if you just keep typing and ignore the location of the Ckeck-Symbols it works, so all good. I'd like to assign a key (or key combination) to a Stream Deck + button, but don't see how to do that. This would allow executing a default MSFS key control binding with a Stream Deck + button. I could certainly do this using the standard Stream Deck "Hotkey" assignment, but wanted to take advantage of Pilot's Deck capability to send a second keystroke using the long press option. If I can't send a keystroke directly using Pilot's Deck, I could use tiny Lua scripts to send the keycodes and then use Pilot's Deck to call the scripts, but that's seems like a cumbersome solution. Thanks, Al

Finally just got it to work. I learned you have to ignore the little white round edit symbol in the variable field -- just keep typing. Trying to move the edit symbol out of the way to "make space" for typing the rest of the variable I think was a problem. And I think the slash was also an issue. I ended up using "feet per minute". Thanks again for an excellent plugin! Al

Great program -- many thanks! While setting up a Stream Deck + dial stack in MSFS with a Display Value with Switch I ran into a problem because the variables (A:AUTOPILOT VERTICAL HOLD VAR, feet/minute) [ also tried (A:AUTOPILOT VERTICAL HOLD VAR, feet per minute)] and (A:AUTOPILOT AIRSPEED HOLD VAR, Knots) where not recognized in the variable address field. The tool tip said "Please match the requested format". I have not been able to figure out what is wrong. These variables are from the MSFS SDK. I had no problem setting up two other similar encoders. Here is the entries for the Vertical Speed part: This is the rest of the variable entry I also was unable to set up a button Display Value because again the variable was not recognized by Pilot's Deck. I am using FSUIPC7 ver 7.3.20 and Pilot's Deck ver 0.7.10. Thanks for any suggestions. Al

You are very welcome -- glad to help out a bit where I can. Thanks for letting me know changing the gear_and_flap_chk_alt value did what you wanted. Now if you want to use the script with a different plane and do want the gear and flaps check, just copy the script, give it a slightly different name, and put back a reasonable value for the gear_and_flap_chk_alt setting. So you then have two Approach Callout scripts, one with and one without a flap and gear check. Al

I think as John suggest above it is best to just comment out some lines of code rather than actually delete code. If you don't want to try that here is something easy you can try. At the top of the script in the User Settable Parameters area is this line of code which sets the Radar Altimeter altitude (in feet) at which the gear and flap call out happens: gear_and_flap_chk_alt = 800 -- RA for callout gear/flap check Try changing the 800 to a value that will never happen, such as 60000 or 0 (unless maybe you land gear up!!) Now that won't remove any code to make the script smaller if that is what you want to also do, but it should stop the call out of the gear and flap positions. It will also be easy to go back and put in a reasonable value should you want to do that for another plane sometime in the future. Let me know how that works. Al

Below is a version of my Approach Callouts script for MSFS. It uses a main LUA scirpt, called ApprCallOutMSFS.lua, and a Sound folder called ApproachCallouts that contains wav files for calling out altitudes, flap settings, gear position and Minimums (Decision Height). This ApprCallOutsMSFS script works for most aircraft with flap settings F1, F2, F5, F8, F10, F13, F14, F15, F17, F20, F25, F26, F28, F35, F38, F40, F45, F48, F50. Altitude callout windows are at 2000ft, 1000ft, 500, 400, 300, 200, 100, 50, 40, 30, 20, and 10 ft. At 800ft(a user settable altitude) there is a callout of gear position and flaps position. The Decision Height callout is based on an aircraft DH Radio Altimeter setting. You will see the path to my sound folder at the top of the main Lua script -- modify the path as needed. There are a few displays as well that appear in a small window (based on the FSUJIPC Window library) which is located in the upper right corner of the screen on my particular setup -- modify the window location as needed. The uploaded zip file below contains the main Lua script and the sound folder with the wav files. There are comments at the top of the script that are worth reading if you plan to try an use or modify it. I'll be glad to try an answer any questions. Although I use this script all the time, it has been years since I originally wrote it for FSX and P3D, and also a while since I updated it for MSFS, so some of the design details are a bit hazy right now . Al ApproachCallouts4MSFS.zip

Below is a version of my Approach Callouts script for MSFS. It uses a main LUA scirpt, called ApprCallOutMSFS.lua, and a Sound folder called ApproachCallouts that contains wav files for calling out altitudes, Decision Height, flap settings and gear position. You will see the path to my sound folder at the top of the main Lua script. There are a few displays as well that appear in a small window (based on the FSUJIPC Window library) which is located in the upper right corner of the screen on my particular setup. The uploaded zip file below contains the main Lua script and the sound folder with the wav files. There are comments at the top of the script that are worth reading if you plan to try an use or modify it. I'll be glad to try an answer any questions. Although I use this script all the time, it has been years since I originally wrote it for FSX and P3D, and also a while since I updated it for MSFS, so some of the design details are a bit hazy right now (age problem!). I've also put this script in the User Contributions subforum and there is a little more info there. Al ApproachCallouts4MSFS.zip

You are right, I had NO idea the term "calculator code" referred to an actual MS/Asobo defined construct. Though it was just a FSUIPC name for a new capability. A search of the MSFS SDK turned up this relevant warning: Always good to lean something new! Thanks, Al

Hi John, It seems the ipc.execCalcCode function does not recognize the use of > for the greater than symbol > in XML code. For example, if I execute the little test code below as shown it works in that the displayed value for Test Var1 is correct, a 3. But, if I then go back and change the 3 to a 4 and change the > symbol to > in the first line so it becomes ipc.execCalcCode(" 4 (>L:TestVar1) "), a 3 is still displayed when the code runs. Unfortunately, for some reason the > syntax (which I don't like) is frequently used for the > symbol in XML coding. I copied some code to use in a Lua script that used the ipc.execCalcCode() function in a number of lines, and it took me a loooong time to figure out it wasn't working because the code I copied used the > syntax. If getting the > syntax to work with the ipc.execCalcCode function is not a viable option, then I think a warning note of some kind in the Lua Library and Advanced Users guide would be a good idea. I looked but did not find anything on this. Thanks, Al ipc.execCalcCode("3 (>L:TestVar1) ") ipc.sleep(500) Test_Var1 = ipc.readLvar("L:TestVar1") wnd.clear(w) wnd.text(w, " Test Var1 = "..Test_Var1) ipc.sleep(5000)

Great info as usual -- many thanks John. Al

John, Will an axis setting, such as rudder axis slope, etc., that is specified in the non-aircraft specific JoystickCalibration section of the FSUIPC7.ini file apply to an aircraft that has an aircraft specific (Profile) JoystickCalibration section if that particular slope (for the rudder axis in this example) is NOT also specified in the aircraft specific profile JoystickCalibration section? Thanks, Al

I don't have any Go Flight equipment or experience, but I see two possible issues here: 1. Offset 0x07F2 is listed as 2 bytes in size in the FSUIPC7 Offsets Status PDF document. So 0x07F2 holds 16 bits, a Word quantity, not a 32 bit Double word quantity. 2. Since the vertical speed can be positive or negative, you are dealing with a Signed, not an Unsigned, value. So given the above, in the event.offset( ) expression suggest you try "SW" , which indicates a Signed 16 bit single Word value, instead of "UD", which indicates an Unsigned 32 bit Double word value . Easy to do, so worth a try I think. Al

Is there a way to display more than one variable on a line using wnd.text()? EDIT: Finally found this syntax works (leaving the post here in case it helps others): wnd.text(w, " Name1 = "..value1.." Name2 = "..value2.."Name3 = "..value3) Thanks, Al

I think this is a MSFS sim bug. It happens with a number of planes that don't have a GPS, even the Wright Flyer! I don't see how this is a FSUIPC7 issue. Al

John -- think you fixed it! I tried commenting out different combinations of presets with // and FSUIPC7 always started when I clicked on the test FSUIP7.exe file. And just in time too, I still have a few hairs left on my head! 😅 I really appreciate you taking the time to look into this issue. I know you are very busy. Best, Al

Sure, will try your test version and report back. Al

Hi John, I 've done some more testing but don't have a conclusion. Here is a pared down test myevents.txt file: Note the first preset is commented out. The sim is not running, and when I double click on the FSUIPC7.exe file FSUIPC7 does NOT start and I get the log file (partial apparently) shown. If I simply uncomment that first preset, FSUIPC7 also does not start. // Next presets for HJet //HJET_AT_TOGGLE#(L:CSC Pushed, bool) ! (>L:CSC Pushed, bool) HJET_AT_FMS_MAN_TOGGLE#(L:HJET_THROTTLE_MAN,bool) ! (>L:HJET_THROTTLE_MAN,bool) HJET_OBS_CRS_INC#(>H:AS1000_PFD_CRS_INC) HJET_OBS_CRS_DEC#(>H:AS1000_PFD_CRS_DEC) //currently using the standard MSFS control bindings Increase/Decrease Autopilot Reference Altitude //HJET_AP_ALT_INC#(L:HJET_AP_ALT_VAR, number) 100 + (>L:HJET_AP_ALT_VAR, number) //HJET_AP_ALT_DEC#(L:HJET_AP_ALT_VAR, number) 100 - (>L:HJET_AP_ALT_VAR, number) ********* FSUIPC7, Version 7.3.17 (25th February 2023) by John Dowson ********* MS Store installation detected: Checking for FS path in 'C:\Users\Al\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt' FS path found = C:\Users\Al\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\ WebSocket server found: C:\Users\Al\Documents\Al's Flight Simulation\AddOns\FSUIPC7\modules\\Utils\FSUIPCWebSocketServer.exe Windows 10 Pro 64 Bit reported as Build 19045, Release ID: 2009 (OS 10.0) Reading options from "C:\Users\Al\Documents\Al's Flight Simulation\AddOns\FSUIPC7\modules\FSUIPC7.ini" Checking the Registrations now ... User Name="Alan Klayton" User Addr="arklayton@comcast.net" FSUIPC7 Key is provided WIDEFS7 not user registered, or expired 63 System time = 28/02/2023 10:33:58 63 FLT path = "C:\Users\Al\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\" 63 Allowing calibration when not assigned with 'Send direct to FSUIPC Calibration' 156 ------------------------------------------------------------------- If I delete the first commented out preset from myevents.txt and double click on FSUIPC7.exe, FSUIPC7 DOES start and I get the log file below. And if I just uncomment the first preset and also uncomment the last two presets, so no presets are commented out, again FSUIPC7 starts! ********* FSUIPC7, Version 7.3.17 (25th February 2023) by John Dowson ********* MS Store installation detected: Checking for FS path in 'C:\Users\Al\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt' FS path found = C:\Users\Al\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\ WebSocket server found: C:\Users\Al\Documents\Al's Flight Simulation\AddOns\FSUIPC7\modules\\Utils\FSUIPCWebSocketServer.exe Windows 10 Pro 64 Bit reported as Build 19045, Release ID: 2009 (OS 10.0) Reading options from "C:\Users\Al\Documents\Al's Flight Simulation\AddOns\FSUIPC7\modules\FSUIPC7.ini" Checking the Registrations now ... User Name="myName" User Addr="myEmail" FSUIPC7 Key is provided WIDEFS7 not user registered, or expired 63 System time = 28/02/2023 10:31:55 63 FLT path = "C:\Users\Al\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\" 63 Allowing calibration when not assigned with 'Send direct to FSUIPC Calibration' 157 ------------------------------------------------------------------- 172 10012 Calculator Code presets have been loaded and are available for use 203 Registered HotKey 'InvokeFSUIPCOptionsKey' (key=0x46, modifier=0x1) 219 FS path = "C:\Users\Al\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\" 219 ---------------------- Joystick Device Scan ----------------------- 219 ------------------------------------------------------------------- 344 LogOptions=00000000 00000001 So I don't understand what is going on. For example, why in the first case is deleting that first preset any different than commenting it out? And if FSUIPC7 starts with no presets commented out, why won't it start with some presets commented out? I get the same results if the sim is running or not, and these presets do work with the HJet. Are there any rules regarding blank lines in a myevents.txt file? Thanks, Al

Delete please. Thx.

If I delete the 4 last lines commented out below in my myevents.txt file, or if I simply uncomment those 4 lines, I can start FSUIPC7 (ver 7.3.17). However, if I leave those 4 lines just commented out, I can not start FSUIPC7 even by manually double clicking on FSUJIPC7.exe. Any ideas why that might be, why the // don't seem to work for those lines -- so strange! It does not seem to make a difference if the sim is running or not. And a lesson here is that a problem with the myevents.txt file can prevent FSUIPC7 from starting. It took me a long time to figure out why FSUIPC7 would not start. Thanks, Al // myevents.txt For my FSUIPC XML Calculator code Presets. See FSUIPC Advanced Users Guide, Pg 48. // This will be listed in the Key or Button assignment control dropdown lists as Flight_Director_Off if the Select for Preset box is checked. FLIGHT_DIRECTOR_OFF#(A:AUTOPILOT MASTER, Bool) 0 == (A:AUTOPILOT FLIGHT DIRECTOR ACTIVE, Bool) 1 == and if{ (>K:TOGGLE_FLIGHT_DIRECTOR) } // turn off FD if AP off and FD on // C414 Heater and Fan TOGGLE_HEATER_SWITCH#(L:CABIN_HEAT,bool) ! (>L:CABIN_HEAT,bool) TOGGLE_CABIN_FAN#(L:GENERIC_Momentary_CABIN_FAN,Bool) 0 == if{ 1 (>L:GENERIC_Momentary_CABIN_FAN,Bool) } els{ (L:GENERIC_Momentary_CABIN_FAN,Bool) 1 == if{ 2 (>L:GENERIC_Momentary_CABIN_FAN,Bool) } els{ 0 (>L:GENERIC_Momentary_CABIN_FAN,Bool) } } // Next presets for HJet HJET_PURPLE_MAP_INC#(>H:AS3000_TSC_Vertical_1_Joystick_INC) HJET_PURPLE_MAP_DEC#(>H:AS3000_TSC_Vertical_1_Joystick_DEC) HJET_BLUE_MAP_INC#(>H:AS3000_TSC_Vertical_2_Joystick_INC) HJET_BLUE_MAP_DEC#(>H:AS3000_TSC_Vertical_2_Joystick_DEC) HJET_ADVANCE_CHECKLIST#(>H:gauges_ha420_sys_Checklist_enter) HJET_AT_TOGGLE#(L:CSC Pushed, bool) ! (>L:CSC Pushed, bool) HJET_AT_FMS_MAN_TOGGLE#(L:HJET_THROTTLE_MAN,bool) ! (>L:HJET_THROTTLE_MAN,bool) //HJET_OBS_CRS_INC#(>H:AS1000_PFD_CRS_INC) //HJET_OBS_CRS_DEC#(>H:AS1000_PFD_CRS_DEC) //HJET_AP_ALT_INC#(L:HJET_AP_ALT_VAR, number) 100 + (>L:HJET_AP_ALT_VAR, number) //HJET_AP_ALT_DEC#(L:HJET_AP_ALT_VAR, number) 100 - (>L:HJET_AP_ALT_VAR, number) EDIT: After more testing it seems the presence of the # character in a preset that is commented out with // prevents FSUIPC7 from starting. I found one solution to the problem described here is to use the semicolon ; to indicate a comment instead of // as suggested in the FSUIPC7 Advanced Users Guide. Don't know if this might be text editor dependent for some reason. I use NotePad++.

Hi John, In the past I've always used a single throttle axis to control both engines of an aircraft. I now am trying to assign a separate axis to each engine of the C414, and in this case the throttles do not have a reverse range. The assignments are profile specific. The calibration looks like this: and the entry in the FSUJIPC.ini file under the profile specific JoystickCalibration section looks like this: Throttle1=-16380,-512,512,16380/32 Throttle2=-16384,-512,512,16209/32 Does this look correct? If so, I don't understand why when a throttle is all the way back, there is 0 OUT for -16384 IN. Is that just the consequence of No reverse zone? And where did the +-512 come from in the ini file entries? I expected the FSUIPC7.ini entry to look similar to what I get when I use a single axis for both engines, e.g. I expected Throttle1=-16384,16383 and Throttle2=-16384,16383 . However, this dual axis setup does seem to work as far as the operation of the throttles in the sim is concerned! So it seems there is something fundamental I don't understand. Thanks, Al

In case it helps anyone, here's what I came up with for the HJet throttles. I currently just use one axis lever to control both engines , but the below can easily be expanded to use two axis levers for those so motivated (each script below gets divided up into two scripts, one for each engine/throttle lever, and two offsets are used, 0xA000 and 0xA002). This single lever solution makes use of three tiny Lua scripts. With the main script the Saitek controller throttle axis value is stored in offset 0xA000. If the value changes by at least a magnitude of 128 the function HJet_Throttle() is called to convert the raw axis value to a number between 0 and 1, and this number is written to the two HJet Lvars that control the two HJet throttles. This script is loaded automatically when FSUIPC starts through the FSUIPC7.ini Profile Specific file entry that looks like this: [Auto.HJet] 1=Lua HJet_Throttle Here is the main script that gets loaded automatically: -- HJet_Throttle.lua function HJet_throttle() throttle = (ipc.axis("T","X") + 16384)/32587 -- need throttle range of 0 to 1 for TQ throttle axis range of -16384 to +16203 ipc.writeLvar("L:THROTTLE1_SET", throttle) ipc.writeLvar("L:THROTTLE2_SET", throttle) end --******************************************** --********* Main Program ******************** --******************************************** ipc.writeLvar("L:THROTTLE1_SET", 0) -- initialize throttles to idle position. ipc.writeLvar("L:THROTTLE2_SET", 0) ipc.writeLvar("L:HA420_ThrottlePos_R", 50) ipc.writeLvar("L:HA420_ThrottlePos_L", 50) event.offsetmask(0xA000, 0xFF80, "SW", "HJet_throttle") -- mask requires a change of at least 128 to trigger the function call. -- Under FSUJIPC7 Axis Assignments, the HJet throttle axis vale has been -- assigned to Offset 0xA000 as Offset Word Set Main script axis assignment. The two tiny scripts below move the HJet throttles between cutoff and idle. There is switch at the bottom of my Saitek throttle axis. When the switch is closed by moving the lever down into the switch, HjetThrotCuttoff.lua is called, and when the lever is moved up out of the switch position HjetThrotIdle.lua is called. --HjetThrotCuttoff.lua ipc.writeLvar("L:THROTTLE1_SET", -1) ipc.writeLvar("L:THROTTLE2_SET", -1) ipc.writeLvar("L:HA420_ThrottlePos_R", 0) ipc.writeLvar("L:HA420_ThrottlePos_L", 0) --HjetThrotIdle.lua ipc.writeLvar("L:THROTTLE1_SET", 0) ipc.writeLvar("L:THROTTLE2_SET", 0) ipc.writeLvar("L:HA420_ThrottlePos_R", 50) ipc.writeLvar("L:HA420_ThrottlePos_L", 50) Setup of the cutoff - idle switch. Frankly, whether or not all the above is a "good" solution for the HJet throttles I don't know. But I have been using this for a while now and it seems to work fine. And of course, this solution is set up to be HJet Profile Specific. Al HJetThrotCutoff.lua 187 B · 1 download HJet_Throttle.lua 985 B · 1 download HjetThrotIdle.lua 184 B · 1 download

In case it helps anyone, here's what I came up with for the HJet throttles. I currently just use one axis to control both engines , but the below can easily be expanded to use two axis levers for those so motivated. This solution makes use of three tiny Lua scripts. The Saitek controller throttle axis value is stored in offset 0xA000. If the value changes by at least a magnitude of 128 the function HJet_Throttle() is called to convert the raw axis value to a number between 0 and 1, and this number is written to the two HJet Lvars that control its throttles. This script is loaded automatically when FSUIPC starts through the FSUIPC7.ini Profil Specific file entry that looks like this: [Auto.HJet] 1=Lua HJet_Throttle This is the main script that gets loaded automatically: -- HJet_Throttle.lua function HJet_throttle() throttle = (ipc.axis("T","X") + 16384)/32587 -- need throttle range of 0 to 1 for TQ throttle axis range of -16384 to +16203 ipc.writeLvar("L:THROTTLE1_SET", throttle) ipc.writeLvar("L:THROTTLE2_SET", throttle) end --******************************************** --********* Main Program ******************** --******************************************** ipc.writeLvar("L:THROTTLE1_SET", 0) -- initialize throttles to idle position. ipc.writeLvar("L:THROTTLE2_SET", 0) ipc.writeLvar("L:HA420_ThrottlePos_R", 50) ipc.writeLvar("L:HA420_ThrottlePos_L", 50) event.offsetmask(0xA000, 0xFF80, "SW", "HJet_throttle") -- mask requires a change of at least 128 to trigger the function call. -- Under FSUJIPC7 Axis Assignments, the HJet throttle axis vale has been -- assigned to Offset 0xA000 as Offset Word Set The two tiny scripts below move the HJet throttles between cutoff and idle. There is switch at the bottom of my Saitek throttle axis. When the switch is closed by moving the lever down into the switch, HjetThrotCuttoff.lua is called, and when the lever is moved up out of the switch position HjetThrotIdle.lua is called. --HjetThrotCuttoff.lua ipc.writeLvar("L:THROTTLE1_SET", -1) ipc.writeLvar("L:THROTTLE2_SET", -1) ipc.writeLvar("L:HA420_ThrottlePos_R", 0) ipc.writeLvar("L:HA420_ThrottlePos_L", 0) --HjetThrotIdle.lua ipc.writeLvar("L:THROTTLE1_SET", 0) ipc.writeLvar("L:THROTTLE2_SET", 0) ipc.writeLvar("L:HA420_ThrottlePos_R", 50) ipc.writeLvar("L:HA420_ThrottlePos_L", 50) Frankly, whether or not all the above is a "good" solution for the HJet throttles I don't know. I'm new to the HJet and I'm not sure I fully understand how its throttles work. But the above solution does seem to work OK. And of course, this solution is HJet Profile Specific. Al HJetThrotCutoff.lua HJet_Throttle.lua HjetThrotIdle.lua