Pete Dowson

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

Please check my announcement at the top of the forum. I can send registration details and details of testing to developers. Pete

WideFS is the only one I am always charging for. FSUIPC in its use purely as an interface to FS will be free to users -- please go and read something about it all before you criticise. I shouldn't have to keep repeating the same information Regards, Pete

I have no site. I do not run a web site. This forum is as close as I get. How does FS2004 say these things? Doesn't it know 2.9 is only an internal Beta release? Or are you referring to a person? FSUIPC version 3 will support FS2004, and it will be released on or a little before the same time as FS2004 is released, which is the 29th July as far as I've been informed. If it is much earlier than that I'm afraid FSUIPC might be a little later than FS2004. How did you get FS2004 so long before its release date? I'm on the Beta team and I've had it less than a week and I still therefore have a lot of work to do! Pete

Please read the announcement at the top of the forum. It is all there. You could also follow all the very detailed questions and answers, some much more clearly worded than I could possibly provide, in the thread entitled "FSUIPC Payware, I support it". It's long, but you'll find it quite amusing in places! Regards, Pete

I'm afraid I don't know anything about Squawkbox or Roger Wilco, and I certainly wasn't aware that RW "autoloads" -- how does it do that? What loads it? It won't load itself unless it has some background process or driver running to do this for it. If SB has a facility to load RW, then of course it cannot when SB is not even on the same PC. The same may apply to this switching of frequencies -- I don't know any "ATC directory" (is this in SB?), but if SB feeds frequencies to RW, it won't find it if it's on the other PC, now will it? None of this is anything at all to do with WideFS or FS. Roger Wilco is NOT an FS Application as such, it doesn't interface to FSUIPC or WideFS, it is an entirely separate program. Only FSUIPC client applications can communicate via WideFs, and then only if they are programmed to do this. Regards, Pete

737NG uses FSUIPC. Maybe you have an old version, or maybe their installation installed an old version? Check. Make sure you have FSUIPC 2.975 and WideServer.dll 5.50 or later. Right click on them in Explorer and check the Properties-VersionInfo. If this isn't it you'll need to wait for their response. There's no relationship at all between any aircraft and WideServer, so they must be stomping on something. Regards, Pete