John Dowson

Then you have a UserCfg.opt file in your user' AppData\Roaming\Microsoft Flight Simulator folder for some reason (did you previously have a Steam version installed?). Delete or rename that file and re-install. If that file is present in that folder, the installer (and FSUIPC) will think you are using a Steam install, hence the issue. John

You need to determine what to use for these controls. To do this, use FSUIPC's logging facilities. For the Twist Throttle, first try logging Axes Controls, open the logging console window (Log -> Open Console...), then twist the throttle in the VC and see if anything is logged. If so, try assigning to that. if not, try logging Input Events and again twist the throttle in the VC and see if anything is logged, and if so you can use that (I can help you in assigning an axes to an Input Event if you don't know how to do that). If there are no standard controls or Input Events, the next thing to try is lvars - try listing them (Add-ons -> WASM -> List Lvars) to see if any look appropriate, and if so try setting it (again using the Add-ons ->WASM menu entries) and you need to determine the value range of the lvar. If there is an lvar, I can also help you assign an axis to control this if needed. Not sure I fully understand this...you cannot easily map different ranges of an axis to different controls. To do this, you would need a lua script. Alternatively, you can just assign your axis to the twist throttle control (whatever that is!) and just send the throttle Cut control in an axis range (using the right-hand side of the axis assignment dialog). Throttle Cut is a standard control and should be available for button assignments and for axes range assignments. You cannot use this control as an axis assignment as this makes no sense - axis assignments take a parameter (the axis value) but Throttle Cut takes no parameter - it is usually assigned to a button (and usually a detent button on a throttle). Note I am currently travelling so support will be intermittent until Wednesday next week. John

Sorry but i have no idea what your issue is.... Be aware that FSUIPC is aircraft agnostic (generally, although it does have specific offsets for PMDG aircraft). If any offsets or controls are not working for a given aircraft, it is because the aircraft does not use that event or simvar. It will only detect these if the aircraft you are using uses the standard simvars for these data points. I have no idea what APLv2 is... What is wrong? Proof (i.e. logs)? Explain what you mean by 'gets data'? I think you are either mistaken, or the aircraft you are using is not implemented correctly...there has been no change in the lights offsets (0x0D0C) for many years (if that is what you are talking about). If they are reporting the wrong data, then the aircraft is setting the wrong data and needs to be reported to the aircraft provider. But I think it is more likely you are either misunderstanding something or have an error somewhere. What do you mean by ' If you have an issue, please show me your files - your FSUIPC7.ini and FSUIPC7.log files, the latter with appropriate logging activated for your issue...whatever that is... But what has this got to do with FSUIPC? FSUIPC just reports and responds to the events seen/received.... Sorry, but I really have no idea what you are talking about...please explain more clearly, if you think this is an issue with FSUIPC... Maybe.... PS: I am now on holiday/away for a long weekend, back on Wednesday....

First, please change this: to this: That won't make any functional difference, but you should understand why the other entries aren't needed.... I don't have the PMDG 777 so cannot test/try these controls to see if they work correctly. Please do the following: - start the sim and load the 777 - open FSUIPC7, and activate logging for both Events and Axis Controls - make sure you also check to Send to console window, so you can see the events when logged - move the assigned flaps axis through its full range, from 0 to 30 and then back again. - exit P3D, and then show me/attach your FSUIPC6.ini and FSUIPC6.log files and tell me what, if anything happened when you moved the flaps lever I don't have the PMDG 777 so cannot test those controls here. And I can only help you confirm if the correct controls are being sent as assigned (which i am sure they are, if assigned correctly). Also, please test/try those custom controls to see if they actually work, e.g. assign a button or key press (temporarily) to one of the flaps settings and see if triggering that moves the flaps. If not, then maybe something else is preventing these controls from taking effect... John

By moving your axis and clicking the From and To buttons - as described in the User manual: Change the file either with FSUIPC not running, or with the Axis assignment panel open, and click Reload all assignments when done, otherwise it will get overwritten with the current settings.

👍 No, not necessary with MSFS - you can have assignments in both MSFS and FSUIPC7 - just make sure you don't have assignments to the same button/switch/axis in both. John

Then this sounds like the lvar only controls the switch position, and something else actually changes the lights. Is anything logged when you switch the lights on/off? If so, you can try using that. You can also try offset 0x0D0C to see if that holds the correct light state, and you can also try writing to that offset (bit 8 for logo lights). Otherwise, see the following article on how to determine how a switch/button functions: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ What type of variable is this? To toggle an lvar, use, e.g (L:VC_Logo_Light_SW_VAL) ! (>L:VC_Logo_Light_SW_VAL) But that toggles between 0 and 1, not 10... The events.txt file is provided by MobiFlight. See https://hubhop.mobiflight.com/presets/. For question or help with defining presets, try the MSFS2020 channel on the MobiFlight Discord server. The events.txt use calculator code, which is in Reverse Polish Notation - see the following: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm Also please don' modify or add anything to the events.txt file (as this will get overwritten the next time toy update). you should use the myevents.txt file. See the Advanced User guide on using the events.txt file in FSUIPC (in WASM section). John

You don't do things like that really... There are two choices: - capture the key press/release event using event.key. The lua script needs to be running to do this - such scripts are usually auto-started, - have two lua scripts, and assign one to be called/ran on the key press, and the other to be ran on the key release Using events is the preferred method and will be quicker than having two separate scripts,

Did you not understand my last comment? It is obvious what is wrong if you actually look at the panel or at you ini file... You are again NOT using the correct control numbers: - your first range is using control number 16000 with a parameter of 74703, when it should be using control 74703 (and no parameter needed) - your second range is using control 11319 with a parameter of 74704, when it should be using control 74704 with no parameter needed - similar issues with your 3rd and 4th ranges Try deleting the addition parameter you have added, highlighted in bold below: i.e. Remove those 0,

Just took a look at both the stable and dev versions and I see the same in both - this lvar stays at 1 regardless of the position of the switch. You should maybe report this to FBW. So try the simvar instead. Once you have added it to an offset, log/monitor that offset (using FSUIPCs offset logging facilities) and see if that changes value when you change the switch position. I have checked that in the dev version and it works there - this is the entry in the myOffsets.txt file that I use to add the simvar to offset 0x66C0: // offset, size, simvar, type, units [, w] 0x66C0, 1, CABIN SEATBELTS ALERT SWITCH,I32, Bool This should also work in the stable, but please test. John

In your first ini, you are using the standard controls, which won't work. In your second ini, you are using custom control numbers 70607m 60608, etc, whuch do not exist. For EVT_CONTROL_STAND_FLAPS_LEVER_0, which is THIRD_PARTY_EVENT_ID_MIN + 5071, use 69632 + 5071 = 74703. Flaps 1 (5072) would be 74704, etc. You are also are not using ranges but specific points: you need to use a range around the detent value, as entering a detent will not always give a specific value., and entry 9 has the same range defined as entry 6. Try a range of around 400 around the detent value. e.g.

Hmm..what version of the FBW A320 are you using (release or dev)? It should hold the correct value, according to the MF presets... That is a simvar that is currently not held in any offsets. To be able to read the value of this simvar, you first need to add it to a free/spare FSUIPC offset. You can do this via the myOffsets.txt file - please see the Advance User guide, section Adding Simulator variables (simvars) to FSUIPC offsets on page 35 of the Advanced User guide, Once it is in an offset, you can read the value using the lua ipc library to read offset values. John

First, this topic is for requesting a trial license only. If you want to try FSUIPC7 for your issue, please download the trial license, available in the first post in this topic, and at least try assigning to the steering controls/events (Steering Set or Axis Steering Set, or the FSUIPC-added Steering Tiller control) , and see if that works, Please also see/read the section on the Steering Tiller axis (in the box) on page 33 of the FSUIPC7 User guide. If you still need help after trying, then post again for assistance - in a new topic please (or one that is already for steering tiller issues), And also please state which aircraft you are using - a steering tiller assignment in one aircraft may not work in another. John

For the position of the overhead seatbelt switch in the FBW A320, just read the lvar L:XMLVAR_SWITCH_OVHD_INTLT_SEATBELT_Position, i.e. seatBeltSwitch = ipc.readLvar("L:XMLVAR_SWITCH_OVHD_INTLT_SEATBELT_Position") John

What do you mean by this? If you want to intercept that control in a lua scrip, use something like the following: function InterceptControl(controlnum, param) //do stuff here - for now, just log ipc.log("Control " .. controlnum .. "intercepted with parameter " .. param) end event.control(66719, "InterceptControl") John

For PMDG aircraft, you should really use the PMDG custom controls for flaps, i.e. these: Assign your axis to (Unused) on the left hand side of the axis assignments panel, and assign to the specific detents in the right-hand side around the position of each detent (you will need to assign most with both Up and Down, but the _0 detent on down only, and the _30 detent on Up only. See the User guide (page 38) on assigning controls to axis ranges if not familiar with this. To use PMDG custom controls, see Also please use substrings for you aircraft profile names - i.e. change: to This will then catch all variants of the PMDG 777. John

This cam also happen with MSFS2020. You need to tune the DetectToConnectDelayAuto ini parameter - see Maybe better to use a separate FSUIPC7 installation for MSFS24 for the time being, so that different parameters can be used for each MSFS version. As above - tune the DetectToConnectDelayAuto ini parameter. Your WASM log also shows the WASM is crashing - this is also a known issue. Tou need to set LvarScanFrequency=0 in your FSUIPC_WASM.ini file - see John

The command line options are documented in the MakeRwys README.pdf. No, there is currently no way to do that. MakeRwys will need to be updated to work with MSFS2024. However, MakeRunwys is no longer supported, now that Pete has retired. I do not know much about MakeRunwys unfortunately, as Pete has always maintained this. I may take a look after MSFS2024 has been released, and I have updated FSUIPC7, but cannot guarantee this. However, the source of MakeRwys is available if you, or anyone else would like to update this for MSFS2024: John

See Looks like FSUIPC7 is working with MSFS2024, although I will need to update... John

Ok, thats good to know...and rather surprising! At least the installer needs to be updated to install the auto-start component. You could try manually adding the FSUIPC7 entry to the MSFS24 EXE.xml file, which should enable the auto-start. Did you try installing the FSUIPC WASM module into the MSFS2024 Community folder? Just copy from your MSFS2020 Community folder. This is needed for the functionality for presets, lvar & hvars. Well, they always have been, hence the need for presets... Anyway, I will review the MSFS2024 documentation on the available events/controls, when available. John

Maybe - if supported by the aircraft. As that event doesn't exist in P3D, for any aircraft that allow other values for anti-ice rather than on/off, then it must use something else, i.e. another event (or custom control) or possibly an lvar. For which aircraft are you trying to use with this event? If the aircraft supports gradual anti-ice, then try activating logging for axis controls, open the FSUIPC logging window and see what, if any, events are logged when you move the gradual anti-ice in the virtual cockpit. If any event is logged, you can try assigning to that. Otherwise, look to see what lvars are available and see if any look applicable, and if so what value range the lvar takes. If an lvar is used, you can create a lua script and use this via assigning your axis to an FSUIPC offset - I can help further with this if needed.

Please see the following post and use that for any other queries/questions on using SkyDemon with FSUIPC: John

Please note that FSUIPC only send out GPS data to serial/com ports, not to the network. This is why you need additional software (Flight Sim GPS) which (I guess) takes the GPS data from a virtual com port and sends it out to the network, This software doesn't seem to be available any more (if anyone can provide this or knows where it can be downloaded, please advise!), and so I think your best solution would be to use the MSFS Bridge Connector, which is payware but very cheap (5-6euros). Otherwise, for use on an iPad, you would need to connect the iPad to your PC via a USB-serial cable. For running SkyDemon on a PC, either the same PC or a client PC, you will need to set-up some virtual com ports. This is described in the following posts (for FS9 & FSX/FSUIPC4 but applies to later version of FSUIPC and P3D/MSFS):

Note that someone has RC4 working (more-or-less!) with MSFS, using ShowText for the menus. See the following post: An issue has also been reported when using PF3 with both FSUIPC7 and FSUIPC6 - see This is corrected in the latest beta release of FSUIPC7 (see Announcements sub-forum) and there is also a patched version of the FSUIPC6.dll available with a fix for this in that post referenced above. John John

@Gabe_62 & @Ray Proudfoot: someone has RC4 working (more-or-less!) with MSFS, using ShowText for the menus. See the following post: