Pete Dowson

There's no problem actually shown in the Log extract you provide. The section 49516 AIRCRAFT\VIPER\VIPER.air 54203 C:\Program Files\Microsoft Games\Flight Simulator\GAUGES\F16.GAU 54203 not listed in Key file 192484 READ1 02A0, 2 bytes: 34 0E 192484 READ1 0560, 24 bytes: 00 00 92 DB 31 6E 50 00 00 00 merely says that the F16.GAU isn't listed in the FSUIPC.KEY file. That doesn't mean it doesn't have access. It may be supplying its key automatically. I could tell if you enabled IPC write logging, instead of read (why DID you enable IPC read logging anyway?). If it was being refused entry there should be an error message in the log saying so -- there isn't one. In fact there's nothing for over two minutes after it starts. Did you suddenly decide to turn the IPC read logging on after 2 minutes? That doesn't help. The gauge may simply be reading the FS version and deciding it doesn't like FS2004, so it isn't running. Have you checked with the author, (Eric Marciano?), to see if it is supposed to work in FS2004? Many of the FS2002 gauges have such checks. I do have a fiddle which you can try if that's the case, but let's get more information first. It looks most unlikely that this is anything to do with registration or accridatation. Don't run TrafficLook, that confuses the issue, and enable IPC read and write logging BEFORE loading the aircraft. If it's your default, enable that logging then close down and restart FS. Regards, Pete

Hmmm. So the one they supply for home use is not so good, really? I use a fully and regularly updated Norton AV and that says it's okay too! :) Thanks, & Regards, Pete

Just load up FS, press ALT M F to get into FSUIPC options, press the button saying "Register an application program", enter "FSMetar" as the program name and the Key you know as the Key. Press OK. Why is this difficult? It is exactly as described and even illustrated in the User Guide. It is simply entry of the program name and the Key. If you like you can instead edit the FSUIPC.KEY file and add it in there, but you are sure to make a mess of that if you are so careless with your spelling. Anyway, why would you make a real mess, and how on Earth do you think a mistake will mess anything else up? Do you really think that I'm such a poor programmer? I'm really not at all surprised you had problems with Squawkbox, as you've not spelled it correctly once in your message -- is is NOT "Squackbox", nor "Squakbox". Please just try to be a little more careful and enter the correct names, not ones you invent yourself! Regards, Pete

You would have to write a program to handle the serial port and thence interface to FSUIPC. The interface for FSUIPC is described in the FSUIPC SDK, available from http://www.schiratti.com/dowson. However, you should be aware that many third party cockpits have their own autopilot system. Whether the PSS A320 autopilot can be controlled programmatically I don't know. You should check first. If it accepts keystrokes your program may be better off reading your COM port data and sending keystrokes to FS. You can do that directly, emulating a keyboard in Windows, or sending FS "WM_KEYDOWN" and "KEYUP" messages, or, perhaps more reliably, do that too through FSUIPC (see offset 3200 in the Programmers' Guide). Alternatively, if you want to be able to program which keystrokes to use in FSUIPC, and maybe use your input for other things too, you could make your program operate the "virtual joystick buttons" FSUIPC provides (offset 3340) and program their action in the FSUIPC "Buttons" page. This method is probably simpler than the keyboard method. Regards, Pete

Sorry, I have no idea. What was your previous version of FSUIPC? I don't know Weather Center at all I'm afraid. If the previous FSUIPC you had it working with was 2. something, perhaps the Weather Center program has some version check which is wrong? Otherwise, if you enable some of the logging in FSUIPC then maybe we can see what it is doing. There's an option for weather logging, try that first, but it may be that you need to enable the IPC read/write logging too to get enough data. Are you also asking the Weather Center author? Regards, Pete

Ah, NOW I understand! You are confusing the setting to limit the surface wind with the FS2000/FS2002 "Taxi Wind" facility, which was entirely different. That operated by directly changing the wind experienced at the aircraft, without changing the weather, as such. The surface wind you are limiting is the lowest wind layer, i.e. the whole layer. There is no taxi wind facility in FSUIPC for FS2004 because I couldn't find any way to get to the wind actually imposed. If I could, I would be able to smooth it too! I'd love to do this, but in many many hours or hacking through FS code I haven't managed, and there are other things needing doing. Please check through the FSUIPC User Guide some time. It does actually mention all these things. You certainly were NOT using the same option in FS2002. Well, two points there: (1) The option doing that in FS2002 was the Taxi Wind facility. You are not using the option you used in FS2002. You are limiting the surface wind layer's speed actually being set. (2) Because the wind being set IS limited to 1 knot, that IS the wind, there is no other, so that is what ATIS correctly reports. Regards, Pete

If you set the weather sliders in FS's Options-Settings-Hardware all to maximum, you shouldn't have many occasions where clouds appear suddenly. That's usually due to limited cloud drawing distances. They may still pop up at that maximum distance, but it is less noticeable. Make sure you have 100% 3D clouds as the 2D clouds are notoriously bad both for popping up and flickering. FS2004's own downloaded weather "morphs" the clouds -- i.e. it grows them and shrinks them. I've been trying to find a way into that mechanism in FS2004 but it is simply so complex I don't have much of a hope. Microsoft won't help, at least not until FS2006, by which time I hope to have persuaded them to provide some weather interface so that third party weather programs can compete. As far as wind shifts are concerned, FS should be interpolating those correctly between stations, but there is certainly a bug in the FS code as 180 degree wind shifts can occur -- even with their own downloaded weather. It is not a phenomenon limited to the add-on weather programs at all, though, since the weather they provide tends to be more complete, more varied, it may be more likely. I know both the main weather program authors are trying very hard to find ways around the problems in FS2004 and I expect both FSMeteo and ActiveSky to be superior to FS's own weather in due course. FSUIPC's smoothing can only smooth what is going IN to FS's weather stations. Except for visibility (which I found a way to bypass) I cannot get to the actual wind and clouds being presented in the simulator, I can only smooth the inputs being made to FS. What it then does with them is outside my control. I don't know FSMetar, sorry, so I cannot even advise on what steps it may be taking. I think you'll need to ask the author. I only have regular contacts with the authors of FSMeteo and ActiveSky. Regards, Pete

Yes, I've got that document now. Looks to have the data I need also. FS2002 was quite different! Don't try to apply that document to FS2002. Regards, Pete

Without knowing what you are actually doing it is difficult to comment, but first test it with the default 737, not the PMDG -- it's cockpit system is probably overriding the autobrake with it's own switch setting. This will explain the flashing in PM -- the PMDG cockpit won't be running when you are in FSUIPC's menus. If you need to override the PMDG interference and it's A/B action is not a separate gauge in the PANEL.CFG, then you'd probably need assistance from PMDG, or perhaps talk to Bob Scott (see PM Newsgroup) who is getting good at patching the cockpit code! :) . As for the views changing, that sounds like a conflict between your chosen button allocations and the FS assignments -- check FS's Options-Controls-Assignments. Regards, Pete

I don't know what moving map software there is for PDAs, you'd need to search the web. The only stuff I do to drive moving map displays is based on those expecting the output from a GPS, to NMEA 0183 standards. NMEA GPS output is by serial connection (COM) and is specified to operate at 4800 bps, but I support (and prefer) higher speeds if possible. This is in my GPSout module. There are no standards that I know of for GPS's using USB outputs. Regards, Pete

Post it in the Radar Contact forum too. Are you using the latest Beta, or only the current released version of Radar Contact 3? I think there's been quite a few changes. BTW I thought generally as far as ATIS and METARs are concerned, a 1 knot wind is likely to be regarded as calm. Pete

You can make FS respond to external positioning in one of two ways -- either as an observer in a multiplayer connection (where it thinks it is connected to another FS doing the flying and is participating only as an observing passenger), or through an interface like FSUIPC manipulating the six degrees of freedom (LLAPBH -- latitude, longitude, altitude, pitvh, bank and roll). For the former you need to look at the Microsoft multiplayer SDK. For FSUIPC check the FSUIPC SDK (http://www.schiratti.com/dowson). It has been done. There's already a program doing it for the Aerowinx PS1 Precision Simulator for a 744, and I'm sure others are doing it or in the process. Additionally there's a program called WidevieW which links multiple copies of FS together for multiple display views, and that uses similar techniques (not multiplayer). Regards, Pete

Last question first: if FSUIPC is installed, and there is a Modules menu with FSUIPC listed, then it is working. If, when you select that menu entry you see an "About" dialogue that says you are registered, and gives your name and email (or address) on the right-hand side, then it is not only installed correctly, it is fully user registered. I'm afraid I don't know FSBus at all, and do not know what it is looking for. If everything else looks correct, I suggest you ask the FSBus folks for guidance. If you want me to check anything, go into the FSUIPC options again, enable IPC read and write logging (in the Logging page), and try FSBus again. The shut everything down and show me the log (Zip it if big -- you should be able to attach it here if the ZIP is less than 125k). Regards, Pete

Good. Well done! Hmmm. I really don't know what you are talking about. With WideFS the "Server" is where FS is running, with "WideServer.DLL" installed. That's why WideServer is called WideServer. The Clients are all the PCs not running FS on which you want to run WideClient and FS applications. That's why Wideclient is called WideClient. The Server sits waiting for any Clients to connect who want to talk to FS and/or get data from it. The exchange of data is two way, but it is the Clients who request a service of the Server. Clients can come and go. The server stays open and ready for as long as FS is running. Think of it like a shop with a counter and a shop asistant (server) with customers (clients). I really can't see how you can have mixed up "WideClient" as being a Serving program and "WideServer" as being a Client program -- after all the names say it all, don't they? And it makes absolutely no difference to any of that what protocol is used. The protocol is merely the carrier of the data, in BOTH directions. Regards, Pete

I still think TCP/IP is your best bet. I had nothing but trouble with IPX/SPX on a Network with a WinXP sever and Win98 clients. I think you will do too. What is wrong with your TCP/IP? It should be good, and it is even installed by default (which IPX/SPX is not on WinXP). Your logs don't tell me anything I'm afraid. Where are the INI files? There's no connection at all being made to the Server, it is simply not seeing any attempt at all. And I've NEVER seen this error (reported by Windows): 45045 Error on client pre-Connection Select() [Error=10060] Connection timed out It seems that the Windows 98 software is trying to connect and simply giving up after 45 seconds. I've no idea what can cause that I'm afraid. If I were in that situation I'd probably uninstall both Network cards, then re-install them and their drivers. If you really want to use IPX/SPX, do not also have TCP/IP installed. Things seem to work better with only one protocol on each Network card. However, even that didn't work for me on a mixed network. It was good on a completely Win98SE setup. Pete

What does that mean? Are you saying they are in the wrong units, or that they never change with switch operation, or what? Please clarify. And is this FS2002 or FS2004? What sort of figures do you want and what are you getting? Those values are in the second, unsupported, table in the Programmer's Guide. No one has ever actually asked for them before, and it is quite possible they are not even hooked up at present. If I know what you are looking for and how I can check it I may be able to fix something in the next FSUIPC version. Pete

If you do find any information about FS2004 AFD file formats, please let me know. I need to update my Runways database generation program (used for FStarRC and Radar Contact) but so far I have no information at all about AFD file formats in FS2004. Thanks. Pete

I don't know. I never got it working satisfactorily (i.e. consistently) for anything on a mixed network. Anyway, TCP/IP is easier and is better with WinXP I'm sure. You didn't mention the Server Node, only the TCP/IP address which of course isn't used in IPX/SPX. But that is still meaningless to me -- folks tend to mean "the latest I have seen you release", and I have had cases where what they thought were "latest" were pretty old. In all cases I always need to know the version numbers. They are easy enough to find -- either look in the Logs or right-click on the programs/modules and check Properties-Version. Well, I think you might have saved a lot of that time by posting some real information -- INI files and Log extracts. So far all I know is that it doesn't connect. Before posting anything it might be a good idea to change back to TCP/IP, or installing Win98SE instead of WinXP on your Server. Also check on your WinXP system that you don't have the firewall preventing access. Regards, Pete

The "position" you are getting is merely Latitude 0, Longitude 0. It indicates that Squawkbox is not connecting to FSUIPC. Check the FSUIPC Log, it will probably tell you why. The most likely thing is that you have not registered FSUIPC as a User, and neither have you registered Squawkbox as an application. Please check the FSUIPC User Guide supplied in the ZIP. If you don't need the FSUIPC user facilities so don't want to pay for it, just check the Freeware Key list earlier in this Forum and use that to register Squawkbox in FSUIPC. Pete

As always, the answers are probably in the Log files which I assume you've not looked at? Please always check the logs for error messages. Points to note: 1. IPX/SPX is really a problem when using a mixed netwrok of Win98 and WinXP PCs. I could never get it working properly here. 2. If you are using IPX/SPX then the ServerName is no good -- WideClient need the full node Address when the Server is an NT/Win2K or WinXP PC. Please check the WideFS.DOC supplied in the WideFS package. 3. Since WideFS version 5.50, the default protocol is TCP/IP. If you haven't set "UseTCPIP=No" in both Server and Client INIs it will try to use TCP/IP in any case. 4. You need ALWAYS to specify version numbers in any queries. Just saying "updated" is meaningless to me. Regards, Pete

That makes sense. The only other report I have (sent provately) was also from an AVAST user. Odd, I've never even heard of AVAST before today. :) Thanks. You sent them the DLL too? As I said, the file is compressed and very little of it represents executable code as it stands. Virus checkers don't check data files because it is known that random items of data can resemble virus code. Because a DLL is presumed to be an executable it will be checked as if it is all code, which in this case isn't true. Regards, Pete

Doesn't TTools give you that? AFCAD displays them with their orientation, so I assume it must. I haven't a clue about AFD file formats, especially the new ones in FS2004. Maybe someone else here will know, but you may need to ask in other forums. Regards, Pete

No. The update rate is limitied for the regular PHs and QPs because they operate procedurally, reading Gauge Token values by calls to PANELS.DLL which in turn calls SIM1. DLL, etc. Very slow. Direct FSUIPC reads are very fast and not a performance problem. Pete

The virus checker you are using is mistaken. I use Norton Antivirus and it is kept scrupulously up to date, and it is evidently more thorogh in its checking than the one you are using. FSUIPC is compressed and expanded automatically only when actually running inside FS. Consequently very little of it in the file is actually code. It sounds like your virus checker is mistaking a compressed string of data for code which matches or partly matches its image of a virus. Regards, Pete