John Dowson

Not sure how it can work if you deleted FSUIPC and the PFCFSX.dll.... Anyway, glad its working.

Auto-ran luas (including ipcReady.lua) are started once the initial list of lvars/hvars have been received by FSUIPC (from the WASM). The only lua that is started earlier is the ipcInit.lua, started once FSUIPC7 is connected to the sim. The WASM waits for LvarScanDelay seconds before scanning for lvars, and the default value is 5 seconds. After this, further scans are performed at a frequency of LvarScanFrequency, which defaults to -2 (i.e. minimum 2 seconds between scans) and if/when any new lvars are detected they are pushed out to FSUIPC7. Please see the Advanced User guide (page 51) for the details on these WASM ini parameters. Lvars can be created at any point, and there is no way to know/determine when they have been created or the initial values set. And it is dependenat on the aircraft - for GA aircraft, a 5 second delay (from aircraft loaded to lvar scan) is usually enough, but for complex airliners it may take a lot longer, and in some aircraft lvars can be created several minutes after aircraft load. There is no way to test if the list is complete - it is never complete as lvars can be created at any time. If you know the lvars you want to use, then you just have to check for their availability in a loop, then continue once you have received a non-nil id. No idea - I have never used these files. I thought an lvar is an lvar, regardless of how it is created. I don't think creating these lvars via config files is a good idea...Why don't you just create them in am auto-started lua, and add checks in any lua script that uses them at the start of the script, e.g. something like -- Check Lvar exists while (ipc.getLvarId("L:myLvar") == nil) do ipc.sleep(200) -- wait before checking again end -- Lvar now available - continue John

No problem, but I don't think this will be of use. That structure is used only in other structures which are used in some race events, and the information doesn't see to be available via simvars.

This sample maps a key press input event to the client event, which is in turn is mapped to the actual key event. FSUIPC does not and cannot use these type of input events for controller assignments, as it interacts with hardware devices at a lower level via the Windows API, not using these type of input events. We will have to wait until this issue has been addressed by Asobo.

Ok, Asobo have now replied again in the DevSupport request that you raised. Sending key events via both SimConnect (TransmitClientEvent) and the Guages API (execute_calculator_code) will bypass the event interception and call the sim event directly, hence the issue. A bug will be logged for this - there is not much I can do here I am afraid. I will look at the Input Event mapping sample that they referenced, but I doubt I can implement such a mapping in FSUIPC as this would be dependent on the loaded aircraft. John

There is no much point me going through such a huge log when I don't even know whereabouts in the log the warning was triggered... Do you know what actually triggers this warning, and why it is triggered on landing (presume this is a warning related to take-off configuration, no?). Maybe ask about this on the Fenix forums (or discord channel... whatever they are using for support). Can you disable all logging please, and add logging for Buttons & Keys. Also add logging for the flaps position - offset 0BDC as U32 (using Log->Offsets...) Also try opening the FSUIPC logging console when you land (Log->Open Console), and make a note of the timestamp when you get the warning. We can then see what the flaps position was when the warning was triggered. The only assignments on your Bravo that have an effect on the Fenix will be these Throttle Decr assignments: I don't think these can be the cause... How are you assigning your axes in the X56? This key assignments in your FENIX profile, relating to the TO Config, looks strange: You are sending the same preset (FNX320_ECAM_TO_CONFIG) on both press and release, so the same preset will be send twice. Could this be the cause? Maybe when pressing to disable TO Config this isn't working due to this problem... I think this was caused by a bug in 7.4.6 (and earlier versions), and is fixed in the latest beta - see There is also a beta version in that post - try with that, and change your key assignments that use _Press for the release control to _Release - you can do this in the UI but maybe quicker/easier to just update your FSUIPC7.ini manually for all key presses assigned in this way. John Later: maybe use the attached version instead - this is 7.4.7 which I will be releasing later tonight/tomorrow: 7.4.7 has been released

I have checked both the event and the preset using your snippet and nothing happens (i.e. lights not toggled) in the VC - but the event is logged by FSUIPC in both cases. I have also changed the priority of the group with this event and still don't see anything, using both the key event and the preset. What do you assign to in MSFS to trigger this event? I would like to check that this is working here....

Does the event work correctly if sent via calculator code/using a preset? Can you check this by creating a preset - add the following to a file called myevents.txt (create this if it doesn't exist) in your FSUIPC7 installation folder and add the following: My_AUTOPILOT_KAP140_1_ALT_Push#1 (>K:AUTOPILOT_KAP140_1_ALT_Push) or possibly My_AP_VS_VAR_INC#1 (>K:AP_VS_VAR_INC) Then try assigning to that. I have commented on the MSFS support thread - lets see what they say. I will do some testing with different priorities here... John

See the section Adding Simulator variables (simvars) to FSUIPC offsets on page 34 of the Advanced User guide (FSUIPC7) or page 36 (FSUIPC6) - not possible in other versions of FSUIPC. Basically you need to add an entry to a file called myOffsets.txt in the format described in the manual. Only the following types are supported: John

That is very strange... No - it checks. This is what I see: I am not sure why it is hanging for you - I will have to check further here. I am noy actually using any WideClients, so I will try later in the week with WideClient also running to see if this affects things. John

No - profiles are selected automatically, you do not need to do anything. What are you actually doing - please explain. General button assignments also apply to an aircraft in a profile, unless overwritten. When you open button assignments panel the profile-specifiic check-box is not checked, When you press a button, if there is a profile-specific assignment, then that will be shown and the profile-specific box will be checked. If not, and there is a general assignment, the assignment will be shown but the profile-specific box remains un-checked, as it is a general assignment and not profile-specific. It works this way as all profiles inherit the general button assignments, unless overwritten, and the panel allows you to see both general and profile assignments, all those applicable to the current loaded aircraft. If you think there is an issue, set logging for Buttons & Keys, open the logging console and you can see what is happening when you press the button. Any issues, show me/attach your FSUIPC7.ini and FSUIPC7.log files (with the aforementioned logging enabled and showing your issue).

I am not sure why the group priority would affect this...I will check out the dev support forums (but a link would have been useful). How would I use that snippet to test this here? I really do not know - I will have to look into this further.... John

Ah, i see now - the installer detected and installed correctly, but FSUIPC7 checks things the other way around. FSUIPC7 does first check that location for the UserCfg.opt file, and so incorrectly determined that you were using an MSFS version and looked for the WASM under E:\MSFS\Packages\Community. Removing/renaming the YserCfh.opt file would have fixed this. I should really check the location in the same order as the installer to avoid such issues....I will update for this. Cheers, John

You have no axes assigned in your Fenix profile - where are these assigned? You also have no calibration section for your Fenix profile, so the general calibration section will be used. In this section, you have flaps calibrated which could be interfering. Create a calibration section for your Fenix profile and remove the flaps calibration: with the fenix loaded, open FSUIPC and go to the calibration tab and click the profile-specific checkbox, then go to page 6 of the calibaration tab and click Reset on the flaps. This will remove any interaction that FSUIPC has on your flaps. Not sure if this will help but worth trying before investigating further. John

It will be kept and included in the next official release, 7.4.7. No problem - cheers, John

No - you do not have to add this. The ipcReady.lua is always started if available, you do not add this to an [Auto] section. From the lua plugins document: Ok Ok

Maybe worth going back to your previous/last working ini and forgetting about the last one you attached, Use that, start FSUIPC7 and exit and then attach your files again, and I can look into any issues with those. Looks like we might need to remove some registry entries again - these look to be incorrect: Wrong GUIDs: N, x00, x04D8, xF30F, AGRONN B737 Yoke V2.2, -1, -1, 1, {NULL}, {F73B7EE0-4B37-11EE-8013-444553540000}, {NULL}, N, N N, x00, x044F, x0402, Joystick - HOTAS Warthog, -1, 2, 0, {NULL}, {F73ABB90-4B37-11EE-8003-444553540000}, {F73ABB90-4B37-11EE-8003-444553540000}, Y, Y N, x00, x0000, x0000, Fulcrum One Yoke, -1, 12, 0, {NULL}, {89A3AE10-D256-11EE-8002-444553540000}, {NULL}, N, N N, x00, x2356, x8046, Landing Gear Lever, -1, 5, 0, {NULL}, {F73B09B0-4B37-11EE-8008-444553540000}, {F73B09B0-4B37-11EE-8008-444553540000}, Y, Y Wrong GUIDs, multiple entries: N, x00, x16D0, x3530, Parking Brake, -1, 10, 1, {NULL}, {F73B09B0-4B37-11EE-8009-444553540000}, {F73B09B0-4B37-11EE-8009-444553540000}, Y, Y N, x00, x16D0, x3530, Parking Brake, -1, 12, 0, {NULL}, {89A3AE10-D256-11EE-8002-444553540000}, {NULL}, N, N ...etc No idea how your registry got into such a mess again. May be easier to remove everything and start again, but lets look at your files when using your previous working ini first... John

Should be fixed in the latest beta: FSUIPC7.exe

Sorry, but this makes no sense according to your current assignments in you latest ini: A=Cat3Design A320 FO Tiller V2 B=Cat3Design A320 FO Tiller V2 C=Joystick - HOTAS Warthog D=T-Pendular-Rudder E=VPC Panel #1 F=Landing Gear Lever G=throttleTek 3 H=LEFT VPC Stick MT-50CM2 J=Throttle - HOTAS Warthog K=Parking Brake M=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> and these are now completely different from your previous working ini: A=AGRONN B737 Yoke V2.2 B=Joystick - HOTAS Warthog C=Cat3Design A320 FO Tiller V2 D=T-Pendular-Rudder E=VPC Panel #1 F=Fulcrum One Yoke G=T-Pendular-Rudder H=LEFT VPC Stick MT-50CM2 K=Cat3Design A320 FO Tiller V2 L=Throttle - HOTAS Warthog J=Landing Gear Lever M=throttleTek 3 FSUIPC does not change device letters, so you must have done this - why? And why are you specifying a 'preferred setup)? Once you have assigned a letter to a device, you should stick with that - so why is your "preferred setup" so different from the last ini you attached, but is the same as your last "working" ini? Are you manually editing the ini, or starting without an ini to generate a new one, then cutting and pasting?

Can you please attach your files - FSUIPC4.ini, FSUIPC4.log and the PFC.log or PFC,ini files. Also please see the provided PFC.dll User Guide and follow the steps there. I do not have nay PFC devices and do not use FSX, so you will need to trouble-shoot this yourself, but I can try and help... John

But how can you set thigs up in the cockpit if you do not have an aircraft loaded? You should not be trying to set anything for an aircraft when in the main menu... But then you need to open the fuel valve once the aircraft has been loaded, not when in the main menu - setting anything in an aircraft when in the main menu is not guaranteed to actually do anything.... The best way to initialise an aircraft on load would be to have a auto-started lua script, which will be started when the aircraft is initially loaded. You can also use ipcReady.lua for anything that applies to all aircraft, but for anything that is aircraft-specific you should have a specific script that is started from the the aircraft profile auto section. The WideServer component/thread in FSUIPC has always been started once an aircraft is loaded and ready-to-fly. Starting it earlier may not guarantee WideClient will work correctly, as this may also depend on other threads which are not stated until an aircraft is loaded. However, in the attached version I have added the ability to start the WideServer thread soon after the simconnect connection has been opened and the data requested, but I am not sure that this will work as you would like it. To use this feature, add StartEarly=Yes to the [WideServer] section of your FSUIPC7.ini file. John FSUIPC7.exe

Can you please attach your FSUIPC7.ini and FSUIPC7.log files.

This is strange as the installer first checks the steam location for the UserCfg.opt file in this location: %APPDAT%\Microsoft Flight Simulator\UserCfg.opt If this file exists, a Steam install is assumed, and if not then an MS Store installation is assumed. And your installation log shows that the following UserCfg.opt file was used: File D:\Users\Administrator\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt opened OK This IS for your Steam installation. Are you sure that you did not update the UserCfg.opt file from the MS Store installation, which would be here: %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt or possibly %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\UserCfg.opt

You are using an old and unsupported version of FSUIPC7, 7.4.1. Please update to the latest and only supported version, 7.4.6 and see if you get the same issue. If so, please re-attach your files. Please disable Log>Log Lua Separately and set Log->WAPI->Debug. and also attach your FSUIPC_WASM.log file. Google is not going to help you with FSUIPC errors... But are these errors actually causing any issues? I suspect that they are due to the fact that you are creating a lot of new lvars in succession and can safely be ignored. The line after these errors indicates that you have the lvars loaded successfully: If you want to remove the errors, you can add a small delay after you create each lvar (e.g. ipc.sleep(250)), to allow time for the updated lvar list to be passed back to FSUIPC, or create all the lvars in one calculator code statement instead: ipc.execCalcCode("0 (>L:DA62_Lt_Panel) 0 (>L:DA62_Lt_Flood) 0 (>L:DA62_Start_1) 0 (>L:DA62_Start_2) 0 (>L:DA62_Eng_1) 0 (>L:DA62_Eng_2) 0 (>L:DA62_Fuel_1) 0 (>L:DA62_Fuel_2) 0 (>L:DA62_AV) 0 (>L:DA62_Batt) 0 (>L:DA62_Alt1) 0 (>L:DA62_Alt2) 0 (>L:DA62_LPump) 0 (>L:DA62_RPump) 0 (>L:DA62_DI_Mode) 0 (>L:DA62_DI_Max) 0 (>L:DA62_DI_Alt)") John

Sorry, but this is still not clear... What is a "fake command"? You send "commands", also known as events or controls, via assignments to keys presses, buttons or axes, or using lua or by writing to offsets. All controls go via the SimConnect API. I have not used either, and am not sure what the 'npm fsuipc package' is...the WebSocket server will be the newer of the two, so maybe start with that... John