John Dowson

Yes, I have heard that both of those Honeycomb devices have buttons outside of the 32 limit and need lua to be used in FSUIPC. I should be getting both the Bravo and the Alpha sometime in January, also updating from the Saitek ones. Btw, are you now using MSFS 1.12.13.0? I've had some reports of FSUIPC7 crashing with this version when using those Honeycomb devices and lua (HidDemo.lua), but am still awaiting details.

Can you tell me what happened? And if FSUIPC7 crashed, can you please check the windows event viewer to see if there is a crash report, and if so post the details. Your log just shows a crash when using the HidDemo.lua. Maybe try without this.

But it is due to the changing joystick numbers that the joyletter facility was added. This then matches the name and GUID to the letter, and so if the joy id changes then the same letter is still in use and so the assignments (to the letter) still work. If its generating a new letter for your device, then its not recognising it either due to a name or GUID change. Maybe you can attach you Joyscan.csv file. I have not used HidVanguard/Guardian, so do not know how it is affecting your devices or registry entries for those devices. BUT, FSUIPC must be able to determine what each individual device is, and this is mainly done from the GUIDs, although the id numbers are also used, especially when not using the Joy Letters. Sorry, I don't understand what you are trying to achieve here. What would a new 'virtual' tab provide over the current button tab? Virtual devices are just devices as far as FSUIPC is concerned, and are handled the same (w.r.t buttons and axes) as any other device. Maybe @Pete Dowson can advise, I'm not sure. I think the best solution really would be for MSFS to fix this issue - is it known and/or have you raised a zendesk report? Also, please be aware that I am now on holiday/winding down (announcement yet to be posted). I will be covering support occasionally over the festive season, mainly for urgent requests. All other support issues will now have to wait until I'm back to full time work around January 11th. John

FSUIPC offsets are general and for all aircraft, except for the specific offset area for PMDG (not available in MSFS/FSUIPC7). So the general documentation is applicable - the FSUIPC7 Offset status.pdf together with the offsetStatus-v0.x.ods spreadsheet. However, I'm not sure what is available using the FBW mod. There has been at least one reported case of an offset not being properly populated when using the FBW mod, but is ok with the included A320Neo. John

You could try the attached version, v7.0.3, which I will release officially later today. This contains a few minor updates, and has been compiled against the new SDK v0.9.0.0 that ws released with 1.12.13.0. However, I'm not sure what the issue is yet, without further information, so not sure it will help. I will be testing this with 1.12.13.0 today. John FSUIPC7.exe

Yes, that's how that control works. But if you have managed to set it up how you want it to function, thats great. And thanks for posting your lua solution. I should be getting a Honeycomb Bravo soon (according to Honeycomb....), so I may use your lua once it arrives. John

I don't understand this. It will only re-assign letters if/when it detects a new device. It looks like different GUIDs are being returned each time you run, and so different letters will be assigned as they are detected as new devices. Changing that parameter means that they are still detected, but letters won't be assigned. This won' help as the numbers (joy ids) being used for each device will also change. I'm not sure why this would occur. Could the device have been 'asleep'? Maybe check the power management (in Windows) for that device/hub, and if using an external hub make sure that it is powered correctly. I don't think this would help, as the initial scan is identical to the scan when opening the axis page. I am also reticent to add hacks to fix issues caused by using other programs, especially if this is a temporary work-around for issues in MSFS. John

So you are using the FSUIPC SDK to send keys? Or are you using the windows SendKey function? I am confused now about your support requests in this topic. Do you require assistance or not? What are you trying to do? Your previous posts were (or seemed) to be about not seeing key presses when MSFS has the focus, and now you are talking about sending key presses. If you require any further support, can you please clarify what you are trying to do and what your issues is. Thanks, John

I think you are referring to the Mouse Macro facility, which was available in previous versions of FSUIPC. This is currently not supported in FSUIPC7 as the MSFS SDK does not yet provide facilities for this. It is generally always better to use controls/events where possible, as such assignments apply to many aircraft. Mouse macros are always aircraft specific. For the Parking Brakes, there is the Parking Brakes control, which acts as a toggle. You can just assign that to a button. If its a sticky button or switch (with different positions indicating on and off), then you can also add an offset condition (on 0x0BC8) to only send the control when required. Generally, you will find that there can be toggle controls (for on/off) or set controls (where you send a parameter to indicate the state to set). Both can be used with offset conditions (if there is an appropriate offset!) to only send the control required to maintain the state of the button with the sim. Please see the Advanced User Guide on offset conditions (P22). John

So is it working now? I'm slightly confused... Have you looked at using the Throttle Reverse Thrust Toggle control? If that is supported in the aircraft you are using, this allows you to use the full range of your throttle axis for reverse thrust when set. John

@Travis1992 Are you also using a PFC driver? Could you post your FSUIPC7.log file please? I'm still downloading 1.12.13.0.

As there is no way to specify which event to cancel, I think it should really continue and cancel all registered events for that function. I'll update this at some point, most probably for the next release (FSUIPC6 & 7 only though). John

There really are no changes between 7.0.1 and 7.0.2 that could cause this. Your log shows simconnect failing, then FSUIPC7 exiting when it detects that MSFS has closed/crashed. I think the issue is almost certainly with MSFS or the SDK, as you say. Are you using any other SimConnect clients (or Track-IR)? It could be a known issue (since FSX) with the number of simconnect client connections being exceeded - you can activate SimConnect logging to determine this, and if this is the issue you could increase the allowed number of clients (or directly do this to see if things improve). However, if this was the issue, I would have expected to see some TransmitClientEvent errors in your log. You should also raise a crash report with Asobo (via zendesk), and include the crash report from the windows event viewer. John

Why did you post the contents of the zip folder you downloaded? Try reading the README.txt (the clue is in the name!), and also please read the Installing and Registering FSUIPC7.pdf also provided.

Please see the README.txt (included in the downloadable zip file - and which you posted for some reason....), check the forums (this has now been reported many times) or try google. If you check any of those, you will find that this is due to your VC++ redistributables that need to be installed, or re-installed.

If a key press works in the sim, AND it is one that is supported via a corresponding key input event string (not all keys are supported), then it should also work via a key press assignment (to a button, for example) in FSUIPC7. However, I cannot advise if using mobiflight for that,

This is very strange then! As I said, try re-installing the client, run P3Dv5 once, then try to install FSUIPC6. If you get the same issue, let me know. John

Ok, then sounds like you need to report to Asobo via zendesk.

Then why was your XBOX 360 controller detected? Note that there are currently issues with the 360 controller and that can't be used/assigned in FSUIPC at the moment, but should be okay using via MSFS assignments. By changing to use a USB2.0 port - you cannot do this via software. I use a surface docking station, and I'm pretty sure that it has both USB2 and USB3 ports. Check the colour - if its blue, its usb3, and if black, usb2. Well, that is pretty weird! Can you attach your FSUIPC7.Joyscan.csv file, if one was generated. Maybe try with the controllers you use connected, and re-upload your FSUIPC7.log, .ini and .joyscan.csv files together and I'll take a look. John

Offset 0x0B49 (AUTOPILOT FLIGHT LEVEL CHANGE) is read-only. There is currently no control (that I am aware of) that you can use to assign this to a button. Due to this, at least for the time being, you can assign a keypress in MSFS to the MSFS control TOGGLE AUTOPILOT FLIGHT LEVEL CHANGE (or, probably better, two assignments to AUTOPILOT FLIGHT LEVEL CHANGE ON/OFF, with an offset condition on 0x0B49) and then assign your buttons or switches to those key presses. For the VNAV, please check previous support requests, as I believe this is working but not sure how or for which aircraft - without checking... John

To receive keyboard input, either FSUIPC7 or MSFS must have the focus. As I have said, please show me your log file when MSFS has the focus, as you have said that the keys aren't being seen for this. The log file you attached shows the keys being seen and the controls being sent (but I have no idea which app had the focus when you did this). Keyboard input will NOT BE SEEN if neither MSFS nor FSUIPC7 has the focus - the input will go to the app with focus, there is no way to receive such input. John

Those keys are recognised. Could you activate logging for Buttons & Keys, press each of those key assignments and then show me your log. This is what I see pressing those keys when MSFS has the focus (with no assignments to them): L: F7 (here I held the key down a bit longer and so a second repeat keypress was detected): Ctl + F: Please attach you full log (not extracts or a continuation) and your FSUIPC7.ini. John

No, What are thes? I can see that there is an MSFS control entitled 'SET ENGINE CRANK MODE and one for 'SET ENGINE NORM MODE'', but these aren't available via SimConnect. I will try adding these at some point to see if this is just missing from the documentation, but I doubt it. In this is the case, then you can assign keys to these controls in MSFS, and then assign buttons/switches in FSUIPC7 to those key assignments. Similarly, there is an MSFS control SET ENGINE IGN/START MODE - is this the control that you are after? Again, seems to be MSFS internal only. John

What keys are you using? When MSFS has the focus, only key input events seen by SimConnect will be recognised. For example, try pressing the standard letter keys - are you saying that FSUIPC7 doesn't see those when MSFS has the focus?

Hi Hermann, I just looked at this in the Cessna Citation and the offsets are populated as expected - this is what I see with the CJ4 when I log those offsets and move my throttle through its full range:: How have you assigned your throttle axis? Maybe you can attach your FSUIPC7.ini and I will take a look. You can also try logging those offsets (as I did, as S16), to see what the values are for you when you move your throttle axis. John Later: Also checked in the 747 with the same results. Are you using any mods? If so, try without.