Pete Dowson

FSUIPC 4.851 is now available. I'll look at P3D 1.4 next week. Pete

Thanks. If it contains most of the FS controls they'll all be there. The CONTROLS.DLL table start location doesn't change often in any case. In fact I think it was the same in P3D 1.0 through to 1.3. The WEATHER.DLL will have changed, which explains the wind smoothing problem. The G3D bug they've fixed is probably the one I patched (I did supply them all the gen on that a while ago), so that explains that. Whether the other things work or not depend on other modules. I'm downloading 1.4 now just to install and look at the changes. In order to test it I'll probably have to buy it (thought I don't use it -- my FSX installation is running so well and don't feel any need to move yet. Maybe I will with version 2). John Nicol was supplying 3 month licenses for each version update so I could test. Regards Pete

Sorry, I'm really not able to do that for risk of wrecking existing programs which assume they have to prepend the FS path. It's not necessary to read 3304. You can just check whether the string starts with \\ (for a UNC path) or the second character ':' (for a full local path like C:\ ...). If neither then prepend the FS path. Regards Pete

Can you enble "Extras" logging in FSUIPC, please, then restart P3D 1.4 and show me the log file? Unless they've not changed much several functions in FSUIPC are unlikely to work including the G3D patch, Mouse Macros, wind smoothing, the timer protection for things like E+number, or pushback direction, and maybe even the list of assignable FS controls. All of these depend on the relative location of things in memory and need checking and possibly updating with each update. What changes are there between 1.3 and 1.4? Are they listed on their site? I'll take a look when I get a chance. Regards Pete

If you don't use the optional loader Mouselook works fine for me with the FSUIPC controls "mouselook on" and "mouselook off" programmed to Space bar press, release (no repeats). I'm checking how the loader can mess that up now. Makes no sense to me. [LATER] Yes, I confirm that FSUIPC cannot see the MouseMove and Mouse Button messages when not loaded by SimConnect directly. I don't know why. I eliminated other addons from loading and it is still the same. I even eliminated the time delays (5 secs in the Loader, 3 in FSUIPC) before subclassing the FS window in order to get the messages, yet nothing allows those particular messages through. Very odd. It can see the MouseWheel messages and all the keyboard messages, so it makes no sense to me. I'm looking to see if I can override this, but if I can't I'll just have to publish a warning not to use the optional Loader if you want to use FSUIPC's mouselook facilities. BTW why did you opt to use the Loader? Just to try it, or to overcome some problem? [LATER STILL] No solution so far. I'll publish the warning. Pete

It isn't "ShortAircraftNameOk" which is broken -- tested here and it works fine. What is "broken" is the initial matching of the aircraft name when first loading, and that applies with or without ShortAircraftName. Changing the aircraft later works. I'm fixing the initialisation problem now -- 4.851 later today. P3D 1.4? Is there a version 1.4 now? And FSUIPC runs? It shouldn't! Since John Nicol left P3D no one there contacts me any more and my license for 1.3 has expired. Not sure who the contact is now. Regards Pete

You need to fix the FSX installation, because that error only arises if it is broken. Try reinstalling the FSX updates. Don't forget always to run FSX once between each attempt to update it. Regards Pete

Offset 9400 is not known to me and is not actioned in FSUIPC, so it is probably only processed in the IFLYTOFSUIPC interfacing program. Maybe they can help? Ah! Is that visual basic? I think some versions of Basic will interpret that as hex FFFF9400 (i.e. extend the sign byte.) I think there's a way around that, something like &H9400& But i am not sure. I don't use VB and have no reference books for it. Regards Pete

Doesn't the VRInsight software allow this? I don't know theis VRi unit -- is it the one also known as MCP A? The original MCP-Combi unit and both MCP-A and MCP-B are known to FSUIPC if enabled. But if you want to use the VRInsight software for most things and just re-program some of them it does get a little complicated. Yes if you want both FSUIPC ro see the device and still let the VRi software handle it. Otherwise only one can see it. But have you checked LINDA? I think that handles VRi devices? Regards Pete

Looking at this now, but meanwhile reloading or changing the flight or aircraft after FSX / P3D is ready to fly should fix it. Apologies for the mess -- it arose because of a re-ordering of initialisation events in order to overcome issues with SimConnect trust crashes. Seems I moved something in there I shouldn't have. I'll fix it this weekend. Regards Pete

Looking at all this now, but meanwhile reloading or changing the flight or aircraft after FSX / P3D is ready to fly should fix it. Apologies for the mess -- it arose because of a re-ordering of initialisation events in order to overcome issues with SimConnect trust crashes. Seems I moved something in there I shouldn't have. I'll fix it this weekend. Regards Pete

Looking at all this now, but meanwhile reloading or changing the flight or aircraft after FSX / P3D is ready to fly should fix it. Apologies for the mess -- it arose because of a re-ordering of initialisation events in order to overcome issues with SimConnect trust crashes. Seems I moved something in there I shouldn't have. I'll fix it this weekend. Regards Pete

No need for any of that. If you assign to FSUIPC's reversers they don't engage if the throttle is set to anything higher than 0 (or a value set in a parameter. This section explains it in the Advanced User's guide: Regards Pete

Nothing of mine works on X-Plane. I do not use and cannot support X-Plane. Sorry. Pete

I'm afraid I've no idea how you've programmed this now what it really does, so I cannot help. There's nothing built into FSUIPC to handle TCAS switching with IVAP. In fact FSUIPC knows nothing of IVAP and vice versa, so I cann't imagine how FSUIPC is involved. More information on how you've implemented this? Pete

As well as what Paul says, if you've not purchased FSUIPC you won't have a key in any case. I think you aren't reading the Installation guide supplied in the ZIP because you say "I have to insert the registration key", which is not true. You do NOT have to, as it clearly says! Just press Cancel if you do not wish to register! Pete

FSUIPC does nothing different in pause or slew modes. It merely sends the value to SimConnect. I'm not sure why it is different in different modes, but i think it is the same in FSX. You might try the "Initial Position" method instead -- see offsets 0558 and 055C. You'd need to write that Lat/lon values as well, but you could read those first to get the same values. Pete

This is most definitely a video driver problem as has now been proven by two or three other separate instances. There is a driver version which appears to work. Please check the other thread(s). Pete

PFC serial devices need the PFC or PFCFSX DLL and FSUIPC. There certainly should be no conflict with Linda. Just do your calibration and assignments in the PFC menu. Regards Pete

Instead of using key presses, which translate into FS contorls, why not assign to the controls themselves? That would be much more effiicent and less likely to error. For precise setting as well as using Flaps Inc/Dec, (F7/F6) and Flaps up/Full (F5/F8), consider using Flaps Set with the parameter giving the position (full = 16383, up = 0, seems you found the interim at 9635? Though the control value for that might be 8192 if its notched. I don't really understand why you need to have the Flaps Inc (you call Flaps down) repeating. I assume the 0, 20 and full positions aren't notched (detentes), so the flaps stop anywhere? If so then certainly Flaps Set with 0, 9635(or 8192 maybe) and 16383 would be much easier to do and avoid doing repeats or testing offset 0BE0. This would also solve your annoyance. Pete

If it is a bug is FSX, no, because FSX is no longer being developed. It may get fixed one day in Prepar3D which is derived from FSX and being developed by Lockheed-Martin. But of course it maybe a bug in one or other add-ons, or even a hardware defect such as a patch of bad memory. All we can derive from the symptoms and crash data is that it is due to corruption of some data in memory. That's something wrong on the Network side of that PC. The only time I've ever seen Wideclient crash like that is deep down in the Ethernet/network drivers in Windows. I get it occasionally on one PC only out of 10, and 3 of the others are identical to that one (bought at the same time too!) I suspect a hardware fault because of this and may replace that PC if it gets any worse. Pete

No. Running Lua plug-ins under FSUIPC is one of the bigger registration benefits. Regards Pete

No need to go to all that trouble. If you disbalbe controllers using the checkbox for this in the FSX dialogue, it will be remembered (unless you delete your FSX.CFG file). It is recorded as "Joysticks=0" I think. Pete

No. The patch which FSUIPC4 appies to G3D.DLL only deals with ONE (1) of the many different crashes I've seen attributed to that module. It just happened, luckily, to be the most frequent one, which is how the publicity for it arose. Well, assuming your computer hardware hasn't developed a fault (which is possible -- memory failures give exactly the same sorts of errors), it must be down to something you've changed. An added scenery or aircraft, or maybe flying somewhere you've not visited before? I don't know. I would have thought "G3D" referred to all 3D parts, including buildings, virtual cockpits, aircraft and the like. Maybe it's only scenery though. The one crash FSUIPC prevents is certainly related to scenery. The patch it inserts detects a corruption in some pointers related to scenery. It seems to be worse where the amount of memory FSX is consuming approaches its limit. Even turning down your settings a bit? It's high settings which aggravates these errors I don't know how that could possibly help. Regards Pete

Recent versions of FSUIPC also include a Mouse control library in the Lua plug-in facilities. Yes, the coordinates would change if you are constantly moving the FMC, but the coordinates can at least be given as a proportion of the FS window screen dimensions. I suppose you could program a number of different positions for each action, assuming they don't overlap or encroach on other mousable spots. With the mouse macros you created, did you experiment at all with the additional parameters you can add -- to change the flags for the actual mouse operation which are sent to the PMDG gauge? I'm afraid I cannot experiment for you as I don't have that aircraft. There are notes on this in the documentation. Regards Pete