John Dowson

Ah, ok. Then the additional offset won't help. However, sending the controls (with parameters as previously mentioned) works for me, as do the inc/dec controls (and the MSFS only hi/med/lo ones). I'm not sure why you can't send to the sim, but presume this must be related to your mobiflight configuration which I can't really help with I'm afraid. You could try logging events (as well as buttons and switches maybe) to see what is being sent.

@asessa Would you like me to add that additional read-only offset to reflect the true autobrake setting? Alternatively, I could add a new ini parameter (allowed in both the the [General] and also the [Profile.xxx] sections) that when set would ignore the simvar update to 0 received after a non-zero value was set, so the current offset should hold the correct value. But, both changes would come with a warning as the value may not always reflect the correct setting in all situations (e.g. if you start FSUIPC7 the initial setting will be unknown), but should correct itself one a Set Autobrake Control was sent. Let me know.

Ok, thanks Thomas. I'll increase the value of the allowed parameter for the write to that offset to 6. @asessa If you (or anybody else) would like the the additional offset to show the current autobrake setting for the A320Neo then let me know, although thus wouldn't be able to show the correct value in all situations. I'll also raise a zendesk ticket to see if anything can be added to reflect the current autobrake setting.

Hi Thomas, So 6 is now the max value? For offset 0x2f80, FSUIPC currently only allows for a max value of 5. Can you confirm this and I will update to 6 (although this offset is currently disabled for writing, its activated in v7.0.3c posted above). Ok, yes - they need a simvar to hold the actual state if the current one cannot be used. Do you think it worth adding another read-only offset to show the actual autobrake state (derived from0x2F80 but ignoring the second reset to zero) to handle this for the A320?

It seems that when you try to change the value to anything other than 0 or 1, it automatically changes back to 0 afterwards. I will raise this with Asobo. I guess I could ignore this second update (back to 0), but that would mean that FSUIPC7 is not displaying the value that the sim variable holds, so I'm not sure this is a good idea. I could add another offset, which would display the autobrake setting as determined by fsuipc (i.e. updated as offset 0x2F80 but ignoring any second control setting this parameter to 0). For the time being, I'll post about this on the asobo forums and maybe raise a zendesk ticket, depending upon the response. John

Ok, took another look when in the air (and the buttons active). It seems that the control/offset is working, but with some peculiarities. Sending the Set Autobrake control with the following parameters results in the following actions: param 1 - autobrake off, offset holds 1 param 0 - autobrake low, offset holds 0 param 2 - autobrake low, offset changes to 2 then back to 0 param 3 - autobrake medium, offset changes to 3 then back to 0 param 4 - autobrake high, offset changes to 4 then back to 0 When a param of 2,3 or 4 is sent, I can also see a second Set Autobrake Control being sent with a parameter of 0. Not sure where this is coming from at the moment, I will investigate but this is probably the cause of the offset not holding the correct value, even though the control has actually changed the autobrake setting. The incr/decr controls also work, as do the MSFS set hi/low/med controls. So thats the same as what I have found, This I don't understand. All work ok in FSUIPC, except for the offset status not reflecting the correct state, which seems to be due to the additional control being sent. I don't think FSUIPC is sending this, but I'll check.

Just took a look at the Neo and it looks like the autobrake control is not currently working, or at least its not updating the AUTO BRAKE SWIOTCH CB variable. I'm not familiar with the A320 so I can't tell what the current autobrake setting is, even after clicking on the Auto Brk Lo/Med/Max switches, Updating the offset will send the control (although I don't know if this has any effect), but sending the control won't be reflected in the offset being updated (as the sim var is not updated). I will raise a zendesk ticket for this. There are also a few other controls available that I have also tried which have the same effect: Decrease Autobrake Control Increase Autobrake Control There are also the following additional controls available only in MSFS: Set Autobrake Hi Set Autobrake Med Set Autobrake Lo You can try these (in MSFS) to see if they work for the A320Neo. If so, you can assign a keypress to them (in MSFS), and then assign your buttons/switches to those keypresses in FSUIPC/mobiflight. Where can I see what the current autobrake setting is in the A320Neo - should the lights on the switches turn on?

Did you try running FSUIPC7 after doing this? It shouldn't uninstall earlier versions.... It shouldn't make a difference installing individually oir installing the combo pack (if installing the correct versions). If its still not working, uninstall 2015, 2017 and 2019 and try again with the combo pack.

You go into the windows settings, select Apps, and uninstall from there.:

WideFS is a separate product - you do not get a key for WideFS7 when purchasing FSUIPC7. Yes, its a different product. If you previously purchased WideFS7, your key is still valid. You can retrieve it from your SimMarket account. It has never been 'included' with FSUIPC, although I think that there may have been a bundle offer where you could purchase FSUIPC + WideFS together for a discount on the total individual price. John

As before, check the SDK. There are no key input events for those keys. The > is mapped, but to 0x6E (with a shift), so I could add a similar hack to get this key working. The < results in no events, so I can't do anything with that. But I really don't want to start hacking for individual keys. You should restrict your assignments to those keys available. John

Yes - FSUIPC recognises the modifier keys directly from the windows API and doesn't use SimConnect key input events for these. John

Its from mobiflight. FSUIPC nly has one offset for each gear wheel which gives the deflection as a percentage. Presumably its just the gear left/center/right position offsets that you have already mentioned. Try monitoring them to see how they change when you retract or extract the landing gear. I would have thought that a value of 0/100 would be retracted/fully extracted (or vice versa) and a value in between would be when it is extracting or retracting. Ok, good. A full list of events is generated by FSUIPC7 and placed in your Documents/FSUIPC7 folder when you run FSUIPC7, called Controls List for MSFS Build 999.txt (999 is the current minor build number). The MSFS documentation is in the SDK - you need to download and install the SDK to access the documentation. If you want to do this, see https://forums.flightsimulator.com/t/how-to-getting-started-with-the-sdk-dev-mode/123241 John P.S. The offsetStatus spreadsheet also lists the simulator variables used for each offset (in column G), where appropriate, and at the end also contains a list of other available simulator variables currently not requested.

Do not delete, but uninstall. Yes, but uninstall 2017 not delete. When you uninstall or install, it applies to both versions. You probably also need the 2019 versions, which should be installed after the 2017. Its not that difficult - they just need to be installed in the correct order. As you have the 2017 installed and not the 2015, you have to uninstall the 2017 before installing the 2015, and then re-install the 2017 after you have installed the 2015. No - why would you want to do this?

Sorry, of course you are using FSUIPC6 and not FSUIPC7.

I can find nothing in the SDK (in events or simulator variables) that relate to the HotBrake or TerrON, and also nothing related to these in the MSFS assignments. Therefore its not currently possible to control these. John

Sorry, I don't understand what you are saying or trying to do here. The offsets you mention hold the gear left/centre/right position. What do you mean by 'extracted' and 'moving'? What are you actually trying to achieve? If the autobrake offset you are using is 0x2F80, this is documented as 'No longer writeable' (in the offset status spreadsheet) I've checked the code and it seems that this was disabled as the Set Autobrake Control was not present in earlier versions of the SDK. As its now available, I will re-activate that offset for writing. What are those? Is there anything in MSFS that you can use to control these? Please try the attached version c7.0.3c where I have re-enabled offset 0x2F80 for writing. John FSUIPC7.exe

@zorzini I am wondering whether this could be the same MSFS bug explained here: https://forums.flightsimulator.com/t/heading-increment-bug-10-degree-instead-of-1-explained/290173 John

Did you get this working? It does seem top be an MSFS bug - see https://forums.flightsimulator.com/t/heading-increment-bug-10-degree-instead-of-1-explained/290173 John

@ark1320 Thomas has pointed out we are actually receiving the arrow key key presses via SimConnect, but we are receiving these as numpad key events. As they are being received, I can check the state of the arrow keys when the notification is received and re-map to the correct VK code. I've done this in the attached version if you would like to try: FSUIPC7.exe John

But remember, the SimConnect API dates back many years, and maybe these keys were not common then. Or maybe they are covered by some of the other VK codes (but I would expect VK_LEFT, etc, or VK_0x25, etc which don't seem to exist). But really, you need to address such questions to Asobo. Well, if they are not assignable I'd rather remove them completely. Or is it worth keeping such key assignments as they do have an effect when FSUIPC7 has the focus? I think the former. But, as the SDK is still under development, for the time being I think its better to accept all and provide a reference to what actually works in SimConnect in the manuals. Once we get to SDK 1.0, I can consider updating the manuals (and maybe the code) to then reflect what is actually assignable. John

Hi Alain, what have you tried? What is the problem? Which VRI insight device overhead? Have you read Appendix 3 in the Advanced user manual (Handling VRInsight serial devices in FSUIPC)? Or is your device recognised as a standard windows hid joystick device? I'm sorry, but your question is so general its hard to answer. Please read the documentation, especially that annex in the Advanced User guide, and the separate document on VRInsight devices (Lua Plugins for VRInsight Devices.pdf). If you still have issues, then please post again (please check for previous posts first) and provide more details on what your actual problem is. John

You logs don't show anything and are huge. Please de-activate most of the logging options when you supply a log, and only activate those relevant to your issue (or what we advise) - which in this case would be axis logging. However, looking at you ini, you have your aileron and elevator assigned to direct to FSUIPC calibration, but your calibration looks very strange: For your elevator, your null zone is bigger than your axis range! For comparison, this is what mine looks like: I suggest that you try to re-calibrate your axes. Please se the provided documentation on how to do this. You may also want to go into the windows joystick calibration page, and make sure they are calibrated in windows correctly first. John

Just looked at this in the A320Neo (but without the FBW mod). In the default A320, both of the seatbelt and smoking switches are inoperative. You can send the relevant controls (Cabin No Smoking / Seatbelt Alert Switch Toggle) and the offset (and associated simvar) gets updated, but has no effect on the aircraft. It therefore seems that this is not connected yet. I'm not sure if the FBW mod is supposed to correct this as I haven't used this (yet!). John

But, as I said, it isn't a bug so no fix is required. Its a new feature request that is needed, as the arrow key input has never been available via Simconnect. Previous versions of FSUIPC were an embedded dll and so could receive all keystrokes natively (i.e. using the windows API) and did not rely on SimConnect for this. Now FSUIPC7 is an executable, it can only get the keyboard events (when MSFS has the focus) via SimConnect. Again, check the SDK documentation to see what keys are available. Well, its the same effect/result, but the issue is different. The issue with the numpad keys was due to a defective SDK (and documentation) and a hacked implementation in FSUIPC7 due to this. This was rectified in the 0.8.0.0 SDK release and the v7.0.2 release of FSUIPC7. The issue with the arrow keys is that they have never (and most likely won't) been made available via SimConnect. I will update the documentation to make this clear, and think about removing these other keys from FSUIPC7 as there is really no point assigning to such keys. John