John Dowson

Ok, thanks. Maybe also post the cause on the avsim thread you created for the same issue (presume that was also you, no?).

Are you running any Honeycomb Bravo software (e.g. Configurator tool) by any chance?

The lag may be due to the fact that you are assigning your throttle axis to send to the FS as a normal axis, and then calibrating in FSUIPC. First, you can try removing the calibration for your throttle axis to see if that works. If not, and you need the calibration, try switching to 'Send direct to FSUIPC calibration' and then calibrate your throttle in FSUIPC. We allow calibration of axis send to the FS, but these values then come back from the FS to be calibrated and then sent again. This results in two round trips from FSUIPC to the FS to set the axis value. This can also cause issues due to priority levels when using certain aircraft (usually complex add-ons), but also introduces an additional lag. This was not that noticeable in previous versions of FSUIPC when it was a dll embedded in the FS, but now that FSUIPC7 is an executable and runs in a separate process, there will be additional communication overhead that can cause issues.

Sorry, but which radio switch do you mean? Also, are you using the stock A320 or the FBW mod? If its the 'Interphone Radio Switch', this seems to be 'inoperative' in both models at the moment, so I doubt it has a value. If its another switch, please let me know which. You can also take a look at the offset document to see if anything matches, or you can also check if there is an lvar available that holds the switch value (using the latest 7.1.0 beta). If there is, you can use that directly or write the value to a user offset if you need it in an offset.

Could you try calibrating your left/right brake again, but this time check the 'Profile specific?' checkbox. Not sure why the general calibration isn't being used as there is no profile specific one - I will look into this. John

Yes, there was read protection added to offset A000 for some reason. I have removed this in the attached version:, v7.1.0g: FSUIPC7.exe

Both of your logs attached are continuation logs. I need to see the full log, not a partial one. Could you please provide a full log. Also, please close down P3D/FSUIPC before you attach the log.

Ok, I'll take a look tomorrow now. Finishing for the day....

Ok, good to know, thanks.

Well, yes, that would be ideal, but I'm not sure its possible. The problem is that its Windows that elevates the installer to Admin, and so by the time it hits the installer code there is only the Admin user, and no way to determine the 'actual' user. Windows tries to determine how you do these things - see the answer to the same question posted here: https://stackoverflow.com/questions/48844435/get-logged-in-username-in-nsis-installer-when-running-as-another-user-admin That may be ok for Documents, but other locations (e.g. UserCfp.opt file) are mandated by the version of MSFS you have, and most users would not be able to determine this, it needs to be done by the installer. As I have said, this is the first time I have heard of this problem in 3 years or so, so I'm not going to spend more time looking into this. For now, you will have to live with giving your user account temporary admin privileges, as advised, and I'll also recommend this in the Installation manual for any other users who have the same issue.

Hi Peter, ok, glad its now working (and a bit of a relief!). Thanks for the update. You could also try without the event.terminate, to see if that works in the latest version...or did you try that already? John

This is interesting: So yes, you are correct. I think the simplest solution in your situation would be for you to temporarily give your user account admin privileges (uninstall first). Then re-install, then remove the admin rights. I have put this on my list to look into, but this will take quite a while as it is low priority.

Yes I know, but not one person with this issue in many years sounds suspicious... And, as I said, the installer doesn't/shouldn't request admin privileges anyway - from the installer: i.e. commented out. I will look at this at some point to clarify, when i have more time. That is not necessary. I understand what you think the problem is and may be, but am confused as to why it is doing this. But you shouldn't get this. As I said, it is not installed as a privileged user. You should not have to enter any password. As i said, I will look into it, but not now. It will be low priority I'm afraid, so when I have time. Once I've looked into it, I will post and updated installer for you to try.

is also almost certainly caused by the same problem But it doesn't do this for any other user - the installer is the same for all other users and I've not come across this before..... ...and the installer no longer requests admin privileges anyway...

Thats code from the installer to determine the location of your UserCfg.opt file.Thats whats failing for you during installation, and so thinks you have an MS Store install.

FSUIPC installs nothing in the Admin folder, unless you are running as admin. However, yout installation log does indicate that it is installing in the admin folder: Not sure why thiis is either. Did you install the first time as admin? Once installed, it will use the previous location in the registry the next time you install. Try running the uninstaller manually (from the FSUIPC7 installation folder or the Windows App management panel) and re-install again, to see if it picks up your correct Documents folder. And show me the new InstallFSUIPC7.log file please. Your Documents folder is taken from the registry for a fresh install, using the HKCU Personal key under "SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" Due to these errors, there may be some other empty folders that have been created that you may want to move: Create folder: \fsuipc-lvar-module Create folder: \fsuipc-lvar-module although those may have failed....Thats an issue in the installer which I will correct - it shouldn't try and install the WASM if the Community folder can't be determined.

Then I have no idea why this test is failing: IfFileExists "$APPDATA\Microsoft Flight Simulator\UserCfg.opt" steamUserCfg nsArray::Set LogMessagesArray "Determing Community folder for MS Store install" ... steamUserCfg: nsArray::Set LogMessagesArray "Determing Community folder for Steam install" Looks to be a space between your t and a (e.g 'AppDat a' as opposed to 'AppData', but maybe thats just your image/font/my eyes... Other than that. I have no idea why its not determining the correct location. It works for everyone else...very strange....

vJoy won't do anything by itself unless you have also assigned to the virtual buttons its using....show us you .ini and .log, with the advised logging activated, which should hopefully show what is happening.

The World Update II was just scenery, and the SDK does not know about lvars/hvars, so I'd find it surprising if thhey changed anything. Weird..

Well, not according to the installer. You should not modify the batch file. Remove that and add the folder C:\Users\jackp\AppData\Roaming\Microsoft Flight Simulator : EXE.xml If you already have aan EXE.xml file there starting something else, just extract the "<Launch.Addon>....</Launch.Addon>" section that starts FSUIPC7 and add that.

Anyway, here's the WASM. Just extract into your Community folder and it will be recognised by FSUIPC: fsuipc-lvar-module.zip The other issue you will have though is that FSUIPC will not autostart with MSFS as it cannot find the location of your EXE.xml. Did you not notice this? Is it a problem?

You do not (and should not) install as admin. The problem, for your installation, looks to be that your APPDATA environment variable is not set correctly and the installer cannot find your UserCfg.opt file location. Can you check what this is set to? Should be 'C:\Users\jackp\AppData\Roaming'.

Yes, It can be omitted, sorry. Please generate a short log as advised. It shouldn't be. Turn off other logging, especially IPC Reads/Writes that will make the log huge. Also add offset logging for the offset you are using, 0x66C0, as U32 in hex. Note you can also use the DontLogThese ini parameter (both in [General] and profile sections) to prevent the spurios logging of many events in various aircraft.

Perhaps I should have been more clear. I'm not trying to set the value of the 03C0 offsets directly. If you look closelier at the .ini line I used, I'm not setting that offset directly, I'm simply pressing the associated button (actually... I'm using the control to set that buttons flag... 1003). By my understanding that should change the offset to reflect that the button was pushed except for this: Again in my initial questions I said: I couldn't tell exactly from this post whether or not "when there is at least one assignment to that joystick" means "when there is an actual device in the [JoyNames] section mapped to joystick number matching the offset I'm trying to read... OR if it means "when there is an entry in the [Buttons] section that uses that joystick as the trigger". Since I wasn't sure and I can't force a particular device to be assigned to joystick number 15 (or at least, I don't know how to force that assignment) I tried to add an entry in the [Buttons] section for with joystick 15, button 9 as a trigger with the "no-op" control and it still didn't work. Because of this, I assumed that you must've meant "when there is a [JoyNames] assignment" as opposed to a "[Buttons] entry". Perhaps you could verify that I'm correct about this. Offset area 03C0 is what FSUIPC maintains for button presses. You can/should NOT wtite to it, by any means, either directly. You cannot set a button flag on a joystick tat doesn't exist. Please just forget this offset for your issue. You don't need the mobiflight wasm if using FSUIUPC, but you can use the mobiflight events instead of the fsuipc facilities if you prefer. You image shows that the FSUIPC WASM module was not installed. Looking at yout log file, it shows this: Do you have an MS Store install or a Steam install? Do you know the location of your MSFS UserCfg.opt file?

What has changed on your system since this change? Was anything updated - MobiFlight, G3000 or the 580 overlay?