John Dowson

Sure, no problem. This does seem strange - I will look into this further when time allows...maybe someone else has noticed this and can respond? John

So MSFS froze? Check the Asobo forums and report this to them. But this error was logged/produced due to a simconnect failure in MSFS, so needs reporting to Asobo. No, this won't help with you issue as it is with MSFS and not FSUIPC7. John

@joeherwig FY, I have just released v7.2.16, which allows you to define parameterized presets to assign and execute calculator code on a button press without needing to use lua. The MobiFlight presets are also included. Please see the Advanced User guide for details. John

You can now assign to calculator code by using 'presets' in the latest version of FSUIPC7, v7.2.16. The MobiFlight presets are also included. John

v7.2.16 has now been released, containing the condition lever controls, as well as direct access to MobiFlight presets amongst ither updates. Please see the history document or the changes.txt file for a complete list of changes. John

v7.2.16 has now been released, containing the condition lever controls, as well as direct access to MobiFlight presets amongst ither updates. Please see the history document or the changes.txt file for a complete list of changes. John

This new functionality is now available in v7.2.16, just released. John

No it doesn't. FSUIPC knows nothing about the views you have set-up, it only send controls to the FS to change and set views, as you have defined them. It sounds like it is going back to the default cockpit view for that aircraft. Have you changes this (in the camera.cfg file)? I really can't help you with setting up custom views - try looking on avsim.com, I think there are several posts / tutorials on how to set this up, otherwise try asking on that forum. John

👍

Why are you using the hidAlphaButtons and hidBravoButtons lua scripts? These were initially useful to access the buttons with numbers > 31, but have not been needed since FSUIPC was updated to recognise up to 128 buttons, in v7.1.0 back in May 2021. I think you should remove those luas, and update the assignments you were using (on the virtual flags used by those scripts) to assignments to the actual button number. If you do that, you should be ok, as it seems like the issue is that both the Alpha lua script and the rotaries script are using the same offset/virtual flags (at offset 0x3340). If you want to continue using the Alpha/Bravo luas (although I recommend not to), you need to update the Rotaries.lua to use the next virtual device, which will be at offset 0x3348 (the alpha script uses 0x3340 and the Bravo 0x3344), i.e. change line 61 to: offset = 0x3348 That will be virtual joystick 66, so you would also need to change all your rotary assignments from virtual device 64 to use 66 instead. John

Your FSUIPC6.ini has no assignments at all, as you reverted to a default ini. Just copy your FSUIPC5.ini to your FSUIPC6 installation folder, rename it to FSUIPC6.ini and you should be ok. Also, please use the JoyLetters facility, by setting this in your [JoyNames] section: AutoAssignLetters=Yes This will prevent issues if windows decides to change the ids assigned to your devices, which it can do on updates. John

Are you saying that MSFS did not CTD or close? Your log still indicates that FSUIPC7 closed as MSFS couldn't be found: If this is not the case, can you restart FSUIPC7 when this occurs and then continue as normal? The windows error (a fault, not a CTD) is also due to the simconnect connection being abruptly terminated, which also results in those simconnect failure messages. So, if MSFS is not crashing, it is still losing its SimConnect connection. The MSFS monitor, that checks MSFS is still tunning every second or so, does not use simconnect but windows facilities to determine if MSFS is still running. It is this that is failing to find MSFS and so exits FSUIPC7. There is a known issue on Windows 11 machines where this can fail and MSFS is still running, and this can be fixed by setting the following ini parameter in the [General] section iof your FSUIPC7.ini file: DisableMSFSMonitor=Enum However, due to those simconnect failures, it does look like an issue with MSFS and I'm not sure this will help, although you should try this if you a certain that MSFS is still running ok when this occurs. John

For MSFS bugs, you should check the Asobo forums. There have been many issues with incorrect altitude over the past year, and I am not sure of the current status of these. For example, here are a few (older ones): https://forums.flightsimulator.com/t/altimeter-problems-altitude-hold-and-atc-altitude/433209 https://forums.flightsimulator.com/t/help-with-incorrect-high-altitude-altimeter-setting/429439/4 Your image is also showing a setting of 30.16 inhg, and not 29.92...interesting, I have not seen that altitude config panel before, I will take a look... Offset 0x0574 just holds the value if the PLANE ALTITITUDE simvar received from MSFS. The altimeter reading (indicated altitude) is held in offset 0x3324, so you could try that offset. John

You just need to copy your FSUIPC5.ini to your FSUIPC6 installation folder and rename it to FSUIPC6.ini, and copy across your *.mcro files (as well as any *.lua or *.dll files that you use) and everything should be ok. What exactly did you do? Can you please show me your FSUIPC6.ini and FSUIPC6.log files, and also your FSUIPC5.ini if you still have it. John

What exactly do you mean by this? If you open the Button & Switches assignment panel, do you only see the buttons registered on one direction and not the other? What button numbers do you see in the Btn# field when you rotate fast/slow in each direction? Why is it so large? You can generate a smaller one, and it also zips up pretty well, so try that. Make sure that you only have logging enabled for Buttons & Keys and Lua Plugins. Also, please change set the LogActivity variable in the Rotaries.lua to true. Then generate a log file, zip it and attach it here, together with your FSUIPC ini file. John

This depends on what axis control you are assigning to. For the Cowl Flaps, from the MSFS documentation: COWLFLAP1_SET Sets engine 1 cowl flap lever position (0 to 16383) Shared Cockpit COWLFLAP2_SET Sets engine 2 cowl flap lever position (0 to 16383) Shared Cockpit COWLFLAP3_SET Sets engine 3 cowl flap lever position (0 to 16383) Shared Cockpit COWLFLAP4_SET Sets engine 4 cowl flap lever position (0 to 16383) Shared Cockpit So those axis only accept values from 0 to 16383. There you calibrate so that a -16383 input sends a 0 output, and a 16383 input sends a 16383 output (and a 0 input would send 8192 as output). No. It means the whole axis range (-16383 to + 16383) is calibrated to send the full axis range of 0 to 16383. John

It really shouldn't, unless you did a clean install...

First apologies for the late reply - missed your post, sorry. Of course. If you look at your ini, you can see that you currently have a delta of 24 set for the slow inc/dec buttons (on press only), and 50 on fast inc/dec buttons (on press and release): Just increase that delta. You do this in the buttons assignment panel - open that and turn your trim wheel and you will see the details of the assignment (you may need to Ignore the slow buttons to see the fast buttons). Otherwise, you can change the hex values of those inc/dec values durectly in the ini (I have highlighted them above0. Best to do this without FSUIPC7 running - if it is running, make sure the Button assignment panel is open and click the Reload button after making changes. John

First, you are using a very old version of FSUIPC7, v7.0.4. The latest version is v7.2.15, with v7.2.16 or v7.3.0 (haven't decided yet!) to be release in the next few days. Only the latest version of FSUIPC7 is supported. You are correct in that your FSUIPC7.ini is empty - it looks like the old one was removed somehow and a new default FSUIPC7.ini was created the next time you ran FSUIPC7. There is really nothing I can do to recover your previous assignments. If you recently re-installed FSUIPC7, could you have re-installed in a different folder from the original installation location? if so. you should copy the FSUIPC7.ini from its original location to the new one. You could try searching your system for any FSUIPC7.ini file - I recommend the program Everything (https://www.voidtools.com/downloads/) for doing this type of thing. Otherwise try to determine what has removed/deleted your FSUIPC7.ini. I cannot see how this can have been done by FSUIPC7 itself - the ini file is only ever updated (once created) and never removed. John

Thanks but not needed, and there is no way to do this really. John

Ok, that is strange. I will take a look when time permits to see if anything can be done. It certainly shouldn't cause a CTD. John

Its usually beneficial to also install the x86 ones as well. Although not needed by FSUIPC, this can prevent issues with older 32-bit programs. Also does no harm. No problem, glad everything is now working. John

You should set this option in the [General] section of your FSUIPC7.ini file: DisableMSFSMonitor=Enum You may also need to install the combined VC++ redistributable package. Please see the README.txt file provided in the FSUIPC7 zip file you downloaded. John

Nothing looks too bad in your ini, but I would recommend two changes for your DC-6 profile. First, change your [Profile.DC-6] section to the following: This will then match all PMDG-DC6 variants. Secondly, create a profile specific calibration section for your DC-6. To do this, with the DC-6 loaded open the FSUIPC axis assignments panel, go to the calibration tab, check the profile-specific button and then click 'Ok' to save. But I doubt these changes will solve your issue. If you still see the same problem, I need to see your log files. Generate one with your current ini (updated with the proposed changes) and one with a default ini (i.e. temporarily rename your current ini). For both tests, activate logging for Axes Controls, load the DC-6 and move the throttle from min to max and then back again, then exit FSUIPC7. Show me / attach both logs (as well as your updated ini). Note also that when you are using a default ini, you will have to re-assign your throttle in MSFS or it won't have any affect. When you are using your current ini, make sure that you have no assignments to your throttle in MSFS. The easiest way to do this is to switch profiles (in MSFS) - use an empty one for FSUIPC and you can (probably) use the default one when not using FSUIPC (by which I mean with a default ini file, i.e. throttle not assigned. John

Hi RAlpaca, please try the attached lua script. To use, save it to your FSUIPC installation folder and then add it to auto-start either from your general [Auto] section or to your [Auto.xxx] (where xxx is a profile name) if you want to use it for a specific profile, e.g. for my 'Cessna' profile I would use Then, in FSUIPC, delete any calibration you have set on the throttle (from the UI) - either in the general or profile specific calibration settings, whichever you are using for the aircraft. Then assign your throttle to 'Send to FSUIPC Offset' and give the offset value as 0xA000 (if you are using this offset already, change to use a new free user offset and update the throttleAxisOffset variable in the script to match). Then try the script to see how it works for you. I suggest you initially try with the the logging console open (Log -> Open Console), and you can see what %age is being used and the values sent. I've commented the lua so you can change some values to suit your needs. Once you are happy, you can disable the logging in the script by setting the LogActive variable (in the script) to false. Let me know how it goes. John ThrottleControl.lua