Pete Dowson

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

Yes, there are offsets which can be specifically reserved for individual applications, as mentioned in the table in the Programmers Guide. You would need to work out your needs and let me know. I would register them to you and the project name. Try to keep your request down to as small an area as is adequate for your needs -- some multiple of 64 bytes (64, 128 or 256 fr instance). Pete

Ah, I see. I'm afraid I know nothing about multiplayer. Really this forum is about my own modules, but I hope someone here knows enough about it to help you. Possibly the MP system itself is not designed to go into that level of detail? I wouldn't be surprised. After all, there would be performance considerations -- it was designed to be used over the Internet, eg on MS's game zone. Regards, Pete

In FS2002 and later it needs FSUIPC installed too, to fix some changes in FS. Sorry it doesn't say so in its documentation -- it wasn't discovered till a long time after. Most folks were using FSUIPC in any case. Pete

Is this a question about WidevieW? I don't have any programs designed to link two copies of FS across a LAN. You are presumably either using WidevieW by Luciano Napolitano, or FS's own Multiplayer? Regards, Pete

You vary the vertical speed (07F2), part of autopilot I told you about, to control the pitch, monitoring the IAS and adjusting V/S accordingly. How else do you think it can be done? You said you were trying to use offset 3460 (AUTOPILOT AIRSPEED HOLD CURRENT, not supported) which would have been only the autothrottle airspeed setting -- the same as the one at 07E2, as I clearly pointed out. The A/T does not control pitch, it controls throttle -- if you set too high a climb rate the A/T will fail to reach its set IAS. If you dive then the A/T cannot hope to reduce speed unless you assist with speed brakes. If you are programming your own A/P then do it by use of elevator, aileron and throttle inputs. If you want to use the FS one you have to use the controls provided. The only one controlling pitch in altitude acquisition is the vertical speed value. You should really be able to control this by setting "Vertical Speed Hold", but the way the FS A/P is written I think you have to set Altitude Hold mode and set a target altitude (which you can keep changing of course -- or set 65000 feet for climb, 0 feet for descent). Regards, Pete

No, it isn't a conflict. It sounds very much like the bug in the 767PIC code which for some insane reason sends "full deflection" messages now and then to FS. This does actually occur regardless of whether you use PFC controls or not, but the scanning of the normal joystick inputs usually overrides it, so what you see are short-lived "flickers" to maximum deflection. These can still play havoc, however. The main fix for this is in FSUIPC. Go to the Technical page in the FSUIPC options and enable the "control spike elimination" for all three main controls. Those facilities were, in fact, deliberately added to FSUIPC for 767PIC users. Even the earlier releases of 767PIC exhibited some tendency to lock the rudder full over. In 1.3 the elevator was also a big problem, often locking full up This occurred without PFC.DLL, it is not actually a conflict with it. Also you need to remove all normal control inputs to FS from the game port or USB connection otherwise you will tend to get interference in any case. Assuming you have no other joystick inputs to FS than PFC, disable joystick in FS itself. Otherwise go into the assignments and delete the ones also present on the PFC device (though this may not be permanent --FS has a habit of reconfiguring itself next time you load). You should probably really also check the "suppress possible interference from game port throttle assignments" on the main page of the PFC options. Regards, Pete

Sounds like OnTop uses a different protocol, like Elite perhaps? Did you specify you wanted it for FS when you bought it? What do PFC say -- their support should be able to help you. On the other hand if you've installed FSUIPC and PFC DLLs correctly into FS, and told PFC.DLL the *correct* COM port (on the first page), then if the Throttle Quadrant is actually sending any stuff at all to the COM port then you should see something on the Test page even if it is rubbish (i.e. wrong protocol). I think your first recourse has to be to PFC. BTW please ALWAYS give version numbers -- they are essential. Both for FSUIPC and PFC modules. See the details at the top of this forum, and go to http://www.schiratti.com/dowson for the latest if you haven't got them. The version of FS would also be needed (FS98, 2000, 2002, 2004?). Regards, Pete

It sounds like there's a memory addressing problem and something is trashing something else. Modules are loaded in the order they appear in the folder's directory, so, each time you copy them in, the loading order changes. Can you list all the non-FS modules you have installed? Maybe it's one of the new ones, maybe it is something else. Can you get a Dr Watson dump? (Look in the FSUIPC User Guide, the section "If FS crashes ..." near the end will tell you how). If so, ZIP it and send it to me. I'll see if I can spot the culprit. Regards, Pete