John Dowson

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

No, not that I am aware of. Certainly there are no specific offsets for the PMDG DC6. I don't know if there are any custom controls - take a look at the aircraft documentation 9sorry, I don't have this aircraft). Looking at the MobiFlight preset list for this aircraft (see https://hubhop.mobiflight.com/#/list and set PMDG as provisor and DC_6 as aircraft and you will see the MF presets available) it seems that this aircraft uses the Rotor Brake control with the parameter indicating the actual control. You should have a document with the aircraft that explains what these controls are. For example, looking at the preset PMDGDC6_CABIN_HEAT_TOGGLE, this uses the calculator code '21401 (>K:ROTOR_BRAKE)' (although the close bracket is actually m,issing for this in the preset page!"). To use that in FSUIPC7, you would assign to the Rotor Brake control with a parameter if 21401. Some presets may use lvars or hvars, or even more complex calculator code. It is relatively straightforward to access these in FSUIPC7, but does require some knowledge on how these are ued (see the Advanced User Guide). For the next FSUIPC7 release, hopefully early next week, I will be providing direct access to MobiFlight presets (i.e. they will be available in the controls drop-down menu for button assignment). This has been implemented but not yet released. Alternatively, you can install the MobiFlight WASM module and use the MobiFlight presets by using event files. Some event files are provided in the EventFiles sub-folder of your FSUIPC7 installation, but there i not one available for the DC-6, you would need to create your own. To do this, create a file called DC6.evt in your main FSIOPC7 installation folder, and and add the preset names that you want to use, in the format: where <presetName> is the actual name of the preset you want to use. The event listed in such a file will also be assignable in the button assignments drop-down menu. Of you wait a few days for the next FSUIPC7 release, you will not need to use the MobiFlight WASM as FSUIPC7 will use the calculator code directly for these presets via its own WASM module. John

If ALTITIDE was previously and embedded dll and is now a standalone program, that will explain why it is no longer receiving keypresses directly. However, if this is the case and keyboard input is received by ALTITUDE from MSFS, then it should get this via a SimConnect interface. I think the P3D IVAO client did use FSUIPC offsets, but not the new client for MSFS - at least according to this post: I think you need to talk to IVAO (or ALTITUDE) support about this issue. Please update this thread again if you fund out anything. John

There is offset 0x32F8 which can be used to inhibit certain operations, and offsets 0x310A and 0x341A to disconnect main and auxiliary axis, but none of these will help with a steering axis. If you want to do this, you would have to write a lua script to handle your steering axis. If you did this, you could then monitor for a ctrl key press to stop sending the steering controls when received, and continue when released. John

FSUIPC only sends keys to the FS. Can you please explain how this is working for you in P3D?

Yes, but not yet released. As as I said, will be included in the next release.

👍

Ok, thanks. So changing the id of your yoke also changes the id if your phantom xbox controller. Very strange... I will maybe come back to this when i have more time, but for now, either go back your previous FSUIPC7.ini if you have that saved, or change your [JoyNames] section to the following: If its all working with that (an an empty yoke name), then we can leave it at that (for now). Thanks, John

Please show me /attach your FSUIPC7.log and FSUIPC7.ini files. John

Well, you can use things as they are but I am still not happy that you have an empty device name for your yoke. We could try forcibly changing the device if in the registry. This may be possible via the ini. Can you try changing your [JoyNames] section to the following: Make those changes with FSUIPC7 closed down, then run it once, exit and show me those files again. Thanks. Thanks for the kind offer but no need really - all part of the support service. John

Does that version not crash? If so, please keep using that version. It looks like the OEMName string is being returned as a unicode string for some reason: OEMName found with length 0: 'F' (460041004E004100540045004300200043006C00) That hex string looks like unicode for 'FANATEC Cl' (only the first 10 letters logged). It is very strange that you are getting a unicode string returned. Not sure why this is, I will take a look in more detail when time permits, but if that version is working ok for you I will consider this closed (for now). John