John Dowson

Use ipc.writeUB(0x66C0, 1)

That certainly shouldn't happen and is the first time I have heard this... You can only minimize the main FSUIPC window, and then it sits in the task bar like all other windows apps, until you open it. However, if you close the main window, FSUIPC7 will go to your system tray - did you look there? You can double click to open, or click/right-click for the context menu for direct access to some functions. You can also use Alt-F (default, can be changed) hot key to open/close FSUIPC7 to/from the system tray.

Do you have an aircraft loaded, i.e. not in the menu screens?

In the Add-ons menu, you should see a WASM entry. Under that, you first need to Enable (you only need to do this once). Then the other menu entries should be available, which let you explore (list, set, etc) lvars. Best to have you plane loaded and 'ready-to-fly) before you start experimenting. The menu entries under the WASM menu are just for exploring/testing. Once you tried some and found the ones you need, I can show you how to add them to offsets or use them in assignments.

Ok. Then we need to find if there are any lvars that control this. First, you need to download and install the latest beta of FSUIPC7 that has access to lvars, available here: Then you need to determine the name of the lvars that control the nd range and arc. For the mode itself, I think this is held in the lvar A320_Neo_MFD_NAV_MODE_1 (or possibly A320_Neo_MFD_NAV_MODE or A320_Neo_MFD_NAV_MODE_2 - you can try them all), with values: 0: LS 1: LOC 2: NAV 3: ARC 4: MAP For the range, try A320_Neo_MFD_Range_1 (and also A320_Neo_MFD_Range and A320_Neo_MFD_Range_2), with values: 0: 10 nm 1: 20 nm 2: 40 nm 3: 80 nm 4: 160 nm 5: 320 nm First try downloading the beta and see if you can see these and change their values by using the Add-ons->WASM Set Lvar / List Lvars menu entry. Once you have found the lvars that you need, I can help you use those either directly in lua or use lua to put the value of the lvars in a free user offset for you to use as needed (for read purposes). To update, you need to either use an lvar macro or again a lua script, which I can also help you with.

The position of these switches can be read (and written to/set) using the following lvars: XMLVAR_RMP_R_On XMLVAR_RMP_L_On with values 1 for on, 0 for off. You can write a short lua script to read those values and populate a user offset. Note that you need to download the latest beta of FSUIPC7 to use lvars (latest version currently 7.1.0g), although I am planning to release this officially in the next day or two.

Not necessarily... Well, if you are building your own AP panel, then that would be the difficult part (for me at least!). Lvars are not difficult to use, and I can help you using those or getting the values into offsets, if available. Which aircraft (and mod, if applicable) are you using?

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.