John Dowson

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

Way back in time. FSUIPC hacked into the sim to get the data for the offsets (before my time!), and was instrumental in developing the simconnect API. Once the the API was introduced, it was moved to use this, but also used some hacking for initial simconnect defects. From P3Dv4 and onwards, 95% of functionailiy has been via simconnect, abut some features still used other FS dll functionality, namely via the panels dll. For MSFS2020, everything comes via simconnect, or the embedded FSUIPC WASM module. These are all requested at sim_frame rate in FSUIPC How can things possibly work faster than the API allows? And there is always going to be a lag between setting and receiving the updated data - everything is asynchronous - you need to allow for this. Setting/updating are different channels than receiving. And the lg between the two depends on many things,,, Sorry, this is beyond me - what are "Token vars"? MSFS has various SDKs for different applications - take a look at those, FSUIPC is a 3rd-party simconnect application providing a uniform interface to multiple flight sims for 3rd party developers (amongst other things). We stopped hacking into the sim code after FSUIPC4, as this was a maintenance nightmare.... John

I am not sure what you are asking.... FSUIPC is a simconnect client, and is therefore restricted to the update frequency allowed by simconnect. Different data is requested indifferent frequencies - some in visual frame, some in sim frame, some in second, but always tagged (i.e. only received when changed). Most data is requested in sim frame (SIMCONNECT_PERIOD_SIM_FRAME), but also a lot in visual frame (SIMCONNECT_PERIOD_VISUAL_FRAME). If you let me know which offsets/simvars you are interested in. I can let you know the request frequency. But FSUIPC is a simconnect client, and has the same restrictions as all clients, And in MSFS2020, FSUIPC is an external client, not an embedded dll, so there is always going to be a lag in communication between an external app compared to an embedded dll. In summary, FSUIPC IS a simconnect client, and can only receive data via this interface. It does have an embedded/WASM component, but that is used only for lvar/hvar/calculator code. The data update rates are always going to be restricted by the provider, not the client. John

But did you change the script to remove the conflicting device? You cannot use the same script - it needs to be adjusted to the device that is giving the problem... I will look at your new files tomorrow or early next week and advise... John

Do you have an issue or question? Then why are you posting?