John Dowson

Hi Joe, Please do, and if you haven't done this already, check out the MobiFlight HubHop website for presets/calculator code, and consider submitting any additional code there. It is the main community resource for MSFS calc code. Cheers, John

Thanks Andrew - updated for the next release. Cheers, John

If it is related to a simconnect issue, then logging simconnect could maybe point to something. However, if MSFS is freezing this really could be anything (e.g. related to weather or AI, your rolling data cache, an aircraft issue, etc) and nothing to do with simconnect. You really need to try and narrow it down. You probably won't get any response from Asobo, but worth checking there to see if anyone else has a similar issue with a possible cause or solution. John

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