Pete Dowson

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

If you still have your FSUIPC.KEY file (the one my document advises you to save a safe copy of) then you can find all your details there. If you still have any Log files from FSUIPC, then your name and email will be at the start of the Log as well. If you've not got any of that, then it will be difficult. Have you really forgotten your own name and email address, or at least those you were using when you got the registrations? If you bought the keys at SimMarket, then I would normally say go to http://www.simmarket.com, log into your account and retrieve the keys, but you have those already and I suspect you can't get into your account without knowing the name and (probably) email address. So I think you are stuck, sorry. You can ask SimMarket's Customer Services, but really I don't think anyone can help anyone with unknown name and address, and without those you cannot even prove your purchase. How did you manage to get into such a situation? (It's a first!). Regards, Pete

Stutters are NOT the same thing as low frame rates. A stutter is a short change in frame rates, or even a slight stoppage, a "jerk". Stutters are much more likely at high frame rates than low ones, because a momentary 30 fps or worse a short stoppage, when things are running at 60, is so much more noticeable. At lower frame rates FS is more likely to keep up, and when stutters do occur they are less noticeable because the contrast is less. In fact the whole point of limiting the frame rate as I do is to achieve smooth, consistent, non-stuttery performance despite enormous variations in the amount of work FS has to do in different circumstances. Renaming in the process I hope. Or, for a one-off exercise, just include the code in your project instead of linking in a library. Sorry, I don't think I understand the question. If you mean what I supposed WidevieW was doing -- i.e. read/writing data at intervals leading to the 32 IPX blocks per second -- then the interval it chooses is no doubt determined by it. Maybe there's a parameter for it? I expect he could try to send stuff every single millisecond, but I doubt that you could achieve your 60 fps then as nothing else would get much done -- or his performance would be anything but smooth as it tried to achieve 1000 fps and failed. Regards, Pete

30 fps, 60 fps? I have FS2004 running on a 3.2Gb P4 and my FS frame rate limiter is set to 20! Unless you are flying helos, I don't see the point of 60 fps -- the system is smoother with everything maxed out and a lower limit set. Maybe that's the timing loop in WidevieW? Well, mainly Microsoft I suspect. I think it's the "not invented here" syndrome. Gradually less and less official stuff is supporting this old original highly efficient Novell protocol. I expect the treatment of the protocol in the Explorer is minimal and reluctant. No doubt if you tried one of the third party file transfer programs it would be faster than TCP/IP. For the program on PC2 to read "through WideFS", PC2 must be running WideClient. WideFS has at least two ends to it -- a server (WideServer) and at least one client -- WideClient. It makes no sense having WideServer running on one PC with no clients to talk to. FSUIPC contains no Network code at all, if that's what you were thinking. No. You have to get WideClient.exe running alongside FS in PC2. This is not normally possible because both want to be class "FS98MAIN" and this is the prime IPC interface class. But there is provision in WideClient for it to start up with another classname, then it is possible. You set ClassInstance=n where n is a number from 1 to 99. This goes into the [Config] section. Then WideClient starts with a class name of "FS98MAINnn" (where nn runs from 01 to 99 according to your parameter). Your interface program would have to link (via modified library code, or your own code) to WideClient via FS98MAINnn and to FSUIPC inside FS using the standard method. You can have multiple instances of WideClient this way, each linking to a different Server by different Server names and port numbers. This isn't documented for good reason -- I don't want to support it used this way. So, have fun, but please don't ask me too much! :) Regards, Pete

If you got it from SimMarket, go there. http://www.simmarket.com. If you get into your account there I think you can retrieve your keys directly. Otherwise you have to ask their Customer Services. I don't have any keys, or any data base here, except for those keys I issued for the early donors. Regards, Pete

Oh, right. I can send it again, then. No need. I've found the original email and have forwarded another copy to you. Regards, Pete

Have you tried doing it using the assumption that the FS LAT/LON/ALT are its x/y/z? In all my explorations within FS I've never come across any other internal method, only the LLA in FS units. Ah, yesbut wasn't it in FS4 that you couldn't fly from one part of the Flat Earth system, like the USA, to another, like Europe, for instance -- Europe was added on, after using the same limited coordinate system. The Lat/Lons were sort of plastered on top. Maybe I'm remembering it wrong, and that was FS3, but I don't think so (Someone will correct me I'm sure! :D ). FS5 saw quite a change in most of that stuff. I don't remember any of the original coordinate system being brought forward. Sorry, Pete

Not sure what you mean be "change from one WX station to another". If you are jumping about amongst weather stations with different weather set, then you'd expect things to change suddenly. If you mean flying between them, then it isn't the two specific weather stations controlling weather at the aircraft, but many from the neighbourhood. I don't know FSMetar. With the latest versions of FSMeteo and ActiveSky, the weather is set at surrounding weather stations, and what is being experienced at the aircraft is supposed to be interpolated between them (many more than two). This should guarantee smooth changes, and is exactly the same as what you'd get in FS's own dowloaded real weather. I've not noticed any "brutal" pressure changes with any weather source, but then I've not tried FSMetar so I don't know what it is doing. If it is feeding Global weather only to FS then certainly the pressure smoothing in FSUIPC should work, but I cannot recommend global weather in FS2004, for reasons explained in my documentation. The only real "brutal" changes I know about are the 180 degree swings in the wind direction, which is the interpolation going wrong. I'm pretty sure that's an FS bug as it can be reproduced with downloaded weather too and no add-on in sight. Oddly, the wind speed changes are quite smooth. If I were you I'd contact the author of FSMetar and see what he/she says. Regards, Pete

Except for any Button and Joystick settings, yes, I think so. I'd have to compare each page to be truly sure. If you want to simulate an unregistered copy, though, all you need to do is temporarily remove the FSUIPC.KEY file from your FS Modules folder. Regards, Pete