Pete Dowson

That is so far out of date it is unbelievable! The current version is 3.85. Please update if you want support. Registration is nothing to do with it. If you insist on using old versions you can be sure that you will get compatibility problems with new programs using new features. Your registration does not entitle you to any support for old versions, you need to update. Two things there. First, 3.82 is not supported either. It too is too old. Second, there's never been any change in the keys. If your key is legitimate it will work with any version 3. Ouch! NEVER publish your key! I may have to disable it as a result. Then you would certainly have to buy a new one! :-( I'll check it here, but I really need you to (a) use 3.85, and (b) run FS, close it. Show me the FSUIPC.LOG from the FS Modules folder. [LATER] You key works fine here. Have you looked at the documentation at all yet? Check the Installation section, particularly the boxed part right at the start. That might be relevant. Regards Pete

No. But what does the middle button click do in FS? You would surely instead assign "o" to the FS control which is by default assigned to the middle button click. Pete

No, FSUIPC provides nothing of that sort. You'd need to use SimConnect to create objects or AI aircraft which you then move around. And I'm not sure you are correct about AI Traffic limitations, at least when controlled through SimConnect. Squawkbox 4 and the other on-line packages for FSX provide the other players using the AI traffic facilities in Simconnect. They aren't using multiplayer. Regards Pete

No, simply because FS does not simulate those features. What would such functions do with nothing happening behind them? The on-line flying programs such as Squawkbox use these features, and on FS9 and before there was a way of programming them via FSUIPC. At present, Squawkbox 4 (for FSX) doesn't provide access except through its own windows -- I have asked for some way of accessing these programmatically so I can add the features to FSUIPC for SB4 (nuch like the PTT which does work okay), but this has not been done yet. Regards Pete

There are only two possible causes of that: 1. The registration key you have was purchased AFTER the system date you have set on your PC, so it isn't yet valid and looks to FSUIPC like a forgery. or 2. It is a forged key made by one of the hacked key generators floating around. I suppose it must be the former, as you surely would not be asking for support if you knew you were using an illegitimate key! :shock: If you reckon neither of these cases fit, please ZIP up your FSUIPC4.KEY file and send it to me at petedowson@btconnect.com and I will check it thoroughly. Regards Pete

Should it? I don't know how the Elite driver tries to control these things. I don't know. What do you think FSUIPC has to do with these axes? The Elite driver may be sending them to FS. Have you checked that the sensitivities in FS are set to maximum, and the null zone to minimum? What does Elite support have to say? No! 4.00 is dead, gone, unsupported, and it will not work with anything but the original unpatched FSX in any case. Regards Pete

Answered in my Support Forum Pete

Really, if you have questions on FSUIPC you should ask them over in my Support Forum. The usual reason for the behaviour you describe is double assignment. i.e. either the same control, or possibly different controls, assigned to the same FS operation in different places. It can even happen in FS alone, with the multiple joystick device facilities there. Adding FSUIPC into the mix, if you are assigning axes in FSUIPC at all you must be sure they are not also assigned in FS. Pete

So, my next question was, are they assigned directly to calibration, or to the FS control? In both the axis assignment AND the calibration? If so it was presumably FSX ignoring it? I know it sounds unlikely, but could there have been any utility program or add-on which might have been deliberately failing the throttle control? Ah, so these answers aren't necessarily relevant? No, because the settings shouldn't just change. If you want to try that, keep a safe copy of the original so it can be compared. Unless you go into the Options and change things they shouldn't be changing. It doesn't sound like any option I've provided in any case. Regards Pete

Why 3.849? What is wrong with the current official release, 3.85? Why are you only using Beta versions? Please compare 3.853 with 3.85, not with 3.849. FSUIPC has nothing to do with FS-assigned controls on the keyboard. It sounds like you have something else going on there. I'd need a *lot* more information to even start investigating. There's nothing broken here, everything is certainly working fine. And there are users of the other interim versions since 3.85 (3.851 and 3.852). The changes made are merely those listed in the Announcement above, so nothing really at all in the area of button assignments. If you can provide some more details, after comparing it with 3.85, I'd be grateful. Like your INI file and a Log with button and key logging enabled. In fact you could use that logging yourself to see what is going on. Regards Pete

By "configured through FSUIPC" do you mean assigned in FSUIPC and calibrated in FSUIPC, or only calibrated in FSUIPC? If assigned in FSUIPC, are they assigned directly to calibration, or to the FS control? If assigned in FSX have you checked that the sensitivity and null zone sliders are correct? Is there any sign of life from that throttle lever in the FSUIPC4 axis assignments, or in the calibrations? You don't say, you only say it doesn't work in FSX itself. Mayne it is merely a corruption of your settings (the FSUIPC4.INI file). I would also need to know the version number of FSUIPC4. If not the latest, please try that first. If everything else is working it is highly unlikely to be anything related to SimConnect. In fact if they are assigned in FSUIPC4 for direct calibration SimConnect isn't being used for the throttle, at least with recent versions of FSUIPC4. Pete

Pretty much any mapping program which accepts NMEA data from a real GPS, in order to show your position and other data, can accept the same formatted GPS data output by my freeware GPSout module for FS9 and before, or by the GPSout feature included in the Registered FSUIPC4 (for FSX). Personally I use Jeppesen's FliteMap (which I understand is no longer available by that name) and Memory Map Ordnance Survey maps of the UK. I think you can use Microsoft AutoRoute, and other assorted programs, such as those made by DeLorme. For flight-oriented maps, apart from Jeppesen, there's a program called "PocketFMS", which also works via a USB link to PocketPCs like iPaqs. GPSout (and FSUIPC4) can send the NMEA GPS data to a serial port (COM or USB), or can send it, via WideFS, to another PC, where it can, in turn, be sent to a serial port there. The serial port link to the PC running the map program can be a real wire (a "null modem cable", basically three wires needed) or, to keep the program in the same PC as FS or WideClient (on the client PC), by using a pair of linked virtual serial ports. These look like real ports to programs, but merely pass data internally. There are a couple of freeware programs which can do this, and some more sophisticated payware programs too. Google is your friend! ;-) Regards Pete

Examples are provided in the SDK. Have you looked? And to get the FSUIPC and FS versions you only have to Open the link, as they are obtained during the opening process, and placed into global variables "FSUIPC_Version" and "FSUIPC_FS_Version". At least they are with the C code I supply in the SDK. See the definitions in "FSUIPC_User.h". It sounds like you've not even looked at what is already provided! Please do so. Regards Pete

Check the assignments in FSX, and make sure the sensitivity is at max and the dead zone at min. for each. I really don't know what Elite do in their drivers. I really have nothing to do with their products. You probably need to ask for their support if you cannot sort it out in FSX. You shouldn't need to use FSUIPC for this. No! Regards Pete

There's no difference between XP and 2000 as far as this is concerned. Maybe you have some privilege levels set differently. Sorry, I don't know. I've never heard of any problem except the privilege one on Vista. Maybe it is just a problem with the BCB5 stuff, possibly a library mismatch? Why not try some of the other examples, or in particular the utility programs i provide such as FSInterrogate (which was written in Delphi), WeatherSet and TrafficLook? Pete

That surprises me. Is it an FSX-specific Elite driver? What does that mean? Sorry, it doesn't make sense to me. What has it got to do with FSUIPC? FSUIPC doesn't read any COM or USB devices. It does have facilities for assigning and reading Windows joysticks, however they may be connected, and Goflight devices using the GFDev GoFlight driver. Oh, and buttons on EPIC cards. A serial COM port device connected to USB via a serial USB adapter looks like a COMn port to the PC. That's what the driver for the serial adapter is for, so that serial COM devices can be used as serial COM devices by those programs who expect them there. If you have questions on FSUIPC you ought to be posting in my Support forum, near here. Regards Pete Dowson

The FSUIPC SDK contains stuff for C# users, or you could use the FSUIPC Client DLL for .Net as described in the "sticky" near the top of this forum. Once you have a program interfacing to FS via FSUIPC you will have both the FS and FSUIPC versions available to you, either directly (as a result of the connecting code), or by reading the relevant offsets, as documented. Regards Pete

I'm afraid I don't know BCB. I only provided the original C library and its source. Other users contributed the other language examples. I just checked and it appears that they didn't make a library for the BCB5 version, but simply included the source code, modified I assume, into the program source. I see there's a compiled HELLO.EXE in the package. Doesn't that work? If, as you must have, you have incorporated the source code in your program, you should be able to debug it with your compiler system's debugger. Put a breakpoint on the calls to FindWindowEx(NULL, NULL, "UIPCMAIN", NULL) and FindWindowEx(NULL, NULL, "FS98MAIN", NULL) and see why they are failing to provide a window handle. These are standard Windows API calls which have worked on every version of Windows as far back as I can remember. All they do is find a top-level Window with that classname. There's a Microsoft utility called "spy" (or "spyxx" these days) which can display a list of all of the Windows on your system with the classnames shown. With FS running you will always see a top-level window "FS98MAIN", and also, if FSUIPC is installed, one with the "UIPCMAIN" classname. Another possibility I just thought of. Could you possibly be compiling your code with Unicode (or wide character) settings, making all strings, like "FS98MAIN" and "UIPCMAIN" incorrect as far as these windows calls are concerned? I suspect they are supposed to map into "A" (ASCII) and "W" (Wide character) versions of the API, but possibly they don't, or your compiler doesn't set the needed macros for that to happen. Certainly all of the FS interfaces need single character codes -- those strings would be 8 bytes long, plus a zero terminator, not 16 plus a two-byte zero terminator. Regards Pete

Well, to get such a failure it would have to fail to find both UIPCMAIN and FS98MAIN, which would mean neither FS nor WideClient appeared to be running. UIPCMAIN is the invisible connection-window classname created by FSUIPC, and FS98MAIN is the standard classname for the main thread window created by FS (all versions, not just FS98). WideClient also creates FS98MAIN on client PCs, emulating FS98 (and all subsequent versions). So, to connect, you use the code or library supplied. There is one possibility which may restrict connection. If you are running on Vista and have FS running at elevated administrator privileged levels, then any client program you wish to connect to it must also run at that level -- otherwise Vista blocks access. It should be unnecessary to use "run as administrator" for FS except when Registering FSUIPC. Regards Pete

But I tend to think that's not really relevant. The logs show the sequence is identical up to the point where it finished executing the final 1070 control. The thread running the Lua program is dead and gone by then. All of the "SendInput" actions to FS are done in the main FS thread. And the keypress encoding for the button isn't from a separate thread. I really don't understand why there's a difference, and, unfortunately it is impossible to trace it or even log it more finely without changing it (a touch of Heisenberg's Uncertainty Principle)! I did try some small timing changes, mostly to the speed at which the SendInput calls are made, and doing this I could get all three ways acting the same -- but they all simply then obeyed the ALT+A (displaying the Menu (yes, even yours)), but lost all further keys -- or possibly stored them and released them to FS after. That is actually what i expected to happen in any case, but now I know that the multiple keysends and the Lua action works so well, I put the code back so that those complete sequences still work okay. Regards Pete

Okay. When you've registered FSUIPC4, on the GPSout page of the options, in FSX itself (in the AddOns-FSUIPC menu) you will see Sentences, Interval, Port and Speed selections and you can enter them there. No file to edit, FSUIPC4 does that for you. Well, that and a sample configuration file was all it came with. Well, the separate GPSout program needed FSUIPC installed for it to work too, and that came with a User Guide which I suppose you ignored too? :-) All that has happened is that GPSout is now incorporated into FSUIPC4, and is no longer freeware. The fact that the GPSout documentation has then been improved and included in the FSUIPC4 documentation wouldn't matter to you if you never even saw any for the old GPSout! If you don't want to look at any other parts of it it won't matter. But you need to get a Key then Register (which you do at the Installation stage, so you'd need to re-run the Installer after you've obtained your key). Regards Pete

What do you mean "syncro"? Throttle, flaps and toe brakes are independent, not synchronised. And there's generally no need to edit any INI files unless you are doing fancy programming stuff on buttons, or making lots of aircraft-specific settings and need to rationalise them. Just calibrate your controls first, as in the User Guide. Pete

Okay, i've done all the testing I can here. I don't know why it isn't working from your gauge. It works, as you know, from that Lua program, and it works also with a button programmed like this: 1=P1,1,K65,24 2=P1,1,K65,8 3=P1,1,K80,8 4=P1,1,K13,8 The Lua program is doing EXACTLY the same as your gauge, except that it terminates as soon as it is done (and it runs in a different thread to FS in any case). A button programmed as above isn't using offset 3110 or control 1070, but it is merely sending keystrokes direct. The sequence from your program logs EXACTLY the same, almost to the millisecond, as the Lua program. The whole sequence is dealt with in 281 or 282 milliseconds in both cases, every time. Where they differ is in the ARRIVAL back in the FS window procedure of the sequence of WM_KEYDOWN and WM_KEYUP messages. And that is outside of my control. They've all been sent within the 300 milliseconds. They all arrive differently in the two cases. I suspect this must have something to do with what your Gauge is doing immediately after sending the sequence. Does it then exit and wait for then next normal Gauge wake up call, or whatever? (Sorry, I know next to nothing about writing gauges). I think it may need to. If you are continuing to keep control of the main FS thread after the sequence is sent, you are not allowing FS to process its messages correctly and this messes the timing of the ARRIVAL (and therefore interpretation0 of these keyboard messages. FSUIPC cannot give control back during the processing of your request, of course, as this is within a windows message already (from the SendMessage in the interface code). It has to exit, back to your code. In the case of the Lua program, it is terminating (and it uses a different thread in any case). In the case of the button programmed to send keystrokes, FSUIPC goes directly back into dormant mode waiting for new requests immediately afterwards. So, in both cases, FS's message processing proceeds normally directly after. If, looking at your gauge, you cannot solve this by rearranging things, then I suspect the only answer will be to program a virtual button to do as above, or else use a Macro or a Lua plugin like the one we've tested. However, if these are activated from your Gauge I suspect the same problem may arise if it then keeps control. Note that, if all this is merely in order to load a different aircraft, a possible alternative method which might be worth investigating is renaming aircraft files somehow and using the "Reload User Aircraft" control -- assuming the details aren't being cached by FS, of course. Regards Pete

No. The program can be installed for use as an interface for client applications, but the User Facilities are only available after Registration. There's no where which talks about any user trials. Click on the link in the documentation, or on the Web site where you downloaded FSUIPC, or in the list of supported versions in the Announcements above. It is really, really hard to miss! There's even a whole page about it in the documentation, even how to pay by post if you don't want to use credit cards! The user guide tells you exactly how to register, with pictures even, once you have purchased a key. Without a key you cannot register. And the documentation tells you how and where to purchase a key, as do virtually all other places talking about FSUIPC! No. but you said you had it working with FS9 using the free GPSout program didn't you? You said "I am able to load and use GPSOUT with the FS9 ( 2004 version), and it works fine with my GPS 396." So, it will work with the GPSout facility built into FSUIPC4, once you register. Since it is a lot easier to set up with FSUIPC4 than it was with FSUIPC + GPSout on FS9, it makes me wonder how you managed that, then? Or did someone do it for you? The documentation is more comprehensive for the GPSout facility in the FSUIPC4 user guide than the small text file provided with GPSout, and its options dialogue does have a checkbox to enable it, and a place to enter the Port. You just need to actually read the right part of the User Guide! There's even a contents list to help you find it quickly! And there isn't a file to edit with some complex text editor as you had to with GPSout! I really cannot understand how you find it all harder now when it is all made so much easier! Can you explain that? Regards Pete

Yes, certainly. You have permission. Okay. Thanks. Maybe I'll get my son, who lives in Spain, to read them for me! ;-) Thanks and Best Regards! Pete