John Dowson

You still have some assignments to the virtual buttons used by the Bravo lua script: You should delete this and re-assign to the actual button numbers if you want to use them. Did you have an aircraft loaded and ready-to-fly? Luas are only started once in this state (well, 5 seconds after, or longer, depending upon the value WASM ini parameter LvarScanDelay which has a default value of 5 seconds). I can't really tell what is happening from the log you attached as it is a continuation log file (i.e. you selected 'New Log' from the logging menu). Always attach a full log when you need support - there is information at the beginning (and end) that I need to see to diagnose issues correctly. Also, did you activate logging in the Rotaries.lua as I advised if you have issues? If not, and you still have issues, please do that and show me your full log file. The log file you attached has no lua logging so I can only assume it wasn't running for some reason. John

The logging level shouldn't make a difference for error logging - they should always be logged, regardless of the logging level. Just checked the code for this as well and it looks ok. Whet logging level were you using when you saw the error? Can you try again and see if you still get that, and if so let me know what logging parameters you are using. I will also update that message to make it clearer what it means. That is strange then. If MSFS was still running when you installed, then this could explain things. However, I think the installer will show a message and not proceed if MSFS is running, so I really have no idea why you saw that message. No problem. Cheers, John

Hi Andre, glad you got it working. One thing in your lua scripts - you are reading as an 'unsigned double', which is correct, but writing as a signed double. It will still work in this case, but better to also write as a signed double using the ipc.writeUD() function. Also, you could have achieved the same using a standard control assignment with an offset condition. That would be slightly faster, as the lua method requires your script to be compiled each time before it is ran, but in this case it doesn't matter much. John

How come you get different logging? Did you re-install and install the WASM? This is correct, and indicates that you have installed the latest WASM. Well, it is certainly in the installer... This is correct - that is the date the WASM 0.5.7 was built. It is (but for FSUIPC7, not FSUIPC6, presume a typo)! Please look at the component options when installing - one of them is the WASM. I really don't understand why you are confused. Please tale a look at your InstallFSUIPC7.log file, this will tell you what was installed and where. John

Then you also need to update your WASM. You should always re-install the WASM from the installer when you install FSUIPC7. The message is slightly misleading...it is saying the WASM installed is 0.5.6 whereas the WAPI/FSUIPC is expecting 0.5.7. You should update as it may cause issues . John

Yes - a 'K' type variable is the same as an FSUIPC control, so just assign your button to the control (when you select 'select for FS control') Toggle Tailwheel Lock. 'A' type variables are simvars and are held in fsuipc offsets (that is in offset 0x2A90). The conditional check 'A:TAILWHEEL LOCK ON, Bool) 0 == if' is only checking the lock is off before sending the control ('(>K:TOGGLE_TAILWHEEL_LOCK)') , so its the code to turn on the wheel lock. You don't really need that if assigning to a button. If assigning to a switch, with one button for off and another for on, then you would use an offset condition (see Advanced User Guide) to only send the control if the actual state of the wheel lock (as reported in that offset) was in the correct position (value 1 or 0, depending if the assignment is for on or off). The latest version of FSUIPC, v7.2.16, released a few hours ago, also has assignments to MobiFlight (as well as user-provided) presets available for direct assignment in the menus. Please download and try that. The MF presets should be available automatically, but please check the Advanced User guide for details. John

That is strange...I see: Are you sure that is from the latest release? Can you check and show me the full log file. And did you also reinstall the wasm? I will check further on that message tomorrow, but it shouldn't be an issue... John

Btw, I am looking to add functionality to add any simvar (or MSFS A type variables) to a free user offset for the next release. Couldn't fit it in to this one (didn't want to delay any longer!), but should hopefully be ready for release by early next week. John

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