John Dowson

Please repeat the test with the attached version, v6.1.1g, and show me the log. Also, please show/attach the full log, not a continuation log. Thanks. FSUIPC6.dll

First, please give your post an appropriate title, relating to your issue, not your name. I have updated it for you this time. You are looking at the offset status document. For FSUIPC7, this is old/out-of-date, and must be read in conjunction with the offset status spreadsheet that is included in the zip you downloaded. If you take a look at that spreadsheet, you will see these offsets are in red, i.e. not working. They are not working as they were populated from lvars in previous versions of FSUIPC. Even though we now have access to lvars in MSFS (via the v7.1.0 beta currently available and soon to be released officially), they won't be the same lvars as for other FSs. If there are lvars available with the information you need, you could try reading the lvar directly (using the latest beta), or have a simple lua script that writes the lvar value to a user offset for you to read. I've attached the latest offset spreadsheet for you. offsetStatus-v0.18.ods

Ok, thanks. However, the logging I was after (slope adjustment) doesn't seem to be present. I think I may have added that logging to FSUIPC7 only at the moment, so I'll add that to FSUIPC6 and post you another dll to try, to produce the same log.

Yes, sorry - you already have a calibration section in your ini. I missed it as there is no new line before it for some reason! Could you activate logging for Extras please, as well as Axes Controls, produce a short log file showing your issue (i.e. move each brake through its full axis range). and show me the log file. Thanks.

In the calibration tab (not the axis tab)? It shouldn't be, as you have no profile specific calibration, only profile specific axis assignment.

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.