John Dowson

Without FSUIPC or Linda running? If so, then SetialIFP2 must be getting the input from your rotaries and changing the display. As I have said, there is no point testing this with FSUIPC without MSFS running. Is this with SerialIFP2 running AND configured properly in FSUIPC using the real and virtual com ports? If you have not tried to configure using SerialIFP + FSUIPC as described in the manuals, you should really try this before anything else.. And if using Linda, you should ask on the Linda support forums, if it is Linda that is driving the display. You should also try with other simpler/stock aircraft, and not he FBW A320 - maybe the A320 is not using the Autopilot Heading Lock Dir sim variable. Have you tried with other aircraft? You can also try logging VRI coms by adding the following to the [General] section of your ini (although I doubt this will reveal anything of use): Debug=Please LogExtras=4 Have you used this successfully with any other flight sims - FSX or P3D)? Other than that, I do not know what to advise with this. There have been no changes in this area for many years (apart from the addition of the VRIDisableCMDRST ini parameter 2.5 years ago), so I suspect it is either related to your configuration or maybe MSFS+FBW. Maybe some other VRI users can help...

No, as its not FSUIPC that is crashing but P3D. You could try logging VRI coms, which you can do by adding the following to the [General] section of your ini" Debug=Please LogExtras=4 Sorry, I don't have any VRI devices.. Maybe some othe VRI users can help you. There is also another VRI support request open at the moment with a different issue - see Maybe you can help each other?

It is MSFS that is crashing, not FSUIPC7 - from your log: Check the Asobo forums and/or raise a support ticket with them.

You could maybe convert the them to use the Wnd library. A demo script attached. FPS_MonitorW.lua

unfortunately that is not the case - I'm just another MSFS user to Asobo. I reported this a long time ago - and have heard nothing, as usual. In fact, previously some basic functions of the SimConnect_Text function were working (sort-of) but it is broken completely since the SU5 update. I'll check to see if there is anything about this in the Asobo fotums and maybe raise again, but it IS known by Asobo - from the documentation: Page Contents (click to expand) SimConnect_Text The SimConnect_Text function is not currently available for use. Syntax N/A

I'm sorry but I don't understand what you mean. If you already have profiles defined, you just install the new version of FSUIPC into the same folder and everything should just work - you don't need to change anything. If you install into a new folder, then you need to copy across all your files (.ini, .key, lua, macros, dlls) to the new folder. But why are you doing this? Were your profiles actually working before you did this? But were there any profiles in the ini before you made that change? Maybe show me your original ini, if you still have it, together with your new one and your log.

First, you posted in a sub-forum which states: NOT for support requests. I have moved your post for you. Sorry, bit what do you mean? There is no installer for MakeRwys.

@Eduardo P Please NEVER post details of your keys - you showed these in the image you attached. I have deleted it. If you do this again, your keys will be added to the banned list. Yes, as I said. But you probably sorted this out yourself at toughly the same time. You should of added an additional post though, and not completely changed your initial post, although its not that important - just means my reply to your original post no longer makes sense! John

FSUIPC will use the FSUIPC6.ini located in the FSUIPC6 installation folder, and will create a new/default one if non is found. It sounds like you have re-installed in a different folder, si when you ran FSUIPC6 for the first time 9in this folder) it would have created a new/default ini, and so it would have no profiles (or assignments). So this sounds like you are looking at the old ini. Just copy this (together with any luas, macro files, dlls, etc) that you are using to your new installation folder. Alternatively, re-install but into the same folder as your previous installation (i.e. where your FSUIPC6.ini with your profiles/assignments is located) If you do not know where your installation folder is, use the 'Open Folder' button in the Logging tab. And, when installing, please take care on the selection of the installation location. If FSUIPC is already installed, it should (always) default to the same location - did you change this? Please see the Installation and Registration guide for details. John

I think your WideFS7 order number (purchased with FSUIPC4) is 1207799. Note that your email address for WideFS7 is ecppassos@*****.com, whereas your email address for your FSUIPC6 license is ep_simp3d4@****.com. As these are different, you need to check the 'Check if using a different Name or Address for WideFS' box, and enter the WideFS Name and Address again. I've verified here and both your FSUIPC6 + WideFS7 license are validated ok, so please try that. Thanks, but you only need one license which covers 1 user, multiple seats. You only need additional licenses if there are multiple users (i.e. for commercial use). John

👍

Please try the following dll - Local Day of Week has been added to offset 0x026C as an unsigned byte (UB): FSUIPC6.dll

Hi Ray, there is a Local Day of Week simvar that I can add to an offset. Give me a day or two and I'll post an updated dll here for you to try (FSUIPC6). Otherwise you could look into lua functions to convert a zulu time to another timezone, then extract the day, but I'm not sure what lua API/functions you would need to do this without investigating.

No, not at the moment - it is something I should add really. Just check the Download page in this forum occasionally, or watch/follow the download page and you will be updated when the page changes, whuch means a new version of something has been released - but not necessarily FSUIPC7. Cheers, John

You don't need the '0039' - that is the index number of the variable, so use: [LvarOffsets.TBM930] 1=L:Generic_Master_Warning_Active=UB0x66C0

Please check your FSUIPC7.log file. You will most probably see that FSUIPC7 is exiting as MSFS has crashed. If this is the case, you need to determine why MSFS is crashing and report to Asobo. There is an issue in FSUIPC7 if using the lvar-to-offsets functionality with a code of UD/SD. This has been corrected in the version posted in the following post, and will be released in the next few days:

Please try again - it was a http link which I have updated to https. A single click should work, if not, right-click and select 'Save as...'.

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.