John Dowson

Yes. Currently FSUIPC7 has to be connected to MSFS for the virtual button offsets to function correctly. I can look into making such assignments available without an FS connection. I've made a note to look into this at some point in the New Year, but this will be low priority. John

Hi Paul, this is a known issue with the ICAO and Model strings. It has previously been reported in this post: To get around this for the time being, I have added the ICAO designator, manufacturer and model (read directly from the aircraft.cfg file) to the following offsets: icao_type_designator: 0x0618, 16 bytes (including string terminator) icao_manufacturer: 0x09D2, 16 bytes (including string terminator) icao_model: 0x0B26, 32 bytes (including string terminator) However, those offsets won't be populated for all aircraft (see that post for details). At some point I am planning to replace the language specific strings with the strings from the language pac files, but I've no idea when I will get around to this, its pretty low on my list. Cheers, John

@daern Your issue is the same as that posted by @rvroman , and so my comment above also applies. You could also try the attached version, v7.0.3, that I will be releasing shortly. There aren't that many changes, but it has been rebuilt against the latest SDK (0.9.0.0) which was released with 1.12.13.0. John FSUIPC7.exe

@Aircom Yes, I'm afraid your thread was hijacked by a different problem. I'm pretty sure that the new version won't help you. I'm at a loss as to what could cause. So it seems that the COM port driver in windows is failing/crashing. Its hard to see how an MSFS update can affect this, unless its also doing something with the serial ports. Maybe you can check the windows Event viewer, to see if you can see any failures there that could be related. Otherwise, maybe try the Windows SFC (system file checker), and maybe check that your mobo drivers are up to date.

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