Pete Dowson

But if they both arrive only the one which is assigned will have any effect. FSUIPC doesn't act on un-assigned button presses (except during assignment). Using Profile-related assignments would be your solution, surely? You are not constantly re-assigning actions are you? Pete

Could you do some elimination on those? Quickest way is to try FSUIPC with none of those then add one at a time, see which one is involved in the crash. So something has changed. No additional add-ons? No updates to add-ons? Ah, that is different. FSUIPC is trapping the error with the offset read/write, so that in itself won't crash FSX -- that's the point of it being trapped in FSUIPC. It may be the other way around: whatever is causing FSX to crash also causes the problem in FSUIPC. So, maybe it isn't being caused by an FSUIPC add-on, but one of the others. So we need to eliminate those too. The CPU upgrade presumably then required a Windows re-installation. And update? Did you re-install FSX afterwards? Seems quite a lot of changes to investigate. I doubt that it is hardware related. It'll be some corrupt software somewhere. Pete

There's no Push-To-Talk facility built into flight sim. There is one added by FSUIPC which should be in the assignment drop down: "PTT on" and "PTT off". These might work with IVAO, but that's another matter. If not you'll need to contact IVAO support to see how to operate their PTT. Pete

As well as John's suggestion, if they are looking distinct, with distinct assignments in FSUIPC, why not use Profiles and only assign to one or the other? Pete

The error appears to be when some add-on application tries to do some offset writing / reading. Can you list the FSUIPC applications you are using, please? Also, try the latest version (4.975a). Please use the <> parentheses (see the editing options bar above the message entry area) to envelope text files like INI and LOG, rather than show them directly in your message -- the spacing makes the INI file quite difficult to read. Or, alternatively, ZIP them and attach them. Pete

So you can do what you want immediately with MSFS? With all jet aircraft and props with reverse? Yes. I use to glue a little piece of card cut into a triangle which overlapped the lever groove a little, to mark the idle position. These days I have separate reverser axes, which can be assigned separately in FSUIPC. I must admit I'd not heard of such a facility in MSFs. Seems oddly unrealistic for something like that to be implemented as standard. However, it appears that others have had this idea before -- see this thread in the User Contributions subforum above. I think you'll not need to spend a long rainy autumn weekend on it after all? Pete

I may be misunderstanding this, but with the throttles so assigned in FSUIPC, if you make sure the "No reverse zone" option is off in the calibration tabs (which i think it is by default), and calibrate a "centre" (idle) zone, the reverse thrust is obtained on the same axes by pulling back beyond the calibrated idle position. That's the normal way of having reverse on the same levers. It gives you whatever range you need to reverse control -- normally you'd calibrate 4/5ths of the movement to forward thrust and just 1/4th to reverse, but you can choose exactly where to place "idle". Pete

Is the only change you made upgrading from FSUIPC5 to FSUIPC6? If you made no other changes, no Windows updates, no P3D4 reinstallation, then all the settings in your FSUIPC5.INI file must still apply after renaming to FSUIPC6.INI if they were left intact. To help we do need to see the FSUIPC6 INI file, so please supply that. The FSUIPC6.LOG file would also help us to see that things are loading okay. Pete

That indicates that they are registered in Windows as digital, not analogue -- i.e. on or off only. The only way I know of fixing that, without editing the registry, is to uninstall the device and any drivers, via the Windows Device Manager, then re-booting and reconnect the device so that its proper details are recorded. If you want a more definite way, or if re-installing it as above doesn't work, then check this for registry editing: I know it refers specifically to Saitek, but the principle is the same for all joystick devices. Pete

As well as what Thomas said, if you start a continuously-running Lua plug-in (i.e. one using events) in ipcReady, or via an [Auto] section (or by assignment), then the event.sim function can be used to detect and act upon the closing of the simulator. I'm not sure how well this currently works with MSFS, mind. Pete

The "AP HEADING HOLD" control is a toggle, so that should do it. You can have multiple assignments to the same button. To do this you would need to edit the assignments in the INI file -- details are provided in the FSUIPC Advanced User guide. Alternatively, ifi t's a push button you are using, then you can assign one action to the press and the other to the release. Pete

FSUIPC6 is for Prepar3D v4 and v5 only, not X-Plane. There is a subset implemented by another parties for X-Plane, called XPUIPC. I would guess they've done their best to implement some compatibility, but i really couldn't comment on how much as i've never used it. With FSUIPC, developed since FS98 and over the years covering all the versions of FSX and P3D, we have always striven to maintain compatibility with previous versions as far as possible. So there's a good level of compatibility between FSUIPC6 on P3D and FSUIPC7 on MSFS. After all, MSFS is in many ways just continuing the line (actually from FSX rather that from P3D, so a different branch of the family. But again I cannot say whether this applies to X-Plane with XPUIPC. Pete

Offsets contain values and states, not commands. 07C8 is just a flag indicating whether A/P heading hold is engaged. The value of the A/P heading is in 07CC. The control (key event) AP PANEL HEADING HOLD sets the AP to hold when the heading reaches the value set on the AP (that provided by offset 07CC), whilst AP HEADING HOLD says to hold at the current heading. I think the latter is more usual in light aircraft rather than airliners. But whether the AP is to holk heading or not should be indicated by the flag at 07C8. Note that the panel heading (the one in 07CC) can sometimes be indicated just by a bug on the compass rather than a value on an MCP. I don't quite understand what you mean by this. Why is a number is appearing on the console? are you saying that in your implementation seting the AP heading hold also changes that heading? The controls involved in adjusting headings for the AP are: Heading bug inc Heading bug dec Heading bug set (heading for parameter) AP panel heading set (ditto) I don't know whether these are all operational in MSFS yet, I think the INC / DEC ones are. Pete

Well, as already stated, the "on ground flag" appears not to be provided at present. However, TCAS only normally shows traffic in potential conflict with out own aircraft, or possibly in danger of becoming so. Are you quite near the ground when you see this, or do you have the vertical range set rather high? Maybe, as a work-around we can 'invent' the on ground indicator by checking the AGL value, if that's provided, but otherwise it would need some determination of ground elevation where the traffic is, which might be quite difficult. I feel that there will be so many "workarounds" to deal with omissions in the MSFS SimConnect provisions that it will be more effective to apply more pressure on MS/Asobo to get it right instead. Pete

Are you using the real-world traffic option, or the AI traffic? Try the latter with 100% on the sliders. You get a lot initially on the ground at airports, but i guess it takes a little while for the airborne stuff to make itself known. Pete

Does seem to be a bug, so it should be reported. Is the value reporting correctly for aircraft with retractable gears? Pete

Your "new" installation of FSX is, in fact, the original very buggy release. You need to apply the free updates SP1 and SP2: SP1: https://library.avsim.net/download.php?DLID=170823 SP2: https://library.avsim.net/download.php?DLID=170824 Pete

Right. I ran FSUIPC7 plus Prosim V3.00B38. On another PC I ran ProSimDisplay with the Pilot PFD/ND and EICAS panels showing, and ProSimCDU. I enabled IPCread and IPCwrite logging in FSUIPC7 -- but not for very long.. after a few seconds there were over a million lines of logging with a file grown to 124 Mb and growing fast. Looking at sections of the log I see that Prosim is reading lots of offsets at a rate of several 10's of thousands per second, repeating of course. It is also writing a set of 4 different offsets (310A, 341A, 0892, 092A) repeatedly with the same values, at a rate of several thousands per second. It looks like it would simply not really allow enough time for much else to happen. Its own displays are okay -- the response to entries on the CDU was immediate. (Without MSFS running nothing was going on on the PFD/ND of course). My PC is very fast and there are lots of threads which can be used, so the impact on FSUIPC's other jobs is probably not high enough to really have an adverse effect, but I can't tell here. However, it is a little worrying that the ProSim software would do this. There's no reason to repeat requests at such a rate. I'll mention it on the ProSim forum. Pete

Ah. Bang goes another theory! 😞 Pete

I think that sort of problem used to be adjustable with a few Aircraft.CFG parameters in FSX. It may be worth looking at the MSFS CFG files? Pete

Blimey! That is rather out of date! Oh, I see. Well I'll try Version 3 this morning, but only with FSUIPC7, no MSFS. Pete

Hmmm. That's a possibility. That may change it from using a "pipe" to using TCP/IP, which, though less efficient, might not block up as easily. Only a guess, mind. Pete

There's no straightforward way that I've found, but I think you might be able to "bulk clear' assignments to each controller in turn -- or possibly only by group, not sure. i'd need to double-check that, though. Save them with Profile names indicating "cleared" so you know. Pete

If you mean the 0 or 1 for the SET controls, they are parameters. Look at the assignments tab -- there's a parameter entry field where you can put values. Axis controls take numbers there ranging from -16384 to 16363. Many controls have parameters defining the value to be used. Pete

I think he mentioned version 2. Version 1 is pretty old. I'll be checking with version 3 tomorrow (but without MSFS). Anyway, your tests do indicate that whatever the problem is, it needs looking at in ProSim rather than FSUIPC. Pete