John Dowson

Is that the "Events" category from the FSUIPC Log menu? No. To activate SimConnect logging, create a file called SimConnect.ini in the FLT UNC Path (or FLT Path), as reported at the beginning of your FSUIPC7.log file (for Steam installs this will be C:\Users\<YourName>\AppData\Roaming\Microsoft Flight Simulator\, and for MS Store installs, this maybe under the LocalCache folder) with the following contents: replacing <path> with the path specification (e.g. file=C:\SimConnect%01u.log).

The SDK contains the following sim variables related to the bus, but nothing for the tie switch (unless its maybe the bus connection): BUS BREAKER PULLED TODO UNITS_BOOL TYPE_BOOL BUS CONNECTION ON TODO UNITS_BOOL TYPE_BOOL BUS LOOKUP INDEX Asobo (bpelmoine) Should be deleted once simvars support multi paramters UNITS_NUMBER TYPE_UINT32 EXTERNAL POWER CONNECTION ON Boolean, The state of the connection between a bus and an external power source UNITS_BOOL TYPE_BOOL If its not the bus connection, think you would need to submit a feature request for an additional event to allow this switch to be controlled.

These buttons don't log any events and there doesn't seem to be anything to control these either in the MSFS assignments or in the SDK events/variable lists, so I don't think this is currently possible. I can raise a zendesk issue/feature request, asking for events to control these be added to the SDK.

This has been fixed in the latest update. The problem was that FSUIPC7 was keeping the UserOpt.cfg file open after reading, preventing it from being updated. @Thomas Richter spotted this - thanks! John

You could try activating SimConnect logging, to see if anything is reported when the crash occurs. other than that, you should raise a zendesk issue with MSFS/Asobo, and include the windows crash report from the event viewer. If you want to test with a fresh ini, you could let FSUIPC7 generate a fresh/clean one, and then copy/replace all sections apart from the [General] section, and also remove the Path variable from the [Sounds] section, together with your missing yoke in the [JoyNames] section:

If the problem is with the client programs that use FSUIPC7, you really need to talk to their support. Do you have any issues with FSUIPC7 when not running those clients? If the previous version was with a build date of 26/09, then there were very few changes between the versions, the main one being the change to simconnect 0.6.0.0. Also, if it was a problem with FSUIPC7 and LINDA or ACARS, I would have thought it would affect many other users.

The latest documents should already be included in your FSUIPC installation. For FSUIPC4 & 5, this will be in your FSUIPC Documents folder, under your Modules folder. For FSUIPC6, you need to select the documentation during installation, and it is installed in a folder called FSUIPC6 under you windows Documents folder. You don't need this. FSUIPC has its own lua interpreter. There are various documents included with FSUIPC on the lua interface provided. However, for an introduction to lua or its standard libraries, please google.

Hi Marc, so MSFS is crashing, but why do you think this is related to FSUIPC? With FSUIPC now being an exe rather than a dll, it should not crash the sim. Even if its a problem in the server side of simconnect, it is still an issue with MSFS. There will be nothing in your ini that would cause this. You can try disabling the option 'Exit with FS', and FSUIPC7 will then still be running once MSFS has a CTD.

Yes, I'm not changing the version number at the moment, just the build date. This should be in the properties, as well as logged in the first lines of the log file.

You can see if its assignable in MSFS. If so, you can assign it to a keypress there, and then assign your switch to the keypress. If you do find something, let me know and I'll see if there's an available simvar or event that I can add. I'll also check the documentation to see if I can see anything that resembles this...

The "latest" release is always the only one available, and available from the same place. I suggest you follow the announcement page, where I comment when a new release is available (last release was 20 mins ago):

To control the eyepoint, I assign a hat switch to 'Select for Keypress' and then to Up, Down, Left, Right (i.e. numpad 8,2,4,6 with numlock off) on repeat, and that seems to work for me. For quick view, I assign the same keys but with a ctrl modifier (to a different hat switch!), and this also gives me quick-view functionality. John

But what version of FSUIPC6? If you are not using the latest (v6.0.10) can you please update and retry. There was an update for a bug in event.key that was fixed in that version. For support requests, either specify the exact version you are using or, better still, attach you log file so I can see what version you have + other information that is useful to me in helping you.

Can you please let me know what sim and what version of FSUIPC you are using (or show me your FSUIPC log file) Ok, so different from your original post....! You are saying that your script worked, but when you added the extra event.key call + function then it stopped working - correct? Does your aftertakeoff() function get called when you press the '191' key? Is you loop function still getting called by the timer? Have you tried activating logging for lua plugins?

Btw, is your lua even running? i.e. are you starting in somehow (e.g on a button press) or have you added it to your [Auto] section?

What sim and version of FSUIPC are you using? You could try activating key press logging, to see what VK keycode is logged when you press your key. Key code 191 is Numpad 7 (with NUMLOCK ON) according to the manual, BUT these keys vary from keyboard to keyboard. On my keyboard, Numpad 7 with NUMLOCK ON is vk=103. So it previously worked? What has changed? Maybe your NUMLOCK is OFF?

@EdwardSm Please try as Thomas suggested and use an installation folder for FSUIPC7 outside of the MSFS folders and report back, thanks.

This question has been asked many times before - please check the forums before posting such questions, e.g. etc

What crashes - MSFS or FSUIPC7? As I said, if its MSFS, you need to report to Asobo. If its FSUIPC7, I need more information - you FSUIPC7.log for a start, and also any crash entry in the Windows event viewer. But multi-player and AI traffic type are different settings. You can have aircraft traffic type set to AI Offline or Real-time Online (or Off), and also multiplayer data set to on/off independently So, are you saying MSFS crashes or FSUIPC7 crashes, and is this when you have aircraft traffic type set to Real-time Online AND multiplayer data set to on only? Sorry, but I need more information as I don't understand what the problem is or what you are requesting.

I have a steam installation, and I've tested this and experience the same - my settings aren't saved if I close and restart with FSUIPC7 still running. Very strange. There is nothing in FSUIPC7 that could prevent this - its only a SimConnect client as far as MSFS is concerned. I'll do some more tests and maybe report to Asobo.

No, the x3365 value only supports 'main menu', i.e. when you cancel the flight. In dialog menus are not currently supported - they will be accessible when in escape pause.

There are no facilities in SimConnect (that I am aware of) that are specifically for multi-player traffic. Aren't multi-player traffic treated simply as other AI aircraft, from the user perspective? so MSFS crashes? That should be reported to MSFS/Asobo. I'm not sure what, if anything, FSUIPC can do with mult-player traffic, or if distinguishing multiplayer traffic from AI traffic is even useful. I'll look into it at some point.

But it isn't....! The problem is that the events to control the camera are currently not working when sent via SimConnect. Due to this, the suggested work around was to assign the camera movement events to keys in MSFS, and then assign your POV switches to those keypresses in FSUIPC. This should work, but there is nothing to implement for this in FSUIPC. Be aware that you shouldn't assign using the ALT modifier though as this is no longer supported in MSFS.

This seems very strange - I'm not sure why FSUIPC would prevent MSFS from saving your graphics settings. There is certainly no setting in FSUIPC that can control this. Where did you get this advise from in the forums - can you share the link please?

I have added these in the attached version 0x0B4E 1 Byte FLAP SPEED EXCEEDED 0x0B4F 1-Byte GEAR SPEED EXCEEDED 0x0C0C 4-Byte (integer) MAX RATED ENGINE RPM I've only checked these in the C172 at the moment, and the MAX RATED ENGINE RPM seems to come through ok (2700) but I havn't seen the flap/gear speed exceeded flags changed, so not sure if these are currently working. FSUIPC7.exe