John Dowson

Do you mean to ask if there is a control/event to control the TERR ON ND switch? For which aircraft? A320 I presume, but it really helps if you can give more information when requesting support.... And do you mean an MSFS control or a MobiFlight one? All MSFS controls are listed in the controls document that you will find in your FSUIPC documents folder. For MobiFlight events, you need to ask MobiFlight, or download the latest release and take a look at their events file. For the A320, there is the lvar BTN_TERRONND_ACTIVE Of course, you can't use that directly using FSUIPC7 at the moment. Lvar support is still a few weeks away, although I hope to be releasing the FSUIPC WASM module for beta testing in the next few days.

Your EXE.xml is now correct. I don't know what created Rick's EXE.xml, but it wasn't FSUIPC. As well as being incomplete (but that may be a paste problem), it should have the CommandLine option (-auto) and needs the <NewConsole> entry. His document Type is also incorrect, as Simconnect rather than Launch. That may also be valid though, I'm not sure.

Yes, that is where it should be. But I had a report in the earlier beta releases where the UserCfg.opt was in the LocalState so I added this as a fallback if it couldn't be found in LocalCache. I can probably remove this now. Ok, understood. I have also had reports of the EXE.xml not working and it turned out to be due to a malformed EXE.xml, with the Type being 'SimConnect' rather than 'Launch', so there is another installer out there that is also writing dodgy EXE.xml files. The FSUIPC installer will create the file (in the correct format) if it doesn't exist, and just add the FSUIPC entry if it does - it will not check the existing content. Yes, thanks.

Thats very interesting! That i the location for Steam installs, it won't work with MS Store installs. But in 8 you say it was working in the LocalState folder - was this with the EXE.xml also in the LocalCache folder then? No - by default, the installer should create the EXE.xml file in the LocalCache folder, but ONLY if that folder also contains a UserCfg.opt file. If not, then it checks the LocalCache folder for the UserCfg.opt file, and if its there instead it will use that. Yes, I think this is the problem. You should report this to the developers of that software. Any updates to the EXE.xml should preserve existing contents. Thanks for the report. John

That was the default installation path in earlier versions of the installer - this has now changed. However, when you re-install, the default location will be the previous installation location. Event though that location was the default, the Installation and Registration guide advices that you should change this. It is the folder where the add-on.xml file goes for auto-discovery by P3D. It is better to have the actual installation folder in a different location. But if its all working now, you can just leave things as they are.

Which FSUIPC6 folder - did you move the sound files to your new installation folder (C:\Users\Myname\Documents\Prepar3D v5 Add-ons\FSUIPC6)? If so, then your 3rd attempt would have worked if you had escaped the backslash, i.e. try sound.path("C:\\Users\\Myname\\Documents\\Prepar3D v5 Add-ons\\FSUIPC6") or simply sound.path(".\\") (i.e. the current folder) Then you can just use that path, i.e. sound.path("D:\\Program Files\\Lockheed Martin\\Prepar3D v5\\Sound")

@David BrewsterI've just noticed that you are manually adding the [LuaFiles] section on these instructions. You really shouldn't do this as this is an automatically generated section, which is written by FSUIPC on start-up when it scans your folder for lua files. Probably also why you were getting this section twice in some instances.

Yes, will do.

Thats fine, but as this seems to be an ongoing issue I'd like to know what is causing this and if there is anything I can do to get around this. Another user has reported an interesting observation with the EXE.xml (not starting programs more than one folder deep), but it doesn't apply in your situation - see Can you show me/attach your EXE.xml file again please. If that has the correct format and is in the correct location, I do not understand why MSFS isn't picking it up in your installation.

Thats very interesting...thanks for reporting. Very strange though, and something that should be reported to Asobo.

Yes, I understand now.

The FSUIPC entry added is correct, but the rest isn't! Something else must have written that before you installed FSUIPC, and made a bad job of it.... Change: <?xml version="1.0" encoding="WINDOWS-1252"?> <SimBase.Document version="1,0" Type="SimConnect"> <Descr>SimConnect</Descr> <Filename>SimConnect.xml</Filename> <Disabled>False</Disabled> to <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>EXE.xml</Filename> <Disabled>False</Disabled> Leave the FSUIPC7 entry as it is. Than try again. You should also commend-out the start of FSUIPC7 from the MSFS.bat file so it doesn't try and start two copies. Or you could just delete that EXE.xml and re-install. It will be re-created with the correct format.

Did you used to have a steam install by any chance? It seems that the installer thinks that you have a steam install as it has found this file: C:\Users\miros\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt That shouldn't be there, as your UserCfg.opt file for MS Store installs is C:\Users\miros\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt (or maybe under LocalState rather than LocalCache) Please check those locations. Then you can either: - remove the UserCfg.opt under C:\Users\miros\AppData\Roaming\Microsoft Flight Simulator\ and re-install FSUIPC7, or - move the file C:\Users\miros\AppData\Roaming\Microsoft Flight Simulator\EXE.xml to the folder C:\Users\miros\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\ (or LocalState, depending upon where your UserCfg.opt file is located).

Luas are NEVER automatically added to the [Auto] section. They are automatically added to your [LuaFiles] section. They are different. Certainly all luas should NOT be auto started, that depends on the lua, so we cannot automatically do this.

You may have to add a couple of substrings rather than one regex expression, but I think that is far easier than using regex expressions for the standard user. If you don't think that is sufficient, please provide me with an example where substring matches won't work for you.

FSUIPC uses DirecInput. The P3D option for this is used when assigning in P3D, not FSUIPC.

The managed/selected modes are switched using the *_SLOT_INDEX events (plenty of info on the Asobo forums on this. e.g https://forums.flightsimulator.com/t/simulator-events-for-switching-between-managed-and-selected-mode-in-the-a320/323838). The variables AUTOPILOT ALTITUDE /HEADING/SPEED SLOT INDEX sim variables are held in offsets 0x0290, 0x0284 & 0x0298 respectively, so you can try those There may also be some aircraft-specific lvars that hold this state, but to use those in FSUIPC you will need to wait until I have provided lvar access functionality.

Sounds like the installer determined that you have a steam install rather than an MS Store install. Did you run MSFS at least once before trying to install FSUIPC? If not, try re-installing to see if that fixes it. Otherwise, show me you InstallFSUIPC7.log file, as well as a FSUIPC7.log file.

I thought that one of the main features of Linda was that it provided the lua scripts that you need so you don't have to write the lua scripts yourself... You can, of course, use lua in FSUIPC without using Linda. I don't know what you mean by this... What do you mean by 'in real life'? Its a hardware controller, it is real life... And what do you mean by 'requires two trim switches to be activated to use the yoke' mean? There are plenty of folks using the Honeycomb Alpha with FSUIPC and this is the first I have heard of this... I do have a Honeycomb yoke, but its still boxed since it arrived 2-3 weeks ago, as I just haven't had time to take a look at it yet....

But you can do this already with the 'substring' match facility. I guess I could match on regex expressions, but I don't see any benefit in doing this as you can already match on multiple substrings. I think adding regex expression matching would probably be more confusing for most folk.

That is not the issue! You have reverted to the previous way of starting FSUIPC7, directly from the batch file rather than having it started by MSFS using the EXE.xml. You log file shows the EXE.xml was updated: Could you show me that file please. I have had one or two other reports of the EXE.xml not being processed correctly by MSFS. I'm not sure why this is, but if the EXE.xml is as it should be, then for now you will have to use the old method, as you are now doing.

There is no change in this in v7.0.5. Are you sure you selected to install the auto-start component? Try re-installing to make sure, and if you have the same problem show me your install log file.

Don't worry about it - If controllers are disabled in P3D, they won't have any affect.

You should really be using the JoyLetters facility, as this was designed to prevent problems arising from when your joystick IDs change. Please activate this facility by setting AutoAssignLetters=Yes in your FSUIPC6.ini [JoyNames] section, start P3D, load an aircraft and then close, and show me both you FSUIPC6.ini and FSUIPC6.log files please. Attach them, do not post extracts - I need to see the full files.

No, shouldn't be an issue. No - the event.button just registers the callback function. The rest of the script will process and the thread keeps running once the end of the script is reached. When the button is pressed, this is picked up (by the still running lua thread) and you callback function called.