John Dowson

I am not sure why its taking so long - I will take a look to see why, but I doubt very much there is anything that can be done to speed this up - its probably related to the gauges/panels dlls that are used to get the lvar values. You could try switching to using the event.lvar function instead, and only write the lvar value when it has changed. You can use the same handling function for all lvars, which will be passed the lvar name as well as the value, so you can have a conditional statement on the lvar name to determine the offset and then set the value. John

You will get a discount when purchasing FSUIPC7 if you have a license for FSUIPC6. John

No - something must be setting the weather, and something clearing it... That is very strange - I don't know what could cause that, but sounds like it may be a memory corruption somewhere. Maybe try installing the P3D client to see if that helps. Until next week... John

Active Sky does not use FSUIPC to inject weather. No - weather manipulation facilities were removed from FSUIPC a long time ago. However, I think there is still a hot-key that allows you to clear the weather, but you need to set this and use it (see the hot-keys tab). You can try logging weather changes (see the logging options) and look at the log to see what is happening - you can attach it here if you like and I can take a look, but I am now on holiday until Tuesday next week. You can also try adding NoWeatherAtAll=Yes to the [General] section of your FSUIPC6.ini. This will make FSUIPC avoid all weather reading and writing activities. Try this and see if you get the same issue. John

Try running with the logging console window open (Log-> Open Console) - you should see when the lua auto files are started. Check to see if this lua auto is started and then try to use it. Just show me your .ini and .log files, the latter generated with Lua Plugins logging enabled and showing your issue. I am now on holiday, back Tuesday, so I will review your files then. John

Ok, but I presume you are also using one of the FSUIPC PFC drivers with FSUIPC... Yes, I understand this. But how is this device assigned? Does it have its own drivers and/or software? is this assigned in MSFS or elsewhere? Does it function correctly in MSFS2020 when FSUIPC7 is not running? Ok. For the log file, can you please activate logging for Events and Buttons & Keys, load an appropriate aircraft and then press a couple of buttons on the GTN 500 that you are having problems/conflicts with, and remember to exit FSUIPC7 before attaching your FSUIPC7.log and FSUIPC7.ini files. Also attach your FSUIPC7.JoyScan.csv file just in-case I need to see that as well. Thanks - you as well, John

What PFC driver are you using? I am pretty sure the PFC driver for FSUIPC is not compatible with XPlane/XUIPC... The FSUIPC PFC HID driver has automatic assignments (i.e. you don't need to do anything) via macros, and for the COM driver you have to assign manually, so there are only assignments that you have created/added. Ok, then the PFC driver is not relevant, and I cannot see how FSUIPC can be doing anything - I need to see your files. Note also that I am finishing for the day soon, and I am away from tomorrow morning, back on Tuesday, so I will probably not be able to review your files until next week.

That ini file is very strange and completely empty, i.e. no assignments whatsoever, and no devices recognised. This cannot be the ini file form your previous installation if you had assignments. It also shows that you are using a very old version of FSUIPC7, 7.4.3 - please update to the latest version, 7.4.8. This is because no devices are recognised (no devices section in your ini file) and so no button press was detected. Try an located your FSYUPC7.ini that holds your assignments, update to the latest version and try again, and attach your files again (FSYUPC7.log and FSUIPC7.ini) if you have any issues. John

I still don't understand this - what exactly is grayed-out? If you have an Assignments menu option in the menu bar, then you should be able to open the assignments panels. Maybe attach a screen-shot so I can see what you mean here. Be aware that if an assignment is shown in the buttons assignment panel and it is grayed-out and you cannot change/edit it, this is because there are either multiple assignments to that button (the button assignment is overloaded), or you have added either a compound button or offset condition. With such assignments, you can only change by editing the FSUIPC7.ini file (as you did to add/create this condition). John

What exactly do you mean by this? If you have not assigned anything to the GTN500 in FSUIPC7, then it should not do anything at all. Maybe there is an id conflict (so it is picking up assignments for a different device)? Can you please attach your FSUIPC7.ini, FSUIPC7.log and FSUIPC7.JoyScan.csv files and I will take a look. But there should be no commands for this device unless you have added them. Or is it also a PFC device controlled by the PFC driver? Where is this device assigned? John

I still don't understand this - what exactly is grayed-out? If you have an Assignments menu option in the menu bar, then you should be able to open the assignments panels. Maybe attach a screen-shot so I can see what you mean here. Ok. John

Yes, just a "glitch"...if it happens again, try a system reboot - that usually sorts things out. Anyway, glad its all working again. John

That is very strange as that is related to FSUIPC7's monitoring of MSFS2020, and nothing to do with client applications connecting to FSUIPC7. Maybe it was something temporary...can you try removing that now and see if it connects or not. Note that option is set automatically if running under windows 11, which you seem to be using - from your log file: Therefore I cannot see how that can change anything... How about those other two apps - PACX and Self Loading Cargo?

When I start LRM, it connects straight away when FSUIPC7 is available/running, even without MSFS running, regardless of the order in starting. The usual reason for clients not connecting is that they are being ran at different priority levels - everything must be ran at the same priority level. Could you be running these clients with admin privileges but not FSUIPC? If you has set the previous versions .exe to run as admin, you will have to do this each time you update. John

Also, please note that your old FSUIPC7.ini may not work directly out-of-the-box with your new PC, as the GUIDs of your devices/controllers may have changed. If you run FSUIPC7 ince with your old ini, exit and then attach your updated FSUIPC7.ini file here, I can take a look and update it for you if needed. John

That log file shows that FSUIPC7 was still running when it was attached. Please ALWAYS exit FSUIPC7 before attaching log files. Can you also attach your FSUIPC7.ini file please. This is rather worrying: Do you not have any general button assignments? John P.S. Try attaching here now instead of file.io

No wonder the file is so large - you have a lot of unnecessary additional logging activated. Please disable all logging for the moment and show me a clean FSUIPC7.log file. Also please make sure that you exit FSUIPC7 before attaching the file. John

The FSUIPC7 config file, where all your settings and assignments are stored, is called FSUIPC7.ini. The config.ini file is nothing to do with FSUIPC7. What do you mean by this? For auto-start issues, see What do you mean by this? What is grayed-out? Are you running/using a licensed/registered version or the freeware/unlicensed version (i.e. Do you see an Assignments menu option in the menu bar)? They will be in your original FSUIPC7.ini file. John

Your upload file size will increase the more you post. I need to see your FSUIPC7.log file though - try compressing it, or use an on-line file sharing app (e.g. https://www.file.io/) if the file is still too large. I will take a look with LRM later as I believee that is a free one I can test with here... John

Ah, ok then. Must be the device also returning a non-usable GUID for some reason. Just ignore. Your files look good! Regards, John

Great! Do you have two VPC Panels or just the one? The HID scanning reports two of these, but only one is acquired: The 2nd one looks dodgy (N in ValsOk? column) so maybe there is only one of these devices and that can be ignored... John

Ok, its good to know the cause. Thanks for updating, John

It would be useful to understand what actually causes this warning - any ideas?

As I said, FSUIPC does nothing with such files. I don't see any good reason why these files should be loaded, but many possible difficulties (e.g. how is FSUIPC supposed to know the name if this file?). As I said, if you want some data from such files available via FSUIPC offsets, then you will need to write a bespoke lua script to read/parse the file, extract the data you need and then add this to a free/spare FSUIPC offset. John

Can you also add custom logging (Log->Custom) with a value of x200000 - this will log further information around the acquisition of HID devices.