Pete Dowson

The electric switches probably simply operate an interlock. I'm not sure whether you are talking about thrust levers/throttles or propeller pitch reversal, which I thought was the normal way to engage reverse on such aircraft. assuming you mean prop pitch not throttle then: A reverse propeller pitch can be achieved on suitably equipped FS models by calibrating, in FSUIPC, on the 4 Propeller Pich page. This offers a central "feathered" or "idle" zone, which should be calibrated to coincide with some sort of lock or detente on your levers. The region below (nearer to you) would be the revere pitch range. I'm assuming you have two or more prop pitch levers, either one for each engine, or at least one for engines 1 and 2 and another for engines 3 and 4. For two levers you'd assign one in FS to engine 1 and the other to engine 2 then select the map 12->34 option in FSUIPC. For 4 levers you simply assign them individually, no problem. If you only have one lever you'd need to select "map to 4" option on the first or second calibration page in FSUIPC, then move to the 4 prop page. If you do really mean thrust reversers, on the throttle levers, then the process is similar but obviously performed then on the throttle assignments and FSUIPC's 4 throttle calibration page. Regards Pete

Good. You are using the latest, 4.92, I hope? ;-) Regards Pete

Yes, I hope I will be able to sort it out too. As I said, it is high on my list. In the end, if I can't get anywhere through SimConnect I may need to seriously look at hacking into the WEATHER.DLL, but that is a last resort as it takes a lot of time and effort and patience as many dead ends are followed -- and only lasts till the next revision. I am getting too old for that sort of thing really. Gone are the days where I was happy working all night buried in machine code traces! Regards Pete

Yes, of course. Nothing will have changed in this regard until Microsoft overcome what they perceive as the more important issues -- according to feedback they get. Erhow many upgrades giving FSX progress have you seen so far? There's only been SP1, which was primarily a performance and major bug fix update. SP2, the only other one expected this year, will be about DX10, and performance again. Until folks are happy that they can get the frame rates they expect with the graphics they have been shown I can't see "lesser" matters like this getting much attention. Those who are experiencing the problem (and it doesn't appear to be universal) need to be more vociferous. The facilities I need to control such things are at the top of my requests already made known to the team, but they will be perceived as "extra facilities", not fixes. Regards Pete

I've had a good study of the Log you sent, and here's the main problem -- FSX is not actually doing what it is told, still, for some timeeven with SP1 applied: 187656 Weather Received (type 5 request, Nearest): "LIMU&A220 081422Z 00000KT&D0NG 100KM&B-1720&D6072 CLR 15/05 Q1013 " 187656 Setting Weather: "LIMU 081424Z 00000KT&D0000NG 16KM&B-1720&D6072 CLR 15/05&A0 Q1013 " ... 192609 Weather Received (type 5 request, Nearest): "LIMU&A220 081424Z 00000KT&D0NG 100KM&B-1720&D6072 CLR 15/05 Q1013 " ... 209640 Weather Received (type 5 request, Nearest): "LIMU&A220 081424Z 00000KT&D0NG 16KM&B-1720&D6072 CLR 15/05 Q1013 " Now FSUIPC is reading weather for up to 9 stations near and around the aircraft. It is then immediately modifying this according to your settings and sending it back. Above is just one example, for LIMU. You can see that even after 5 seconds the 100KM visibility wasn't reduced to 16KM (10miles). However, it did get set correctly within a further 17 seconds. I think this is the "phase in" time I mentioned -- though instead of phasing in gently it seems to simply delay then apply. Checking my code I was setting a delay of about 5 seconds for "phasing in" -- I'll try setting 0 and see if it helps at all. I noticed also that FSUIPC is omitting to do this operation with the GLOB ("global") weather, which is what gets set initially (before it localises) if you set "user defined" weather. So, I've made changes so that it filters the GLOB weather too. Even then I don't think it'll work correctly yet, but it might be betterit seems a little better here. Really I don't think this sort of problem is going to be fully solvable until Microsoft sort these weather setting facilities out. However, I'll send you a revised version to try later today. Let me know. Regards Pete

Only by reading the file(s) themselves. If this is for the PM CDU only, then maybe that's possible via either PM's offsets or some other way in PM. Obviously the PM CDU is communicating the plan details to the ND, which is often on a separate PC. Perhaps you need to ask PM support about that? Just checking my WideClient code (where I send the CDU-loaded flight plan name to Radar Contact so it can load the same plan), I get the CDU's "NetDir" as a string from offset 5B00, and load from that path a file called "ROUTE.BIN". The flight plan name is in the parameter "coroute=" in that file. There's probably other useful stuff there -- it will be what the ND uses. The stuff from the GPS data in FSUIPC's other offsets is only for plans loaded into FS, and I don't think it is that reliable in any case. It certainly has nothing to do with the PM CDU plan. Regards Pete

No. The name and email address (or street address for snailmail applicants) are tied to your Keys irrevocably. They are only used to uniquely identify you, they are not used for email or other purposes. Regards Pete

You might want to ask this on the cockpit builder's Forum. viewforum.php?f=106 FSUIPC doesn't itself drive any display hardware, but any ready-made system will come with configurable driver software which may or may not use FSUIPC to get its information. Regards Pete

Cut and paste the complete sections across. All of the INI stuff outside the [General] parameters (and of course the new sections for [WideServer], [AutoSave] and [GPSout]) are 100% compatible. Regards Pete

Huh? It should look like this. See the "Rev" check box? Maybe you are not calibrating in FSUIPC? If the top left button reads "Set" instead of "Reset" you've not calibrated it yet. Press that button. Please see the documentation. Regards Pete

As it says, the version of SimConnect needed to load FSUIPC4, which should have been installed from the original FSX DVDs, is either not there at all or not installed correctly. Please see the FSX Help announcement at the top of this Forum for instructions on repairing it. Regards Pete

Ooops! Sorry. I did my usual trick and replied to your last message using the "Edit" button instead of the "Quote" button. Hence your message got squished. Sorry. Well, I also find a lot of the stuff rather, er, arcane, to say the least. It isn't intuitive at all. Trial and error, with a capital ERROR, is the usual path taken. I think most of your compile errors will be down to a missing header (probably windows.h as I said) defining some of the types. A lot of the others will be "deprecated" library functions, like sprintf, strcpy, etc, and stronger typecasting in the more recent Microsoft development packages. Regards Pete

No, because these are implemented within an add-on, not in FS. I really cannot hack into add-ons to find out how to drive them. I don't even know how it works. That said, you can certainly program controls to operate in specific parts (i.e. notches) of an axis by assigning it through FSUIPC's axis assignment tab, and defining the axis ranges and actions to be taken on the right-hand side. I'm not sure what else you could possibly need. Regards Pete

Different versions of Microsoft C/C++ perform different checks. The "sprintf" problem, for instance, is that it is "deprecated" and they advice you to use "sprintf_s" instead. This is to do with security, as the result of a sprintf can overrun the destimnation buffer. The "_s" variants of many of the string operations are designed to stop this. Same with a lot of the typing. If you've not yet found any need to use casts when using Microsoft C to write Windows programs you've lived a very sheltered life! I'm afraid there's a lot needed. The example code in the SDK is intended to be READABLE. It doesn't have all those new complications. However, f you are a C programmer, you will understand them, and therefore will be able to edit your own code to siut your own compiler, whether it be Microsoft or whatever. The examples aren't meant to be YOUR projects, just show you what is involved. You need to know how to use YOUR development system. I think you are not understanding the evolution of C in the hands of Microsoft. Just learn the rules for your specific version and you'll be able to eliminate the warnings and errors. We've all had to do it. Oh, one other thing. The C examples in the SDK are C, not C++, though the Header does have a "C" declaration so it can be used in C++. The errors you list in FSUIPC_User.h appear to be due to the omission of the BOOL typedef. Did you forget to include the Windows.h before including the FSUIPC header? I can only post the same there. Regards Pete

In my experience ALL uses of credit cards need the name actually on the credit card. I don't know where you've shopped before that don't care about the name! :shock: They also want the address of the person, as known to the card issuers. Without some sort of ID security how could we trust the use of cards at all? We'd all be in a mess, reverting to hard currency again. ;-) Only one in Japanese, Intercraft. Check the payment options. There's many ways SimMarket can take your money. ;-) Pete

Actually, it was up there within about 30 minutes of my post, about three hours before your reply! ;-) Regards Pete

Okay, new video card in and working. I also took the opportunity to double my main memory to 2Gb whilst I had the box open -- makes debugging a lot smoother! ;-) I found the problem with the mapping to Throttle3 (and Prop and mixture). It was to do with the interception changes I made in 4.16. I didn't notice it because I tend to use Direct Axis assignments in FSUIPC, not assignments in FS or to FS controls in FSUIPC4. It worked okay then because the direct assignment doesn't need any interception from SimConnect in the first place. Anyway, it was easy to fix, so I've done so and I will be uploading an interim version, 4.162, to the "FSX Downloads" Announcement above as soon as I've compiled and verified the Release build. Thanks for reporting this. Oh, Thomas, if you are still following this thread. I tested the Direct assignment for SteeringTiller, and I can't make it fail. Are you by any chance using the undocumented INI assignment of a different axis? Or have you tried using the built-in nose wheel steering axis new to FSX (which I don't actually support in FSUIPC4 in any case)? Regards Pete

But isn't it a matter of right-clicking on them, selecting Properties, and unchecking the read-only status? Regards, Pete

Check the "Rev" option in the Calibration section. Pete

That's weird. Stuff like that used to happen sometimes with Win95 if you copied stuff directly from a read-only medium (like a CDRom), but I've never heard of it happening spuriously since. It sounds like a bit of directory file corruption on disk. Also, in any case, if there was no "FSUIPC.DLL" already in the Modules folder, marked read-only, you should have been able to place your new copy there without a problem. It sounded more like the folder itself being so marked. Okay. Good. Well done. Regards Pete

No, the tiller axis should be fine -- you'll need to give me more details. It is nothing to do with any mapping, which apears to be the problem reported in this thread. Regards Pete

Only offsets with multiple values in separate bits should be operated by "Setbits" and "Clrbits". For all the others you should use "Offset XXXX Set", where XXX is Byte, Word or Dword, depending on the size (1, 2, or 4 bytes). In the case of Gear you'd need "Offset Dword Set" with a parameter 0 for Up and 16383 for down. But in many cases, such as Gear, you are making it more complicated than it need be. Only resort to driving the offsets when there's no suitable FS control. Really the offsets are for application program use. Regards Pete

There's never been any "search" button for throttle or any other detection. The joystick options in FSUIPC4 are identical to those in FSUIPC3, as is the interface offered to programs like Elite's driver. Please clarify what it is you think you cannot find. If you refer to and compare user guides for FSUIPC3 and 4 you will see that all the areas to do with buttons, axes, switches and keys are identical. I took a lot of care to be sure, so much so that you can transfer your FSUIPC3 settings form the INI file to your FSUIPC4.INI file. No, it isn't now -- they came good and paid a licensing fee. As far as FSUIPC4 and FSX are concerned, there's no difference whatsoever for the Elite driver. The only possibility I can think of is that they do some sort of Version check (either on FSUIPC version, or FS version) and fail when it doesn't match. If this is the case you probably need an update from Elite. Regards Pete

Agreed, looks okay. Maybe I've broken something. Unfortunately the video card is found to swap for the one which failed doesn't support FSX. I'm popping out first thing Monday morning to get a replacement card which will support FSX, and I'll test this then. Sorry for the delay. Regards Pete

Yes, the FSX version of FSUIPC (FSUIPC4) is a new product and needs a new key to unlock all the facilities. Regards Pete