John Dowson

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

Sorry, but I cannot help with other products that use FSUIPC7. You need to talk to LINDA, ACARS and SLC support for this. There is an issue with the pause state indicator in that build, due to changes in the 1.9.3.0 release of MSFS. I'm not sure if that would affect LINDA and ACARS, but you can try the following build where this issue has been corrected: FSUIPC7.exe

There is no way to disable controllers in MSFS. You can create a new 'empty' profile (all new profiles are created empty) and use that.

@IanAbel Could you try the attached version where it should be working again. Offset 0x3365 should now also correctly reflect when the sim is in the menus: FSUIPC7.exe

Can you try the attached version, in which offset 0x3365 should contain 1 when in the menus and 0 when in game. You may also want to read in conjunction with offset 0x0264, the pause indicator. I say this as the in-menu flag gets reset as soon as you go into the game, but this takes quite a while (up to a minute) and the sim is set to a pause state just before the in-menu flag is cleared and then unpaused when the 'READY TO FLY' state is reached. FSUIPC7.exe

Its not possible to do this reliably at the moment unfortunately. We are awaiting SDK updates to do this reliably. Thomas has pointed out that you can determine the menu/in-game status by looking at the Filename events. I'll look into this today and see if I can get offset 0x3365 correctly reflecting this status. You could check the stall warning flag at offset 0x036C.

Yes. Each time you start a lua function, it will be compiled and ran. This its why it is better, for many use-case scenarios, to have a lua pre-compiled and running (from the [Auto] ini section). and then waiting on events to activate.

Its not possible to do this reliably at the moment unfortunately. We are awaiting SDK updates to do this reliably. Not sure about "landing" weight. There is a sim variable for Max Gross Weight if thats what you are looking for, which is in offset 0x1334. I'll look into adding these to the offset area. I'll let you know when done. John

Ok, thanks for the update.

I guess its a false positive. I've just downloaded and tried it and its fine here, so download and try again.

Hi Keith, unfortunately the only event for batteries listed in the SDK/SimConnect is the Toggle Master Battery event. There is also a simvar ELECTRICAL MASTER BATTERY that you can use, via offsets 0x281C and 0x3102, but there are no individual events or variables for battery1 and battery2. That is strange! But I presume this is just a parameter to the toggle event, no? Nothing to do with offsets. Toggle controls are usually just that - a toggle control with no parameters. So does sending this control with no parameters (or a parameter of 0) toggle all batteries, and if you give a parameter (1-4) then it just toggles that battery? You can also give a parameter to the control in the assignments panel to test this. I'll take a look at this in more detail when I get a chance.