John Dowson

@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.

It is in your FSUIPC7 installation folder. together with your FSUIPC7.ini file (where your assignments are stored). If you cannot see the extensions, you need to update your Windows Explorer settings to show file extensions for known file types. Instructions are provided at the end of the Installation and Registration guide.

Have you calibrated your TCA Quadrant as described in the instructions? Please see the following post/comment (and subsequent comments for the download links): However, if its working for the FSLabs (and default aircraft?), then it may be due to the controls for that particular aircraft. Try switching to using the FS controls (and not direct to FSUIPC calibration), and try various controls to see what work for those aircraft. Please don't post screenshots or links to screenshot. We need to see your FSUIPC6.ini file to see your assignments, usually in conjunction with your FSUIPC6.log file (with appropriate logging activated). For trouble-shooting assignment issues, FSUIPC logging is your friend. Try activating axis logging and see what events you see when you move the throttle in the aircraft, and see what events are logged when you move your TCA throttle levers. Also, please check for other posts for the TCA quadrant and the add-on aircraft that you use, both here and in the forums for the add-ons that you use. This is a popular quadrant and there is a lot of information out there. The first thing I do when I receive such reports (as I have neither the TCA Quadrant or the add-on aircraft that you use) is google!

Ok, understood. Use event.button for now. I'll make a note to look into the LuaValue param issue when I get a chance.

Ah, then thats interesting. If MSFS CTDs, that should be reported to Asobo (via zendesk) with crash and event logs attached. Do you also have your FSUIPC7.log file from the crash? I'll take a look at the dump to see if there is anything there when I get a chance (but will take a while for this I'm afraid), but I suspect, as MSFS also crashed, that it is a simconnect issue thats affecting both client and server. Its more usual for such crashes to take down MSFS only, but then FSUIPC7 closes anyway (with auto-close activated), but it shouldn't crash. Another thing to try would be to activate simconnect logging (see FAQ section on how to do this). This would then show if there were any simconnect errors at the time of the crash.

Yes...is the speed an issue, or is the problem with the parameter being lost for the first call here: You are sending two different parameters to the same script at the same time, so it looks like the second is overwriting the first before it is processed (they are global parameters/variables). I'm not sure if I can do anything about this but I'll take a look (may take a few days to get around to this).

No, that doesn't matter. Did you change the stall parameters as suggested. Did you not see any stalled warning messages (or re-connects)? Maybe activate Extras logging as well. As well as finding out what clients those ids refer to (as suggested by Pete), you should also look for and count any connection closed and open messages, which will be when clients are re-connecting. That would be interesting to know. The start of the log file should show you the format of the open messages - just extract all of those from your log, together with any close messages. John