John Dowson

No idea, sorry.

There is one parameter you could try that stops the CMDRST command being sent to the device - from the Advanced User Manual: ...but I think that was added for issues related to connection (and also closing down) VRI devices. See John

Are you sure? Is that if using LINDA? I have no idea what is making the display erratic, but, looking at the documentation (and also what Pete has said), I think you still need the SerialIFP2 driver if using it with FSUIPC, or check with Linda support. Your logs show that FSUIPC is working as expected. However, some of the runs of the HDG.lua were killed before running, meaning some button presses would have been cancelled by subsequent ones as they are using the same lua and didn't have time to complete. Maybe not an issue, and certainly not related to your problem.

If you re-installed windows, you will also need to re-install the VC++ redistributables from 2015, 2017 & 2019. Please see the section Invalid Key Problems in the Installation and Registration guide,: and this section in the README.txt: John

Hmm, I don't see how this can be.. Without MSFS running, no offset data is populated, and no controls/events are sent. I don't see any point investigating or looking at this without MSFS running (and an aircraft loaded and ready-to-fly). No idea, sorry, as I don't have (and have never used) any VRI devices. Maybe check the FSUIPC & VRIinsight manual (or search the support forums). So, if you close FSUIPC, what is controlling the rotary assignments if your VRISim software isn't running? Ok, more relevant. But maybe better to exclude your lua's for the time being, especially LINDA, if your issue is just with your assignments. Are these the events fired when you turn your rotary: ? If so, what is sending them - I can't see anything assigned to those events in your FSUIPC7.ini file. Maybe you can let me know what/where the assignments to your rotary are (i.e. which lines in your FSUIPC7.ini)? And if its assigned to a lua (HDG.lua maybe?), then please show me that lua. Also, please activate logging for buttons & keys - this will at least show me which device/button number you are operating. And what is driving the display? Is that offset 07CC, the one you are logging? If so, please correct to log as S16. Does the display show the same as the offset (*360/65536)? Also, as another test, please try disabling your VRI device from FSUIPC7, but use FSUIPC7 for logging when you operate the device and the VRISim software is running, so we can see what is logged when it is running normally. Also, please check the FSUIPC & VRInsight document. It does say: You are not specifying the second COM port, but I do not not enough about VRInsight devices to know if this is needed or not. John

I'm not sure I understand your issue. Please activate logging and see what is logged in the different situation. You probably need to log Buttons & Keys and also Events, but if your rotary works on an axis you also need to log Axes controls. I don't have any VRI devices and no nothing about VRISim, but if your assignments are done by VRISim, why have you also assigned in FSUIPC? Wouldn't your rotary be assigned in both, giving such issues associated with assigning in multiple places? And I don't think its worth testing without MSFS running, and certainly not when using FSUIPC7.

Ah, yes - this can happen if you are changing screen sizes/resolution/etc. You just need to remove the Window ini parameter from the [General] section of your FSUIPC7.ini file so that it reverts to the the default size/position. I am also looking for a multi-screen solution for MSFS. I'll take a look at this, thanks. John

Then use a flag for the compound condition, and set/clear the flag on your 'shift' button. This is also explained in the same section of the Advanced User guide.

Not sure I fully understand this...why would the hat switch have double the number of functions, especially as you are already holding down one of the hat switches, so how can you trigger the others? Or do you mean that you are using a button (hat switch or otherwise) as a type of 'shift' key, and holding this down when you press another button triggers some sort of virtual button instead of the original button? We usually don't recommend using other config software if assigning in FSUIPC. FSUIPC reads your device directly at a low level and probably won't see these 'virtual buttons'. To achieve something similar in FSUIPC, you can use the Compound Button functionality, which allows you to specify actions for one button which are dependent on the state of another button (or switch). See the Advanced User guide for details (P22 in the FSUIPC6 manual).

👍😎

Ok, then you need to uninstall and re-install some VC++ redistributables. Please see the provided README.txt: I wouldn't do this just Yet. That error is most likely shown when MSFS tries to start FSUIPC7. However, it certainly shouldn't crash the sim - it should just prevent FSUIPC7 from starting. Anyway, uninstall and re-install the VC++ redistributables and see how you get on.

Does MSFS run without FSUIPC7 installed? Can you manually run FSUIPC7 (without MSFS running)? I see Pete has also replied: Uninstalling FSUIPC7 and running MSFS would verify that it is an MSFS installation issue. If its an MSFS installation issue, then check the Asobo forums and/or raise a ticket with them.

Great! Please try the attached version: FSUIPC6.dll

So MSFS is crashing even before it even tries to start FSUIPC7? It is the EXE.xml file that is created or updated, not the .exe. Did you install the FSUIPC WASM module into your MSFS Community folder? If so, try (temporarily) moving it out of your Community folder to see if that helps. Do you have anything else installed there?

Please try with this version: FSUIPC6.dll I can only see it occasionally in event.button, but I've added some extra logging around event.offset in the dll above.

Ah, sorry - I attached a debug build rather than a release build so you will be missing some windows dlls to run that. I'm going to add some more logging and I'll post a correct build later today for you to try.

Could you also try the attached version please: FSUIPC6.dll

Yes, the lua's were running as they were killed when you quit. Strange. What do you mean by this? The log should show each line of the lua being executed, so what wasn't expected? I've done further tests here and I can occasionally get an event.button not firing, but its very random, and never occurs when I step through in the debugger. I also can't get it to happen when I add additional logging to try and work out what is happening. Its very strange. - I'm thinking it could be a timing issue between different threads. I will keep investigating... John

You can either: - assign a button or key to the List Local Panel Vars control and use that - use the lua script log lvars.lua, included in the lua examples zip (in your FSUIPC documents folder).

Is this when MSFS is in full-screen mode? Strange, as I don't see this behavior. What happens if you press alt+f and then click the FSUIPC task bar item? And if you press alt+ enter (when MSFS has the focus - to put MSFS back in windowed mode) and then alt+f to display the FSUIPC window, does it then display ok? Has it always been like that for you? Nothing has changed in this area since initial release and this is the first I have heard of such issues. Do you have anything running (or an MSFS option maybe) that is keeping the MSFS window on-top?

I was also just replying when I saw Pete has replied... You should try this and also maybe activate logging for Buttons & Keys, and take a look at the log when you press the buttons (assigned to the flaps controls) and compare it to what is logged when you use the F6/F7 keys. You can post your FSUIPC4.log and FSUIPC4.ini files here and I'll take a look. John

Done.

Hvars are made known to FSUIPC7 via the use of *.hvar files. Do you have such files installed for the aircraft you are using? I don't think the installer will remove any hvar files that you added, although it may over-write the provided hvar files under the Community WASM folder so you may lose any changes to those files, which is why it is preferable to keep your (user) hvar files in the WASM persistent storage area. Please see the Advanced User guide (P44) on how to use hvars with FSUIPC7.

You should be able to run MSFS without an internet connection. What happens when you try to start MSFS from its own menu entry or desktop icon (or via the steam app if using steam)? I have deleted the similar posts you made in an unrelated topic (FSUIPC PFC Random Input - Need Assistance).

MakeRunways is a separate download, and is compatible with all versions of P3D, FS2002, FS2004, FSX and MSFS (all on Windows 10). It is available from www.fsuipc.com or the download section in this forum. If you already have it installed, it should work with MSFS, but make sure you are using the latest version. John