John Dowson

I just got the same issue but with the Keys section being overwritten... This is definitely a symptom of memory corruption somewhere...

Can you please use the attached version and send me the log again the next time this happens: FSUIPC7.exe I will continue to test here to see if I can also reproduce... John

No, this is not possible as various sections of the ini are re-written quite a bit...far too often in fact. I am adding some additional logging around the writing of the buttons section and will provide you an update version to use.

Ok, this is rather worrying... Looks slightly different than before as the [Button] section is now missing completely... From the log, when started, the Schweizer S300CBi White was loaded (last aircraft from previous session), and then you then switched to the "Bell 407 Blue Stripes" before starting the flight. When you switched aircraft, or started the flight, was the FSUIPC button (or any) assignment window open by any chance? Did you open any assignment window at all during this test? But that was even before the Bell was loaded, as was this one: I dont think this can happen during a flight as the buttons section is not read or written during a flight - only updated/saved when you are in the Button assignments dialog, and only when OK is pressed. I presume this occurred at some point before the flight was started. I will try and reproduce here. For future tests/flights (after restoring your FSUIPC7.ini), could you make a note of when you are using the FSUIPC UI, especially the assignments panels.

As your question is on FSUIPC7, I have moved your post to the FSUIPC7 sub-forum. Note also that 7.4.7 was released yesterday - please update. Most 3rd party apps do not require a key/licensed version, but some do. Looking at SkyDemon, that uses the GPSOut facilities of FSUIPC7 so a licensed/registered version is required. If you have purchased a license, you can always retrieve the license details from your SimMarket account. Once you have a license, you also need to configure FSUIPC7 to send out the GPS coordinates. For example, see John

👍

I think this may have been caused by an issue in the 7.4.7b release (a string termination was missing) that was fixed in the final release. The same issue could also prevent auto luas being started. Please restore your buttons in your Schweizer.ini file (by backup, if possible) and continue testing. Post your files if you have an issue. Its also strange that the lua auto issue has gone...

Ahhh - I see the problem in your Schweizer.ini file - the button section has been trashed: Hope you have a backup... This is worrying and I don't know what could have caused this....looks like a memory corruption error somewhere....I will investigate.... No button assignments in the Bell2206.ini, and the CabriG2.ini looks ok. Please take a backup of all your ini files before anything else....

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