John Dowson

Have you tried following the steps outlined in the User Guide, under the section 'CALIBRATING MULTIPLE THROTTLE, PROP & MIXTURE AXES TO "LINE UP"'?

It may be worth activating SimConnect logging anyway as this may show some errors when it stops responding. You can also determine the number of SimConnect connections used when this occurs, which would confirm or otherwise if this was the issue. It may be that with P3Dv4 there are less re-connects done by any SimConnect clients. ...and have a Happy Christmas! John

You are probably using the freeware version - do you have a license for FSUIPC4, and if so did you register it during the installation process? If not, or if it was installed for use by another program, then there are only limited user facilities available (mainly logging). Please see the FSUIPC4 user manuals, which should be installed with FSUIPC, or available under the Downloads sub-forum.

Following on from what Pete has said, you do not even specify what product or FS version you are using. Please provide enough information for us to understand and investigate your problem. Before posting again, please read this: Also note that support for our products is now closed for the festive period. I will still be monitoring support and maybe assist for urgent or simple problems, but if you are complaining and providing no supporting evidence you will be ignored. John P.S. And what does your topic title of 'FSUIPC' mean, when posted in the FSUIPC support forum? Please give any new posts an appropriate title.

Thanks for the update. Maybe worth checking the Asobo forums for issues with the latest release before you report - I still haven't had time to do this (or review the documentation updates for the latest release). Regards - and have a healthy and enjoyable festive period, John

@pilotjohn Ok, thanks. Let us know how it goes or if you need any assistance, although support will be occasional for the next 2.5 weeks or so. Regards, and have a Healthy and Happy festive period, John

You need to make at least one assignment to the rotary first. Your video showed device C with buttons 24 & 25 firing, and you have no assignments to those buttons. Try making one assignment in one direction, then look at the ini to find that assignment. Then, as Pete has said, follow the instructions half-way down P23, where 'Joystick 1' would be your Joystick C, B1 would be 24 and B2 is 25 (for the rotary you showed in your video). Otherwise, post your ini again after making an assignment to the rotary, and let us know the device and button number you assigned to. John

Hi Jan, I will look into this but I'm afraid that it will now have to wait until after the christmas holidays. I will get back to you once I have had time to look into this. John

Hi Hermann - Ok, and thanks for reporting back. Regards - and best wishes for a Happy and Healthy Christmas, John

There is a known issue in the SimConnect SDK since FSX that affects P3D (all versions) and also MSFS. It occurs when the number of SimConnect clients is exceeded, and tends to happen after long flights when using several simconnect clients (as they often close the connection and re-connect when the connection stalls). I haven't got time to dig out the references now, but there are various posts in this forum where I have explained the issue, given references and also how to improve (by increasing the max number of allowed SimConnect clients in a SimConnect config file). John

@daern I'm surprised about those events as your log shows FSUIPC7 exiting normally and that it was MSFS that crashed. I guess they are non-fatal errors due to the MSFS error. Your problem is almost certainly due to MSFS and you should raise a zendesk bug report. Btw, can you please ALWAYS attach your full log rather than pasting extracts, as there is further information I need to see, such as devices being used and the build version of FSUIPC (and any dlls) that you are using. @rvroman As you have not attached any relevant information (i.e. your logs) I can't really comment, but if it is similar to your previous log (or that of daern's) then it will also be the same issue. Maybe worth checking the MSFS forums for any similar reports - I haven't had much time to check out any issues with the latest release yet.... John

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