Pete Dowson

Why several attempts? How did the earlier ones fail? These is very little difference in the SimConnect initialisation in FSUIPC between 4.12 and 4.20. There are lots of other updates and fixes, but they are all only applicable when it is running. Your installer log shows things are okay. I assume the date on that Log file shows it was created before you installed 4.20? If FSUIPC4 isn't getting loaded, then it is irrelevant which version it is -- it has to get loaded before any difference would be manifested. You could prove yourself if you still had 4.12's "FSUIPC4.DLL", by simply copying it into the FSX Modules folder. So, it seems likely something else has changed, or maybe some other add-on has been installed which has disturbed SimConnect in some way. Since FSUIPC4 is not even getting loaded, the first step is to get a SimConnect Log -- the FSX Help Announcement above tells you how to do that. Let me see the reslut. It may also help to show me the DLL.XML file, which you will find in the same folder as the FSX.CFG file (C:\Users\David\AppData\Roaming\Microsoft\FSX). Er, no, not FS9. There was no SimConnect in FS9 to get a log from! As the instructions say, the SimConnect.INI file does not go into the FSX.CFG folder, but into your documents "Flight Simulator X Files" folder, the same place that plans and flights are saved. Regards Pete

Assuming it is COM17 and the speed of 9600 is correct and it uses Aviation 400 format input, then, yes, those parameters are correct, as you can see for yourself. The others have little bearing on it in any case. I'm pretty sure at least one of those models has cropped up in success stories here in this Forum before. Try doing a search on "Garmin" or the numbers. There's a huge collection of stories in this forum (over 100 pages it says here) so browsing manually isn't feasible, but the Search works pretty well. Don't forget to select the Forum correctly or it'll be too wide. Regards Pete

I don't know them well really, but I think Saitek's build quality, the feel of the things, is generally a bit classier than CH. But there have been some initial problems in the firmware/driver implementation which have been reported here (do a search on "Saitek") and elesewhere. They have said they are fixing these so the ones being sold now may be fine. Regards Pete

Hats first: the right hat is operating as a true "POV", with only 4 not 8 positions. That's quite common. Obviously the other hat isn't a POV at all. The other buttons are doing the traditional CH-style encoding, programming up to 14 buttons by using assorted combinations of the 4 buttons lines which were available on an old style Game Port. So, it this a true USB device or a converted Game Port device? Does it have a Game Port connector on it? It sounds like a pretty old game port device to me. Your findings with the Games Controller applet in Windows also seem to confirm that the device is indeed an old-style CH game port one. You need a standard CH driver installed for it which will decode the assorted button number combinations and give you 6 separate buttons number for the buttons and 4 more for the left hand hat. Those 10 plus the 4 for the POV gives 14, the maximum for this style of encoding. I think you mean Game Port, not Serial? A serial port plug has 9 or 25 pins. Look at the adapter connection. I'm pretty sure it will have 15 pins. Note that I am not at all sure that even if you find the correct (antique by now) CH driver it will be able to handle the USB connection -- I think Game Port drivers only dealt directly with the fixed motherboard Game Ports. But it may be worth a try. Otherwise it may be time to ditch the thing and treat yourself to a new one. Regards Pete

Only for a genuine USB device. When using a USB serial port adapter the driver supplied for that emulates a COM port exactly. COM17 should be fine, though that does seem rather a high number. I would expect something more like COM6, 7 or 8. The problem is more likely to be the settings in the device which need sorting out. Unfortunately I can't help there as I have no GPS which accepts positional input (despite having three Garmin GPSs!). Regards Pete

Sorry, I really have no idea. When you say there are buttons sharing numbers, do you mean on separate joysticks, or duplicates on the one? Hats are only nmumbered in FSUIPC -- 32 to 39, abiding by old (FS98 & FS2000) FS conventions. I can't imagine any of those coinciding with any of the ordinary buttons which must be 0-31 (FSUIPC) or 1-32 (Windows Game Controllers) -- excepting of course that DirectInput does allow up to 64 buttons [FSUIPC doesn't use DirectInput for buttons, so won't see 32-63]. Pete

Sounds like a video driver problem. there are lots of niggles with Vista. I hate it. Try running FS in Windowed mode (ALT + ENTER to swap between each mode). Then look for better drivers. Regards Pete

As it is a demonstration of features provided by FSUIPC for all versions of FS, the one and only version provided previously is, of course, okay for FSX too. If it were not so FSUIPC4 would have failed in one of its main purposes! Regards Pete

There is no such message in FSUIPC. That is produced by a program which is trying to use FSUIPC. Yes. Either the system date of your PC is earlier than the date of your Key purchase, or the Key is in fact invalid. I've just checked the latter and it certainly appears to be okay, so could you please check the date on your PC? It needs to be 12 December 2007 or later. Regards Pete

I've sent you a special logging version of FSUIPC by email. Regards Pete

Please turn off your keyboard's "Caps Lock". Don't use my GPSout module with FSX. Delete that DLL from the FSX Modules folder. For FSX the GPSout functions are included in FSUIPC4. Okayso you did discover GPSout in the FSUIPC4 options. You have the COM port set to the default, COM1. It is very unlikely (impossible, I would say) that your USB to Serial adapter is set to use COM1 -- both COM1 and COM2 are normally fxed for motherboard ports. You need to find out what COM port the device is emulating. Look in the Windows device manager -- Control Panel -System-Device Manager. Or try each listed COM port in turn. And check that the speed (9600) is correct for your device. Regards Pete

Ah. It was you! The log is okay, everything is good. It won't contain anything about message interception -- I've not added any diagnostics for you yet. ;-) Pete

If the options are accessible, as they must be for you to set the single line suppression option, then it is most certainly "running". It runs as part of FS. It does create a few minor threads, but otherwise resides entirely within the normal cycle of FS event and message processing, and shares the same Windows Message queue. I will look to see what diagnostics I can add to delve further into the matter. This week, if not tomorrow. Regards Pete

Okay. Both of these are now available in the Download announcements above. Regards Pete

Not only FSUIPC. If you move devices around their ID changes in Windows. The only way anything can keep track is for you to keep each control in its respective USB port, or at least plug them back into the same ones if you do happen to remove them. Well, not really. The parameters will still be there in the FSUIPC INI file. If you have to move your devices around then you either need to change the Joystick Number (a value from 0 to 15) in each of the parameter lines, or reproduce the entire set 16 times each with a different joystick number so that there are parameters for whatever USB port you happen to use (FSUIPC cannot cope with the 17th device or beyond). Alternatively just remember which port you used and plug it back in there -- the parameters will then be active as originally. You've not lost anything. No. The only unique identity for any USB device is the port it is plugged into. Even if I detected the device's name, that is rarely unique. There are many folks with multiple identical USB devices each of which need to retain their specific assignments and so on. Regards Pete

After getting more deeply into the FSUIPC code on this I find that it really genuinely is a BUG! It is an error in the routine which checks whether to apply a "slope". Obviously slopes are not relevant to these axes, but the off-centre axis nevertheless resulted in the linear "slope" getting the output value wrong, mapping the whole upper portion to the 12k - 16k range. So, despite all the justification here for the jump to be there on turboprops, I am going to fix the error instead, making it a continuous axis for all purposes. as far as I can see this matches all the aircraft I've found and really canot do any harm. This fix will be in interim updates 4.207 and 3.767, this week. It will also then not even offer the slope option for 'centred' mixture axes Regards Pete

Okay, that's understandable. Those two options are defaulted OFF in any case. The first was only provided to deal with some odd FS behaviour which doesn't usually apply to good add-on aircraft, and the latter is only ever needed if you have an elevator trim joystick axis configured which interferes through jittering. Not many folks use analogue trimming. FSUIPC will only send throttle settings through to FS when they change. The way to deal with this without having to lose the ability to use the lower range would be to always park it someplace with no jitter when it isn't being used. alternatively, if the airbus you are using can accept keyboard or other controls to select the correct speed "gates" you could use the right-hand side of the axis assignments page to actually send those when the axis passes through the correct areas. There are all sorts of ways of doing all this of course. You shouldn't need to do that at all because the aircraft-specific options will swap axis assignments, calibration settings, and so on over for you automatically when you load the Airbus. Regards Pete

Very strange! That's a new one on me! I really don't know what to suggest. It sounds like your copy of SP1 may be broken in some way. Maybe downloading a fresh copy would do the trick? Regards Pete

Okay. there is one other possibility. The error can also be caused by having a SimConnect.dll (or a file ending with that name) in the FSX Modules folder or FSX main folder, or anywhere associated with other programs you use with SimConnect. Check for this and delete any such copies. Failing that I can only suggest going ahead with the reinstall or delete and reinstall of SP1. The repair suggested in my FSX Help announcement may help, though if FSUIPC4 is actually getting loaded it would seem that the base version of SimConnect is okay. Regards Pete

The first and original purpose of the message interception was for the long ATIS messages, to be able to redirect them. You get ATIS (an automated weather report) by tuning into an ATIS frequency -- many larger airports have such. FS will announce by voice and optionally by text. I'm surprised you've never used this facility. It's been around in FS for as long as I remember, certainly since FS2000 probably before. If it isn't intercepting any messages then something very strange is certainly going on. I'm not sure how to help at present. I may have to add some diagnostics to the logging to help you track it down. Regards Pete

And where is your request for help? [LATER] Oh, I see -- a different thread with the same title. You are the gentleman wh didn't look at the User Guide to learn how to install! ;-) Let me know if you still have questions AFTER looking at the documentation. The installation only consists of one simple step so you really shouldn't have any difficulties, especially with WindowsXP. It is Vista that can get confusing due to its over protection. Pete

I'll be fixing the "jump" in any case (making it optional) in an update shortly. Just got a couple of other things to do as well. Hope to make a little interim update, for both FSUIPC3 and FSUIPC4 before Christmas. Regards Pete

You have incorrect or multiple assignments in FSX then. My PFCFSX.DLL driver has nothing whatsoever to do with a standard Game controllers-driven joystick, which is presumably what your jetliner has become. It is now a joystick like any other. Make sure you disable the main aileron/elevator controls in the PFC options (Flight controls tab). I'm not actually sure why you are asking me, assuming you are not doing assignments in FSUIPC. If you are, try deleting your FSUIPC4.INI file and starting again. As far as FSX is concerned, you should be looking in the Controls-Assignments dialogues. Pete

Yes, that is what I understood from earlier in the thread. This is why I don't understand why the levers aren't notched just for those. And why has the "high idle" got a range of 12k to 16k (ie 25% of the available range) according to the way FSUIPC is programmed? Why not just 0, 8k and 16k? Ah, but the flaps are notched and you cannot actually set intervening values -- the flaps don't stay at any intermediate points, unlike the King Air's mixture lever and values. There are not really comparable, at least as implemented in FS. I'm not arguing about whether to change FSUIPC or not, I am only at a loss to understand (a) why I did what I did, and (b) why this hasn't already looked anomalous to someone even in the King Air. I mean, this isn't new, even to FS2004. It would have been like the way it is now since FS2000, some 7 years ago. Regards Pete

Hmm. I'm not sure how they are produced. Long ago I suppressed pretty much all of FS's messages so maybe I've never seen these. For FSUIPC's interception, probably the best test is to check the ATIS messages. Have you done so? [LATER] Okay, I found out how to get the "main exit opening/closing" and "exit open" message back -- restore the original LANGUAGE.DLL module in the main FS9 folder. Obviously I was using a patched version with such messages eliminated. ... and, yes, you are correct. FSUIPC does suppress those (at least the exits ones). Interesting. I didn't know that. They must use the same call into WINDOW.DLL Anyway, it does mean your current findings are indeed baffling. I can only think the explanation is one of three things: 1. The version of Window.DLL in your modules folder is not one which FSUIPC recognises, so it cannot insert the hook, or 2. Somehow the data area into which it inserts the hook is write-protected in memory, or 3. the Window.DLL is not, for some reason, actually available in memory during FSUIPC's initialisation. I'm not sure how to eliminate any of these. You could try adding the "InitDelay" parameter to the [General] section of FSUIPC.INI. Try InitDelay=3, to make it delay 3 seconds. If the reason for the problem is (3) that should help. you could even try longer. It's been defaluted to zero on FS9 but was 3 seconds on FS2002 and before. Reason (1) seems extremely unlikely. I'm not sure about (2). For some things FSUIPC does have to unprotect memory, do the changes, then re-protect it. But this hook is in a table which is filled in by other modules in FS too, so it seems unlikely. Regards Pete