Pete Dowson

AhI think this was where my Bluetooth adapter went wrong. I had two installs going on at the same time (I did put the manufacturer's disk in), and i think I just said yes to everything. I will try uninstalling everything and starting again. I'll look to see if they have a PocketPC version, as my Palm doesn't have BlueTooth. Thanks for all the information. I hope it will help others too. [LATER ...] Darn it! They only support Palm. Shame, it's a good looking program! Maybe worth getting a Palm with bluetooth. I don't use this Ipaq in any case. ;-) Best regards, Pete

Good. Since then I checked a bit further. It appears that you can use FSSound in FS2004 if it is needed (I assume some Gauges use it to play extra sounds). To avoid the FS error report on start-up you have to add the following to the FS9.CFG file: [OLDMODULES] FSSOUND.DLL=1 but see if there's an "OLDMODULES" section already there first -- if so just add that second line. You'll find the FS9.CFG file in your Documents & Settings folder, under your user name then Application Data - Microsoft - FS9. Regards Pete

Well, three things about that: 1) Instead of waiting (which may be in vain, as I said this problem has been VERY rare) you could try different video drivers, as I suggested. One set (older or newer, I don't know) may install a proper compatible version of the Windows DLLs. 2) You could ask the Windows expert, Katy Pluta, over in the FS2004 Forum how to check and update Windows DLLs from your install CD, instead of having to re-install the whole system. With Win98 there was a system file checker program that would do it. 3) For many of its early releases, there was no Options dislogue for FSUIPC -- that was an extra added in version 2. Before that folks had to decide on options by editing the FSUIPC.INI file. That is still possible today. All of the user parameters for the INI file are documented in the "Advanced User's Guide", part of the FSUIPC.ZIP package. I know it isn't so easy that way, but it is possible. If I can find anything else out about correcting this Windows problem I'll post it here, but I am on holiday from tomorrow night for two weeks. Sorry. Regards, Pete

Nice pix, and thanks for posting them. But actually it was the nitty-gritty of HOW you got GPSout talking to the Palm that folks here might need to know. There seems to be a lot of difficulty with getting the USB stuff to operate like a normal serial port -- maybe because the usual PDA Synch. programs take over? I have a Garmin iQue 3600 (a Palm with OS5, but USB connection, no WiFi nor Bluetooth), and an iPaq PocketPC with USB, WiFi and Bluetooth, and I've not managed to talk to either! :-( Possibly your Palm has an ordinary COM connection, not a USB, which would presumably be a lot easier? But you mention Bluetooth? I purchased a little Bluetooth-USB device for my PC and can't make it do anything with anything. Maybe you could show your GPSout.INI parameters, and notes of how you connected, and set up, the Palm end, please? Thanks! Best regards, Pete

There are absolutely no changes to FSUIPC which can do that. The change for 3.53 was merely to allow new registrations in 2006 to be accepted. Why did you do all those things? Are you saying you did all that BETWEEN running FS with 3.52 and 3.53? If so, how is this "narrowing it down" to 3.53? Assuming you are using FS9.1 (the original version FS9 had lots more reasons for CTDs), CTDs are almost always driver problems -- most notably video and sound drivers. The only reason there may be a difference between having FSUIPC installed or not (assuming you have nothing actually using FSUIPC) is down to small timing differences and memory arrangements. You really do need to do a process of elimination other than simply discarding better versions of FSUIPC. Regards Pete

FSSound.dll is nothing to do with me, but I think it was made for FS2002 not FS2004. You may need to add something to the FS9.CFG file to tell FS2004 that it's okay. It sounds like you tried to install an add-on which is VERY old. Either that or it is badly put together. Doesn't it even tell you about this stuff in its documentation? The package has also installed a very old version of FSUIPC. The current one is 3.53. Just go to http://www.schiratti.com/dowson and get yourself the current version, which is compatible with the FS9.1 update to FS2004. All versions of FSUIPC issued since the FS2004 update came out, 16 months ago, have been fine. You will need to take better care to install add-ons which are either up-to-date, or better able to support Microsoft's developments. If you purchased this one recently please write to the publishers/authors and make sure they know of your dissatisfaction. Regards, Pete

Ahthe AV400 spec? Thanks. I've downloaded it and will file it for reference. Happy New Year to you too! ;-) Aren't we all, just a little, at least? :-) Best regards Pete

As I said, that is the problem. I do not really know. I have never seen the problem here, on many different systems, and it is extremely rare - about 4 cases in the last 4 years! I don't know how the others solved it, that is the problem. Folks don't come back and say. The first thing I would try to do is update or change video drivers. It is very likely to have been one version of those or another which changed the crucial Windows module in the first place. Other than that I only know of a Windows re-install. If you know how to manipulate Windows systems then you may be able to get COMCTL32.DLL reinstalled from your Windows CDRom. Maybe Katy Pluta (over in the FS2004 Forum) can help you with that, she is a Windows XP expert. Otherwise, I do hope someone else can come and help -- I did change the title as you can see. Regards, Pete

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