John Dowson

Ok, but just a good idea to remove these assignments at some point. Understood, but you should clean-up your profile aircraft names and this won't cause any issues, and will make sure a profile is loaded regardless of the aircraft livery being used.

Understood, but may be tomorrow before I can review your latest files.

Btw, are all your devices attached to the server PC, or do you have some attached to the client PC? When the profile buttons are not working, are these in a device attached to the server PC or the client?

Not related to your issue, but a few problems I have noticed in your ini fille... You have assignments to these two missing joysticks - best to remove those assignments (or change the letters to an existing device) and remove those lines. You should update to use substrings in your profiles. e.g. change to Change to etc. Do this for each of your profiles, i.e. use a substring of the aircraft name that identifies all aircraft of this type you want to capture, and no others. Doing this will match the aircraft to the profile regardless of livery.

Can you try the attached version and show me the log file please. No change here, just additional logging around button assignment loading FSUIPC7.exe

Profile buttons should be loaded after the aircraft name is logged: But I cannot tell where those button assignments in your log are coming from... can you please attach your FSUIPC7.ini file and the profile .ini files of the aircraft you are using for testing.

You will as there is no change just additional logging.. So you are saying that the luas are now started ok (including profile luas), but the profile buttons are not loaded? And the first time you tried everything was ok for the first two aircraft, and the profile buttons failed to load on the third aircraft, and the second time the profile buttons failed to load with the first aircraft?

Yes but that will be done slightly later - different sections of the profile are loaded at different times. It looks like the aircraft name isn't available when the lua autos are started - this is what I want to check with the additional logging. Could you also use the attached version which has additional (temporary) logging added. John FSUIPC7.exe

Ok, thats interesting. Is this auto started in a profile [Auto] section? I suspect so... Can you add logging for offset 0x3D00 please, as AscIIZ. This will log when the aircraft name is available which is needed to determine which profile to use. Also add logging for Extras, to add the thread ids to the log. Then generate those two files again. Thanks - I will see if I can reproduce here, but it does look like something that WideClient is doing that is triggering this... John

Yes, it would...hopefully this will be fixed in a later SDK update, but no idea how long this will take... Cheers, John

There is no way to "reload a profile". Profiles are ALWAYS automatically loaded once an aircraft is loaded that is assigned to the profile. If an aircraft is loaded that is not assigned to a profile, you can attach this to an existing profile or create a new profile for it. So I presume you mean that you need to attach your aircraft to an existing profile before the buttons work.... If a profile isn't loaded, it is usually because an aircraft with a different name is loaded, usually due to not using substrings for you profile names and the aircraft is using a different livery. For example, in your ini, change this: to this: That will then load your Fenix profile for all aircraft that contain 'FenixA320' in the title. Do the same for all your aircraft profile names (i.e. shorten them to a substring). Those Fenix aircraft names do look a bit strange though, but the other profile aircraft names look ok. And if that is not your issue, please attach your log file with appropriate logging as previously advised. And as you are using profiles-in-separate-files, please attach the profile ini for the aircraft you are using, as well as your FSUIPC7.ini file again. This also needs correcting in your FSUIPC7.ini: This was probably caused by a bug in an earlier version of FSUIPC (sorry about that!), corrected now. I suspect that they were assignments to presets initially. John

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