Pete Dowson

FSUIPC has absolutely no knowledge of what video system you have, nor does it need to know. the registration is held in a file called FSUIPC.KEY in the FS Modules folder. If that is still there are staill the same then it cannot become "unregistered" unless you re-installed windows or rolled back to a copy of the registry pre-dating your original registration. In either of the latter two cases, just re-register with EXACTLY the same information as before -- cut and paste it from the FSUIPC.KEY file (which you can open in any text editor) for ease and accuracy. You got something wrong, then. Your name and email must also be EXACTLY as originally entered! No, that is entirely irrelevant. No, the registration is tiued to the ORIGINAL name and email, not any new one. Yes, just enter the details correctly. Also, please update to FSUIPC 3.53, the only currently supported version. your 3.48 is well out of date and is not supported. Pete

Neither are relevant, as all GPSout does is throw standard NMEA sentences out of the Port you specify at the speed you specify. Nothing more, it is very very simple. Go to http://www.systeminternals.com and get PortMon. Use it to check that the data is going to the port. Everything after that is to do with your cable and device, or its software. Regards, Pete

There's no chance at present. I just don't have time to do the documentation (for that's all there would be). Sorry. Last time someone did this for an Apple or Linux PC was years ago, and he just analysed the data streams and asked the odd question now and then. Things have changed a bit though since then. Regards, Pete

In the user documentation for FSUIPC version 3.53 there is a boxed warning about FSUIPC and FS2000. It does tell you how to work around this problem -- which otherwise I have found no solution for. Please try it. Regards, Pete

Just pull up the GPS on your FS screen and compare values. I really cannot do more than that. Yes, this is what GPSout is doing, and it gets the track from the GPS and corrects it to TRUE using the current MagVar. Early versions of GPSout did provide track computed approximately my own way -- from heading and wind vectors, but this was in error on occasion. The GPS values have given excellent service according to all those who reported the earlier discrepancies. Regards, Pete

There's a misunderstanding there. FSUIPC injects nothing at all into FS9. That is all done through the multiplayer interface, it is nothing to do with FSUIPC. What may be injected into FSUIPC's "TCAS" tables, for reading back by TCAS gauges and the like, are details of the same traffic that is being sent via MP to FS. This used to be done by Jose Oliveira's "AIBridge" program for SB2 but I suspect SB3 has it built in now? I don't know about the IVap programs I'm afraid. I don't know how your program is reading data with "regular multiplayer", sorry. All that side of FS is a complete mystery to me, something I've never dealt with. The FS DLL "TrafficInfo" only deals with AI traffic I believe, and that is all switched off when Multiplayer is enabled. If your TCAS display is reading FSUIPC's TCAS tables then the traffic has to be injected into those in the first place. I don't know what program you are using for this, but it sounds like you need to find out what part does what and then ask the author. Maybe you aren't running a crucial part of the total package? I'm afraid I cannot advise any further. I don't have any of these programs. I hardly get time to fly off-line let alone try my hand at on-line flying, though I would certainly like to, one day;-) Regards, Pete

Sorry, I just couldn't read all of your single extremely long paragraph. Please, next time you write to me try to break it up a little so it is readable. Your problem sounds like one already covered here in another thread. I think it turned out to be video driver problems. Certainly, if it is AdvDisplay that concerns you (you don't actually say anywhere, I had to guess) there is nothing in it which can have those effects -- it is all a video driver problem. I'll see if I can find the other thread. Stand by ... [LATER] Right. See these threads: http://forums.simflight.com/viewtopic.php?t=47479 http://forums.simflight.com/viewtopic.php?t=46795 The second actually showed a solution found, thus: I don't know if that will apply to you, but certainly either a change of video drivers or finding better settings will fix it. I think you are just on the edge of the cards capabilities with your settings and adding one more Windows takes it over the top. Regard Pete

What version of GPSout are you using? That was changed a long long time ago! Track (TRUE) is provided in RMA, RMC and VTG Heading (MAG) is provided in VTG Track (MAG) is provided in AV400 In Fs2002 and before the track has to be computed from heading, ground speed and wind vectors, so it may not be so accurate. In FS2004 GPSout obtains it from the GPS values -- the track will be the same as that shown in FS's own GPS. Regards, Pete

FSUIPC doesn't use Networks at all. You mean WideFS. WideFS isn't making folder-to-folder connections at all, it is using the TCP/IP or IPX/SPX protocol to talk across your Network -- program-to-program, not program-to-file. The other things you mention are all to do with Windows Explorer and its file sharing facilities. I'm afraid that's an area I know little about. I use it of course, but I'm stumped if it goes wrong. I did run across problems recently with "too many connections" failures in Networked file access. It seems that Windows XP is deliberately limiting how many connections you have to to any one PC. It is up to 5 with WinXP and 10 in WinXP. It seems if you need more connections to the file system that that you have to buy Windows Server. If you have mapped folders or drives, then each may represent at least one connection -- I don't tend to use them much, I just point the program to the folder via the normal explorer-type views. Then the connection is only counted whilst it is being used. Regards, Pete

Thanks Hugo. However, I think the latter is usually the problem. you can't easily change a DLL which is in current use, and most of the common Windows DLLs are in constant use -- the desktop and Explorer use them. This one might be an exception, I don't know -- it depends what is running I suspect. You don't need to go far to find an assortment of different versions of COMCTL32.DLL. I searched my own C: drive and came up with 6 of them, of 4 different versions. I think some of the Windows XP updates replaces that DLL. I notice also a COMDLG32.DLL and wonder if that may have something to do with the reported problem too, though I think it used to be only COMCTL32.DLL which was replaced by some video driver installs. The problem with the DLLs downloaded from the site you gave a link to is that it seems to have only one version of each and doesn't say what they are for (e.g. what operating system, version and so on). I just looked at the COMCTL32.DLL on the DLL site and it appears to be older that all 6 of those on my system. Regards Pete

I did it! I used the long way round -- uninstalled everything I could find dealing with BlueTooth. then installed the stuff from the manufacturer's CD (Belkin it was) -- but this time I did NOT plug in the bluetooth adapter first! I think that was the problem last time. It got very confusing. This time I refused to put the adapter in untill all the software was installed, THEN plugged it in and followed the instructions to point it to where the drivers were. ... and it works! Well, it talks to my mobile phone and to my mobile phone headset (provided the mobile phone isn't already connected to it!). I could use the little mobile phone headset (light, comfortable thing clipping to the ear) for ATC, if I ever fly on-line! All I need now is a Palm with Bluetooth! ;-) Thanks! Pete

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