John Dowson

I'm not sure it is. What are you using to set the position? There is an indexed simvar GEAR STEER ANGLE that I could add, with indices for centre, left, right and aux (and also individual variables for each), but I'm not sure if this is what you are after or if this would be populated when using ProSim. Do you want me to add these to see if they can be of use? John

Hi Al, No, the ipc.ask() lua function isn't currently working due to problems with the SimConnect_Text function. Unfortunately I don't think there is an alternative to this at the moment, sorry. Thanks - and a very Happy festive period for you as well! John

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