Pete Dowson

Ah, yesI have had such reports before. You have a part of Windows installed which is not compatible with the rest. The most likely part is a module called COMCTL32.DLL. Some video drivers install one of these, and if it is not correct it can produce a strange effect whereby standard Windows dialogues, like those used in FSUIPC, are actually scaled too large for their containing window. I don't know what the easiest solution is. Possibly a re-install of video drivers, or better a later and more compatible set of video drivers. It is quite hard to simply replace COMCTL32.DLL because many things use it and you cannot change things whilst they are in use. Maybe others who had this problem and have fixed it will contribute here -- I have changed the thread title to make it more likely that someone will recognise it and help. In the end the only solution may be to repair Windows, even as far as re-installation, but I do hope there is an easier way. There is nothing to do with window sizing in FSUIPC, it is all left to automatic action in Windows. Regards Pete

I am sorry, but I do not understand any of that. Can you see if you can translate it a little more clearly please? Pete

That error message is only produced by an older version of FSUIPC, one that is not compatible with FS 9.1 update. What probably happened is that the installer for the 727 aircraft did not bother to check that you already had a later version of FSUIPC before installing one it had packaged with the product. That is very bad of it, and you should please complain to the manufacturers. It is contrary to their agreement with me when they obtained permission to package it. The fix for this is simply to install FSUIPC 3.53 again. Putting FSUIPC in any folder than the FS Modules folder accomplishes nothing, as FS is only looking in that folder for such modules. Just install version 3.53. You can always check version numbers of any of my programs and modules by simply right-clicking on them in Explorer, selecting Properties then Version. This is actually the best way to check versions of anything, there are few programs these days that don't provide such version information. Regards, Pete

Just tried it. It doesn't appear to be hooked up inside FS after all -- so I'm afraid, for an FSUIPC implementation, it will have to wait till I've done the axis-to-controls facilities. However, I see that Bob has offered to show you how to do it with the CH software! Regards, Pete

FS doesn't make any provision for positioning the gear to anything other than Up or Down, but it would be possible to assign a lever for use like a switch for this, instead of an axis. But at present there isn't a way in FS or in FSUIPC to assign axes to non-axis events like Gear. I am working on an Axis assignment facility in FSUIPC which to reach more axis and parameter-sensitive FS controls than those supported by FS's own assignments facility. Axis and similar controls ("_SET" controls, by name) take parameters to tell them what to do. For GEAR there is actually a "GEAR_SET" control, but whether it is connected inside FS or not I don't know at present -- I will try it. If it does work then the next version of FSUIPC will allow you to do what you want quite easily. It isn't imminent, however -- maybe late February. I may release an interim version before then in this Forum, so keep an eye out on the Announcements above. If it doesn't work then there is another part of the same facility I have planned, but may be even later. That is to allow any controls (FS or FSUIPC) to be assigned to operate on axis values in separate calibrated ranges, possibly different moving up or down through them. This would certainly do what you want as it would allow you to calibrate a region of the lever for "GEAR_DOWN" and another for "GEAR_UP". I think most such levers actually use microswitches -- in other words they are effectively a pair of ordinary buttons operated by a big lever. I know the lever in my PFC cockpit is like this. Regards, Pete

You also need to edit the WideClient.INI file on the target PC to provide the GPSout parameters there -- identify the COM port it is to send stuff out on, and the speed (nominally usually 4800). Have you done that? See the WideFS documentation, search for GPSout. It is also not always obvious what COM port numbers have been assigned to the two MixW ports. Take a look in the Windows device manager (Start-Settings-System-Device Manager). Using the WideFS method no COM ports are used at all on the FS PC, so that's just a waste of time. It won't do any harm, but you'll have two extra COM ports on that PC linked together for no reason! ;-) If you've set everything up in GPSout.ini and Wideclient.ini, and found the right COM ports on the Client, then the remaining problems are likely to be in setting up the application program correctly. Regards Pete

Well, not really. Let's see if I understand: You have some of the controls (axes, buttons, whatever) on a single joystick/controller operating things in FS, but others, also routing through FS you actually want, instead, to connect to your other hardware -- and presumably you don't want to open up the joystick or whatever it is and take connections direct from that, bypassing the PC altogether? Obviously, to drive some hardware from the PC you need to interface it somehow. Are you designing the circuitry for that? It isn't just a matter of linking bulbs or LEDs or whatever to contacts on a parallel or USB port. You need an interface, including isolation and current drivers, whatever. And USB certainly needs cleverer chippery of some sort. All this is hardware which I know little about -- I've played around with circuits in my younger days, when microcomputers first came out, but I really wouldn't want to do that sort of thing myself now. There are some ready-made solutions though -- check out some of the cockpit building Forums and websites, or just Google for flight sim hardware. You could probably get an all-in-one solution which allowed your joystick device to connect through the same interface hardware that is connected to your indicators, which would be tidier and probably easier. Certainly EPIC can do such things with ease, and it is programmable. There are other, probably cheaper solutions. I hope this helps. If I am on the right track to understanding your question, then I'm really not certain why you are asking me in the first place, so perhaps I am still misinterpreting it? Regards, Pete

No. The freeware MixW does not connect two computers. The WideFS solution is for an existing Network. If your two computers are not Networked then the easier solution is a direct null modem cable between two serial (COM) ports -- USB ports with a simple USB-Serial Port adapter. GPSout does include a facility to send its data via WideFS, as an option, instead of the more usual COM port out route. The MixW freeware is used at the client end to simulate two COM ports there, linked together. Two are needed because WideClient needs one of them to send OUT the GPS data it is receiving, and the application, whatever it may be, needs the other one to receive the data coming IN. MixW links the two simulated ports with an imaginary null modem cable. Beyond that it is merely a matter of setting the "speed" correct for the application, setting the choice of NMEA sentences to suit its needs, then configuring the application to actually receive the data and respond to it. Regards, Pete

I'm rather confused. What is the actual question here? You seem to be saying you have a hat and three switches which you want to use to control something external to the computer. Right? So why is the computer involved at all? What is its part? Isn't this a hardware implementation question? Can you elaborate? Regards, Pete

I don't know what all the symbols mean (never needed to find out -- I only use the Project Settings), but the fact that you are even offered "managed extensions" seems to me to indicate that you may, indeed, be compiling your module as managed (ugh, means "interpreted" to me) code! Regards, Pete

If those parts of the airbus implementation are implemented in the proprietary code for the add-on aircraft you are using, the only folks who may be able to help are those who designed and implemented it. No one else is likely to be hacking into individual aircaft code to extract such data. FSUIPC, which is probably the interface your recorder is using, was built by hacking into FS's own code but there's no way I can do this for every possible add-on aircraft. It is up to the individual implementers to help there. Your only other alternative is to find a less sophisticated Airbus implementation which does use the FS facilities for autopilot etc. Regards, Pete

I doubt if the module is loadingdid you check? The export names for C++ use some weird mangling which will disguise the two needed link address names. I only use C, but you might get away with defining the exported procedures as C even if the rest isn't. Regards, Pete

But then disconnect the joystick before re-booting FS, or it will add them back! Yes, but you understand about editing files. For the average user it is easier and safer just to delete and reload. When/if you change video cards or even sometimes driver versions you would have to delete the video section before booting -- some horrendous things can happen otherwise. It's a similar thing. Regards, Pete

It's the pointer to the data you want to write. It is defined as a "void pointer" so that you can use any data type -- a string pointer for a string of characters, or whatever. Are you just learning C? Programming things to interface to FS is not a good starting project if you are just beginning. Regards, Pete

Sorry, not only do i not know the "TRC controller", but both of those indications must be specific to the aircraft implementation, they are not available in FS. If you are implementing your own programming for these functions (e.g. via PMsystems) them i'm sure you can get help from the TRC makers on programming that end. Regards, Pete

I tried it here and whilst it wasn't worse, it was about the same. Very odd -- the "disable joysticks" obviously doesn't stop the scanning or whatever DirectInput does, even though the results won't be used! However, there's certainly no registry access for joysticks if you delete all the [JOYSTICK ...] sections from your FS9.CFG. They only got there because you did have something plugged in when you loaded FS. If you change hardware, like videos, it is sometimes a good idea to delete the FS9.CFG file and force FS to make a new one. I've managed to avoid getting into DirectX quite well. I've really no time to get into such complex stuff at present. Regards, Pete

You can do it via FSUIPC -- see the FSUIPC SDK, offsets 32FA and 3380. Regards, Pete

Did you read the sticky above entitled "READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys"? It isn't only your email and key which must be exactly correct, but also your name. It is quite amazing how many different ways folks have of spelling and entering their own names. All three parts of the registration need to be correct. Next time please make a backup of your FSUIPC.KEY file, as advised in the documentation. Regards, Pete

The user's aircraft, the one you are flying you mean? There are no such specific indications -- you have to deduce them from all the information you have. If you are flying it in person you will know in any case. Regards Pete

As far as I know the serial drivers for USB do make USB connections look like normal COM ports to the programming interface, so I doubt that this is the problem. The problem is likely to be much more to do with the fact that the software you probably installed to handle the nornal functions of your PDA (Active Sync or whatever) is grabbing the link as soon as the device is connected and switched on. I tried for ages to sort things out on my Ipaq and gave up. Sorry. Perhaps someone who succeeded (and I am sure there was at least one) can chip in if he sees your message -- else try to search through the forum, see if you can find who it was. Regards, Pete

Why not just go to FS's Options--Controls and disable the joystick input? That's all that's happening -- it is looking for one! Yes, but it would be far easier just to tell FS there's no joystick, surely? The PFC driver doesn't use anything to do with joysticks or HIDs nor does it access the registry. Regards, Pete

A zero ID field most definitely means that slot is now unused -- I simply don't bother to clear the rest of the structure as it is a waste of processing when the ID is the 'key'. The logical way is to stick to the documented rules -- zero in the Id field means that slot is not used. Always, no exceptions. I do not want to see anything showing zero Ids being treated as valid slots. They are not. Please change your methods. Regards Pete

My site? It isn't mentioned here in the forum. I have no other site. In any case, by "supported by FSUIPC" all that is meant is that the program needs FSUIPC to operate. It doesn't mean it will necessarily run on an unregistered copy of FSUIPC. I think the reason that program is unsupported is that it became part of a payware package, so unless the author requests it, I am not at liberty to make a freeware access key for it either. Regards, Pete

Well obviously that will make AI aircraft come and go a lot more, so the slots will get used, freed, used again and so on, but then yje 'range' business wouldn't have any beneficial effect. Can you please confirm that you are checking the "id" field", not just the flight number as you mentioned. It is the Id field which defines a slot's usage -- you must not use information in a slot with a zero id. Regards Pete

Okay. Thanks. I'm on to it! Pete