John Dowson

But you did not run FSUIPC afterwards. The version of the ini is 7.4.18, but the log reports 7.5.1. So this ini was not used by that log file. O need to see files from the same session. No, those changes could not affect MobiFlight in any way. You should make those changes as advised, and if you have issues report them and we can investigate. But if you don't follow my advise, I can't help you. Nothing was working in the aircraft you tried as all the assignments are empty: Not sure why that is, but you should remove those and re-assign. And for your PMDG / FBW / Fenix profiles, they all use presets and won't work as you have not installed the FSUIPC WASM module: If you selected to install the WASM and it wasn't installed, then check your installation log for errors. You cn try re-installing and install the WASM, and if any issues check the documentation or previously reported issues. There are various known issues that can prevent the WASM being installed. You may also have issues if you have installed FSUIPC under the Windows Program Files folder: ? If that is one you created then thats ok (it is not under c:\), but otherwise it could create issues.

Null zones are calibrated in FSUIPC's axis calibration pages. See the User guide. John

What do you mean by this? If you previously reported the same issue, you should use the same support topic. Is this the same issue reported here: If so, please continue there rather than starting a new topic for the same issue.... I will close/lock this shorty, unless this is a new issue... John

That is interesting - I hadn't noticed that. That will at least make the profile matching easier/more reliable for most people! It is not possible to add MSFS2024-only simvars to FSUIPC offsets at the moment, as this would create issues when using MSFS2020. I could look into only requesting certain simvars in specific MSFS versions at some point if needed, but I don't think this one is useful enough for enough people to add this to a fixed offset at the moment.

Your upload limit is rather restricted as you are a new forum user - it will increase the more you post. You can try compressing/zipping it, but if still too large you can use one of the free file exchange services, e.g. https://filetransfer.io/ You only need to update the one, but it doesn't matter. Ok, so the buttons on your controllers/devices are not recognised? If thats the case, please also attach your FSUIPC7.ini and FSUIPC7.JoyScan.csv files. And that would explain why nothing is working, but is not exactly the issue of this topic...

That can have absolutely no affect whatsoever, as only additional software and files are installed with this, and nothing is actually started or used unless you manually do something with what is installed. The log file you attached was attached when FSUIPC was still running - please exit FSUIPC before attaching files. Did you check the MSFS logging console for messages? Did you try setting the ThreadAffinityMask?

Thats not strictly true - it could be that the WASM couldn't acquire a simconnect connection, which may be your issue. This is usyally caused by another third party app taking too many connections. FSUIPC can sometimes cause this, if nadly tuned, but the auto-tuning facility should detect this and set auto-tuning to run, and after FSUIPC7 has been ran a few times (2 or 3) it should have tuned itself. Anyway, if thats the case, the FSUIPC7.log file may help. but I may also need to see a SimConnect.log file to see what is taking all the connections. But let me see the FSUIPC7.log file first, and follow my other suggestions. John

I am afraid that 16 is the maximum number of devices allowed. Not sure why you are only seeing 15 though... John

This is possible but not via offset area 0x3340 as that is for FSUIPC-internal virtual buttons and such buttons are only seen by FSUIPC and its clients. What you need to do is download and install the vJoyOffsets program. Use this to configure a separate/distinct offset area for your virtual buttons. then use that area. Changes to such an area are then forwarded to windows (using vJoyFeeder) and can be seen by any other windows application. Make sure you read the vJoyOffsets documentation. John

The WASM log file shows that it was attached when MSFS was still running and that you hadn't even started a flight yet. Please always exit MSFS before attaching a WASM log file, and also please set Debug level logging.in the WASM (via the FSUIPC_WASM.ini file). And I also need to see your FSUIPC7.log file generated showing your issue, preferably with WAPI debug logging set (Log->WAPI->Debug) as well as for Events and Buttons & Switches, so please attach that, but only once you have exited FSUIPC7. You should switch to using substrings for your aircraft profile names in all your profiles. For example, for your B737 PMDG profile, change to and to This will prevent issues with the profile not being loaded when using a new livery. Updated from which version? There were hardly any changes between 7.5.0 and 7.5.1, and nothing that would effect presets. John

The WASM log file is under your AppData folder, but for some reason you have not installed the WASM module, so you won't have one anyway, The myOffsets.txt file only exists if you create one. In the log file you attached, you didn't even load an aircraft or start a flight, so there could have been no possible reduction in FPS. Please attach a log file when you experience the issue. Did you check the MSFS logging console for messages? Please do this. Can you also try with FSUIPC7 running but without APL running, to see if the issue is with FSUIPC7 or is with APL If you get the FPS drop with FSUIPC and without APL running, you could try moving FSUIPC off of the first 2 CPU cores by using the ThreadAffinityMask ini parameter. See, for example, https://bitsum.com/tools/cpu-affinity-calculator/ on how to calculator the mask value, and then add the entry to the [General] section of your FSUIPC7.ini file. I use the following which will use cores 2-7: ThreadAffinityMask=xFC John

But why does SayIntentionsAI need to see this? If the button on the intercom switch of the Airbus Radio Control Panel triggers this and writes to an FSUIPC offset (via the "gate"), then you can have a lua script that monitors the offset and sends the required PTT control to the FS. How is the current PTT button assigned - is that in FSUIPC or elsewhere?

Thats exactly what the script should be doing. This is what I requested above --> My intention would be to have the pedals disconnected as long as the button is being pressed down and to reconnect them as soon as I release the button. So it is still disconnecting when the assigned button is pressed? This wasn't clear from the OPs original post. The issue is probably that he is using a momentary button, rather than a sticky button or switch, and so the diconnect is activating then de-activating on each button press/release. If he wants 1 press/release to toggle on, and another to toggle off, then he should use the MF preset, and update that to also trigger the animation if needed. John

But how are you expecting to trigger this virtual button press? Rather than the trigger writing to offset 0x3340 to trigger a virtual button, that then triggers the PTT, why can't the initial trigger just trigger the PTT directly?

And when the button is down, are the pedals not disconnected? Those presets consist of 2 parts - one to control the function (via the lvar L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT) and one to control the animation (via the lvar L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT_Anim). So it seems that the functional part is not working. There is also an MF preset for this which acts as a toggle- FNX320 Misc Tiller Pedal Disconnect Captain Press. That just controls the functional part. Can you try that preset to see if it works for you?

I think you are misunderstanding the functionality provided by offset 0x3340. Setting a button flag in that offset range will trigger a virtual button press in fsuipc, which will trigger the button assignment in FSUIPC and you can see the button in FSUIPC's button assignment panel for assignment. it cannot simulate a button press for other applications, i.e. it is not possible to force/send an actual button press event for other programs to action. John

I thought FSUIPC could handle up to 64 devices, but looking at the code that writes the [JoyNames] section it only writes 16 devices. Not sure why - I will check this and get back to you, but probably not until next week. Could you please set a custom log value (Log -> Custom) of 0x200000. restart FSUIPC7, exit and then attach your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files.

First, only a subset of simvars are added to FSUIPC offsets. And I do not add any new simvars to offsets unless by request and I think it a useful addition for everyone. Several years ago I added a new facility in FSUIPC to allow the user to add any simvar to a spare/free FSSSUIPC offset via a file called myOffsets.txt. Please see the Advanced User guide for details on using this feature. Note also that as FSUIPC7 is compatible with both MSDS202 and MSFS2024, it is build using the latest SDK for MSFS2020 and not the MSFS2024 SDK. However, it should still be possible to request simvars from the MSFS2024 SDK, but make sure this is only done when using MSFS2024 and not MSFS2022. John

First, please use the FSUIPC7 / MSFS support sub-forum for all issues/questions with FSUIPC7 and not the main support forum which is for all other versions/products. I have moved your post. Yes. The main cause of such stuttering is excessive logging by MSFS. Can you check the MSFS logging console to see what messages are logged, and if they are being logged at a very fast rate (you will need to activate Developer mode in MSFS to see the logging console). Does this occur with all aircraft or only a selection (please try both simpler/ GA aircraft and more complex ones)? Excessive logging can be caused by FSUIPC requesting variables from the new fuel or electrical system in an aircraft that does not use them. FSUIPC does not do this by default, and so if this is the cause it is due to a simvar being requested via the myOffsets.txt file. So, if using that file, check to see if it has any such simvars added and if so you should only use that file when flying an aircraft that uses the new systems. Please attach your FSUIPC7.log and FSUIPC7.ini files, as well as your FSUIPC_WASM.log file. Please only attach files once FSUIPC7 has exited, and only attach the WASM log file after exiting MSFS.

I am not sure I understand this - how is your controller assigned, in FSUIPC or elsewhere? The software cannot send such events to FSUIPC and all events are received from the FS. So I suspect that it is the Elite software that is sending the events to the FS, and then FSUIPC is receiving them for logging purposes and possibly for calibration. It should be possible to calibrate such events when not assigned in FSUIPC or when assigned but not with 'Send direct to FSUIPC Calibration', as long as the ini parameter AllowSendToFSCalibration is not set to No. If you cannot see any movement in the elevator trim calibration tab, could you please activate logging for Axes Controls, load your aircraft, move the assigned elevator trim axis through its full range and back again, exit FSUIPC7 and show me / attach your FSUIPC7.log and FSUIPC7.ini files. John

I have updated the display vals.lua script to use the Wnd library in the attached version. John display_valsW.lua

If you are having issues, please attach your log files (FSUIPC_WASM.log and FSUIPC7.log, with appropriate logging activated) and I will take a look.

What do you mean? You should be able to control this aircraft already, either via standard controls, lvars or presets - there are currently 386 presets available for this aircraft. There is currently no access to the iFly SDK - I will look into adding these (as read-only offsets) at some point when time permits - see John

No - as I said, the folder for saved flights is determined by the FS.

No - the folder for saved flights is determined by the FS. FSUIPC delegates the flight save/load operations to simconnect API. Unfortunately in MSFS2020 (and MSFS2024) the flight save function is still not working 100%, and is still documented as "NOTE: The current status of this function is NO ERROR, NO RESPONSE", which is Asobo's way of saying that this function still isn't 100% reliable. So the flight load/save functionality needs to be used with caution, and seems to work better in some aircraft and not in others. There is nothing I can do about this in FSUIPC and this needs to be fixed/addressed by Asobo. John