Pete Dowson

You can use your existing FSUIPC.INI file. No problem. But if you are using some of the extra facilities, like the joystick calibrations and button programming, then you need to Register your copy. Full details will be announced here next week. Regards, Pete

Why use ActiveSky to get weather information? There's FS's own ATIS, and there's also my own WeatherSet, part of the FSUIPC package, which will report the weather at the aircraft. Isn't it ActiveSky, if you are using it, which is supplying the weather to FS, the very weather you want reporting? I don't understand what you want to use it for if it isn't supplying the weather? Maybe these questions are better directed to the ActiveSky folks? After all, they may know more about it than someone who doesn't even use it? Sorry I can't be of much help here. Good luck! Pete

Sounds like a video driver issue to me. Have you asked in the ActiveSky support forum (is there one?), see if others have similar problems with, perhaps, similar hardware? I think the first thing to try is updated or different drivers. I can't think of anything else that could screw around with stuff like hardware acceleration settings. Pete

Each SLOT is 40 bytes. So if you read 40 bytes at F080 you get all the data in Slot 1, in the format defined. There are 96 such slots, the next one starting at F0A8 (40 bytes ater the start of the first one). In fact these size and count values can be read (size is at F000, the number of slots is at F002, as documented). However, they are likely to remain fixed, at least for another two years, so can be assumed unless you are really worried about long term compatibility. You *can* read the whole set of 96 slots in one go, by reading 96 x 40 bytes at F080. This is actually what my TrafficLook does. Providing you don't do that too frequently this is fine. However, there is a 96-byte array of single byte counters at F008 which tells you which slots are changed, so if you wanted to be more efficient you could read only the slots which have changed. This is more programming work, but less data transferred. For a TCAS scan rate of say once or twice per second it probably doesn't matter. All this information is there. If it was in the same form as the simple data it would say "TCAS data: F000, 4096 bytes" because the whole block of 4096 bytes (F000-FFFF) is reserved for the Airborne traffic data. In fact, if you look in the main table it IS there, in exactly that form! However, specifying the data for up to 96 aircraft like that wouldn't help much, now would it? How would you decode the 4096 bytes without the additional data I give in the earlier parts of the document? Please explain what it is you don't understand. I find it rather difficult to be more explicit, everything is defined quite precisely already. Regards, Pete

Well, there must be plenty of VB programmers around. I expect one or two here would be able to help if they see your message. I'm having some trouble understanding your question. In the Programmers Guide I provide a structure. Admittedly it is defined for C use. Can't it be converted to VB? Doesn't VB support any types of structure? If not, all you need to know is that each 40 byte slot, starting with slot 0 at F080, contains: Bytes 0-3: ID number as a 32-bit number (0 = slot not used) Bytes 4-7: Latitude as a 32-bit floating point number Bytes 8-11: Longitude as a 32-bit floating point number Bytes 12-15: Altitude in feet as a 32-bit floating point number Bytes 16-17: Heading as a 16 bit number in regular FS format Bytes 18-19: Ground speed as a 16-bit number Bytes 20-21: Vertical speed as a 16 bit number Bytes 22-37: A zero-terminated ASCII character identity Bytes 38-39: The COM1 frequency tuned in, in BCD (see Guide) In the next version of FSUIPC, when it is used with FS2004, the string at 22-27 will be shortened by one byte and byte 37 will contain a status byte telling you what stage the AI aircraft has reached (taxi, takeoff, etc). Hope this is clear. Regards, Pete

I have heard about this before and I think it is known to the PM folks, to whom you need to address your inquiry. It is not a function of my software. Please check with PM support. Regards, Pete

Okay, it is easy enough. I'll send a Beta WideClient when I get a chance to put it in. Please write to me on petedowson@btconnect.com with the request so I can be reminded and return the result as an attachment. Only that existing applications couldn't connect to a WideClient with modified class names. But obviously you can have one copy of WideClient with standard names as well as the others which can only be accessed by your modified interface applications. Yes, it is only checking against a conflict with the class names. Regards, Pete

I've never heard of that. Are you observing any incorrect Lat/Lon values being read? If your program is reading bad values you should surely be able to detect them? Maybe there are occasions when FS (or your PC) is doing something whch causes the call to FSUIPC to time out and return an error. If you are not detecting this and taking action to avoid the non-data return, then possibly you are reading (0, 0) as a valid location. No doubt that would be many thousands of miles off course! Pete

On the contrary, Adam required licenses to be purchased by all commercial users of FS6IPC. When FSUIPC came out free for all, including commercial use, that was the first time there was actually a completely free interface. Really there's no difference now, because the FS interface parts (IPC) of FSUIPC are free for freeware and end users, but licensed for commercial users. The only user license payable is for the extras which are added to the IPC functions, which were never provided by FS6IPC in any case. The only similarity between FSUIPC and FS6IPC is the interface for external applications. I've always kept that the same to maintain compatibility for programs, though I'd often wished I'd changed it in the early days, it isn't the most efficient or flexible way to do it. BTW, for those of you who don't know, Adam Szofran is now part of the Microsoft FS development team, and has been since well before FS2002. Regards, Pete

It works fine, as can be seen by using AIBridge. I cannot diagnose your problem without any data at all. You can check exactly what you are doing with the IPC logging in FSUIPC. If you cannot see anything wrong from that, by all means show me a log extract showing exactly what you are writing. Also check the range -- maybe it is beyond the set range. Or there are no free slots. Regards, Pete

Yes, I read that. And I replied. Sorry, I do all my replies whilst reading the message, so the answers are in the same sequence as your questions. It is quicker that way. I do have lots of other things to do. Sorry. No, I don't think so. Of course. The source code is all provided. You can do what you like with it. Window titles are used by both WideClient and WideServer to display other information, admittedly optionally. Window titles for different FS versions are different, and moreover they are different for different language versions. Whilst what you propose is feasible, it is not as simple as you make out to make it general and it is bound to involve users in additional configuation settings. I do not mind at all whatever you do internally for yourself, and I do not mind if you publish what you do for others, I just want it to be very clear that it is an alternative for specific purposes. In all the seven years since WideFS was first published there's never been another request/proposal even slightly resembling this one, so I don't feel there's a demand. If you had wanted my original proposal, of using different class names, then that show-stopper wouldn't arise. I still feel that is the only sensible way to do it. I can very easily provide parameters in WideClient.ini to set alternatives to FS98MAIN (for multiple loads) and to UIPCMAIN (for connections). It is just as easy as providing a parameter to set different titles. but more sensible IMHO. I could just do it by adding an Instance Number to both (FS98MAINnn and UIPCMAINnn) according to a simple paramter in the INI. After all the INI has to be changed for each instance in any case, in order to specify a different Server and/or Port. Incidentally, of historical interest, back in FS98 days there were some applications which did use the Window title to identify the correct Window - as well as the class name. In fact the WideServer additions to the FS title mucked them up, so an option was added to the WideServer INI to stop it changing the title at all. That is still there. Yes it is. But I think it is better to use the Class, see above. Regards, Pete

When I'm happy that it is ready. It is looking good so far for release around the time FS2004 itself is released, or probably a little before. I'm pressing on, still lots to do. BTW it won't just be an FS2004 version, it will be the supported version. It applies to FS2000 and FS2002 as well. Folks can stick to older versions, but I can only support the current one. Regards, Pete

No, your applications would have to be changed to find a separate Window (by a different Class name), they depend on finding the window to Send the messages to. Yes to the Servers (I said that already), no to the Clients on one PC -- you can have several servers on different PCs and several clients on separate PCs, this would be used in a Multiplyer or WidevieW linked multi-cockpit set up, for instance, and has always been possible. Because of the way the Window class name is used to allow applications to find and link into the system there can only be one of each (Server or Client) on each PC. Yes, I said that in my original reply. Yes, but this would be your own private SDK version. I'd rather you made your own, with a different name, else it could get dangerously confusing. The source is provided in any case. You'd have to change/recompile your applications. It wouldn't be any good for existing applications that you don't have the source to, unless you patched the different classnames into the binaries. It isn't a change to FSUIPC. It is nothing to do with FSUIPC. It is only allowing the class names (FS98MAIN and UIPCMAIN) to be changed by parameter in WideClient only. Nothing else of mine is affected. You mean the Window Title text? Yes, you could do that. But at present WideClient won't load twice. It checks that there's not already any top-level window of "FS98MAIN" class already running. It does this to (a) stop trying to compete with FS itself for applcations to interface to it, and (b) to prevent having two copies of WideClient running with random applications attaching to each. It wouldn't, any way you did it. It would only ever be WideClient and the applications concerned. Not my SDK. It would be your local code, or not an SDK any more. Yes, but in that case how do you get the applications to talk to the server you want them to? You have to do something to the applications. Hmmm. It would need to be very carefully labelled, renamed, distinguished. I wouldn't want to cause the sort of confusion and problems that could arise should it be used unwittingly! Regards, Pete

2.983 is a Beta version, for testing only. It has only gone to FS2004 Beta testers and developers. The official and supported version of FSUIPC which includes FS2004 support will be Version 3, which I am now sure will be released on or before the day that FS2004 is officially released. But I am still working on it. Regards, Pete

Well, it can be used for this, of course. You'd have to write a program to read whatever information you needed and write it to wherever you wanted it. You need the FSUIPC SDK -- go to http://www.schiratti.com/dowson. Regards, Pete

Well, you've identified the reason why it won't work -- though it isn't the SDK which works like this, it is the IPC interface mechanism designed by Adam Szofran about 8 years ago and which has been continued in FSUIPC ever since. The reason it is continued and maintained is for compatibility. If any application was changed to do it some other way then it wouldn't interface to FSUIPC. All WideFS does is extend the FSUIPC interface to other PCs, and WideClient "pretends" to be FS so that applications written to interface to FS think they are doing so. If you are writing your own applications and you don't want to interface to FS itself you can of course do it a different way. It would be possible, for instance, to have a parameter for WideClient.ini which set the "FS Window Class" name to something other than FS98MAIN and the special FSUIPC class name to something other than UIPCMAIN. Then you'd do the same in the application program, and so be able to run more than one WideClient. Each client could connect to a different server simply by naming a different Server and/or Port. The Port is definable in the Server too. Regards, Pete

Yes, Gauges and other internal programs must use the internal library (or equivalent code). They are in the same Process as FSUIPC, so the normal "IPC" (="inter-PROCESS-communication") method is not only inapplicable, it is horrendously inefficient by comparison. Incidentally, you wouldn't actually choose the locations in FSUIPC address space yourself -- I have a more up to date list of the areas which are allocated, and would select an area for you when I know how much you need. The list in the SDK was only correct when it was published. Wel, certainly knowing that would help if you wanted a largish area, but I would otherwise try to assign something unique. You never know what other 3rd party additions you may use or try and you wouldn't want the surprise of having your data areas trampled on. Actually, Mark Burton has already contributed a Java section for the SDK. It is ready here ready for inclusion in the next edition (within the next two or three weeks). Not for any technical reasons, only to avoid double use, as I mentioned above. Also, future versions of FSUIPC may use more. For instance, in FS2004 I am providing new Weather control facilities which use areas previously free. I'd need to allocate them and keep a record to avoid causing you problems in future. It doesn't have to do anythng, but it is best if I reserve an area for you for the above-mentioned reasons. Otherwise you will have to stick with a know working edition of FSUIPC and not add any more third party stuff in case they also used your area. That's certainly a possibility, but I would hate to lose a large chunk that way, and a small one may not be enough. I'd rather keep it the way it is for the time being. I will certainly bear your idea in mind though. Thanks. Regards, Pete

Weird. It's usually IPX which gives problems. BTW I pulled all my hair out long ago! Pete

Ahthat's at least more understandable. The computer "GAME" most certainly seems to be not recognisable to the client computer, at least not on the Network that is being used here. Why that should be I really don't know. Do you actually see GAME listed in Windows Explorer, under "My Network Places" (probably inside "Entire Network"-"Microsoft Windows Network"-""). Actually, come to think of it, are both computers in the same work group? Do they have the same name against "Workgroup"? In XP you can find that by right clicking on "My Computer" then selecting Properties, then the Computer Name tab. If this is not it then I hope someone else has some ideas. Regards, Pete

In your WideClient INI you have: UseTCPIP=Yes ServerIPAddr=192.168.0.1 Port=8002 which is fine, assuming the IP address is in fact fixed as that. I see in the Server log: Date (dmy): 08/07/03, Time 11:35:57.613: Server name is GAME so why not try setting the Server name (GAME) in the WideClient, rather than specify the IP Address? The it will find it even if the IP address is changed. As for this error: [Error=10065] No route to host I admit to NEVER having seen that one. All the Microsoft documentation says about it is "the network cannot be reached from this host at this time"! Sort of implies that at another time it would be okay? Weird. I hope someone can help you. I assume you've made sure you've got no firewall getting in the way, either Windows XP's own or ZoneAlarm or something? No router in the way? I'm no netwrok expert I'm afraid, and never having seen this particular error before leaves me floundering I'm afraid. Regards, Pete

He gets about quite a bit, he usually answers but it may take a few days. However, you should know that I currently provide the driver for PFC hardware into FS, and will be able to do so for your panel when you are able to supply interface information. Thanks, Pete

No, sorry. I have no idea how to use a USB port without specific drivers for the connected device, and I'm not getting into that are of Windows complications. Anyway, the NMEA standard applied to GPS connections with computers currently only specifies the formats for serial port connections, at least the versions of the specification I have seen -- are there any real GPSs with USB connections? You can get little devices with drivers which provide COM port simulation on a USB port. They aren't expensive -- I saw some recently at only £14 (about $24). I use on one on of my PCs because I ran out of COM ports. Regards, Pete

It is possible, using some versions of EPICLINK and EPIC.VXD. But it depends upon having the EPIC.VXD installed on both PCs, and most folks have Windows XP installed on their new (ISA-less) PCs. It is then impossible -- NT/2k/XP do not support VXDs. The only other answer for EPIC users is to change over to the USB version of the EPIC. You do gain a lot more power and programming capacity then, but it does also mean some re-programming. The new EPL is quite a bit different. Regards, Pete

If the 737NG programmers have made their own autopilot with no provision for external control and igniring the normal controls then there is no possibility. A "new" FSUIPC and FS2004 has nothing to do with it. It is really up to programmers of aircraft to consider those with home-built cockpits as well as those with ready built controls like PFC. If the 737NG programmers have provided an interface for external control, as, for instance, Project Magenta did, then by all means I will consider adding support for it to the PFC driver. But this is nothing to do with FSUIPC or FS2004, and I will certainly not have time to consider it until well after FS2004 release. Have you asked the PMDG folks? Is it documented? It sounds as if you need to use their fine model (visual and flight) but substitute a standard FS panel/autopilot so that you can use the controls. If you find out otherwise, let us know. I am always interested in good 737 models, especially NG, even if I won't have time to deal with them for a while. Regards, Pete