Pete Dowson

Last things first -- try nVidia 52.16 drivers. They are said to be fast and not so much affected by clouds. For visibility simply select the three *** marked facilities in FSUIPC's visibility page. For clouds, there's nothing in FSUIPC -- go to the FS Options-Settings-Display-Weather page and set all top three sliders to maximum. And go and find the faster cloud graphics by Chris Willis. For weather either use FS's own downloads, or get FSMeteo or ActiveSky. Regards, Pete

In FS2004, FS2002, FSUIPC, what? I think it will, in all cases, depend on your system, your taste, and your choice of weather sources. If you'd like to be more specific maybe I can propose some things to consider? Regards, Pete

Do you mean an aircraft crash or an FS crash? There's a lot of difference! If you mean simply an aircraft crash, then it sounds like EpicMapper has a timeout which is too tight for the amount of time it takes your system to recover from that crash -- reloading scenery, aircraft, et cetera. You'll need to contact the EpicMapper folks about that. Are you running it on a Client or on the FS PC? Why you should need to reload FS9, I don't know. Maybe Epicmapper is closing without closing its FSUIPC link, which will cause problems with references to memory mapped files crashing FS or WideClient. Why are you adding that parameter? It make FSUIPC lie to programs, telling it they are running on FS2002 even if they are not. Regards, Pete

Maybe I'm not understanding you, but the only thing which would do that is if the top of the visibility layer, set in FS, is very high. The visibility limits applied by FSUIPC are for that layer, no matter how thick or thin it is. Usually the visibility later finishes a few thousand feet above the ground. Above this, if left to its own devices, FS provides "unlimited visibility" always (though there will be a drawing limit set in the Options). Go to the weather menus in FS, find the visibility, and see what you have set for the upper altitude for the layer. I don't know where you are getting your weather from, but certainly all the normal sources (FS downloads, and external weather programs) that I know of set quite thin layers. There is only one visibility layer, and FSUIPC only applies its limits to it. To get restricted visibility above that you need to use the graduated visibility option. Set a target maximum visibility and altitude, with a base of 0 (so FSUIPC uses the top of the visibility layer), then the visibility will gradually increase above the layer up to that maximum at that altitude. Regards, Pete

It should work fine. There's nothing very complicated involved in this. FSUIPC just intercepts the control number you provide, nothing more nothing less. Did you press the "Set" button? Double check the number you've assigned. If FSUIPC is not seeing anything on that axis it does really mean nothing is getting through from FS, so it isn't correctly assigned. Maybe Fs isn't liking it for some reason. Regards, Pete

There are three ways of externally controlling the aircraft position and attitude in FS2002 and before: slew mode, pause mode and setting the simulation rate to 0 (though the FSUIPC interface). Each has advantages and disadvantages, things like jerky operation, or various gauges not working in different modes. In FS2004 you can actually change Lat/Long/Alt/Pitch/Bank/Heading (known together as LLAPBH) in normal flight modes too. Really, then, you want instrumentation but no simulation. I think you'd be better off doing without FS altogether and just driving a set of external instruments. This can be done with Project Magenta modules and a special program I wrote for PM called IPCserver, which replaces FS but supplies the FSUIPC, WideFS and GPSout interfaces, so instruments driven from FSUIPC can respond to inputs from another program. If this sounds like the avenue you wish to follow, check out the instrumentation available from http://www.projectmagenta.com. You'd need to talk to Enrico Schiratti about meeting your needs as these are commercial programs and he owns the rights to IPCServer too. Regards, Pete

Well, it's only my opinion, but I hate the 2D clouds. They pop in and out and sometimes flicker. I'd put up with any lower frame rate to keep the 3D clouds at 100% The problems with not having the other two sliders at maximum are things like odd looking horizons and clouds which sometimes appear to get cut off with straight line edges. So I always have all three sliders at maximum. If this reduces performance too much, try limiting the visibilty more using FSUIPC's maxima and graduation facilities. I've toyed with the lower slider, the detail/quality one, and frankly don't seem to get much effect from that at all. For performance, go find Chris Willis's higher performance cloud graphics. They look just as good to my eyes but give noticeably better speed and smoothness. If your card is a nVidia based one, you should also try the recent approved drivers - 52.16. From what I read they reduce cloud stutter as well as being faster. I'm using a Parhelia, so I cannot attest to that first-hand I'm afraid. Regards, Pete

I downloaded the manual for the GPS III Pilot from the Garmin website, and browsing through that it really doesn't look hopeful to me. I can't reproduce bits here (it's a PDF file), but for NMEA 0183 format is simply says "supported by the GPS III Pilot and enables the unit to drive up to three NMEA devices". In other words provide positional output. The only inputs mentioned are DGPS (differential GPS) which are corrections from land units, using RTCM protocol, and the proprietary Garmin protocol for downloading and uploading routes, waypoints, map data and so on - not real-time control (I've got the protocol and it is for such static data as normally exchanged between PCs and GPSs, before and after journeys). Regards, Pete

Sounds like you have a thoroughly corrupted copy of TrafficLook there! The "File" menu dropdown is fixed, defined in the resources, not programmed, and lists: Print ... Ground Traffic Only Airborne Traffic Only Refresh AutoRefresh Exit The COM1 column is still there, as it was before, and the "State" column did not even exist before the current version, it was added for FS2004 and released in version 1.41 dated June 2003 ready for the FS2004 release -- this is still the current version, so it has never been changed! If you've used it before and seen the "State" column then it must be the same version -- so how come it's changed on your system? Corrupted file perhaps? The printing has always worked fine. It is a standard printing routine which I use in all my programs and hasn't been changed in many years. I just tried it here and it is okay. Please download the ZIP again and replace your EXE. It sounds like it has been messed up somehow. I have just re-checked the version in the ZIP to be sure. Regards, Pete

1. FSUIPC doesn't know any names, only numbers. 2. You don't say which FS you are using, but if it is FS2004, you don't need to provide FSUIPc with the number in the INI file, as FS2004 provides direct axis assignment for the flaps. Just assign it in the FS assignments dialogue. Regards, Pete

You wouldn't want to change the time in FS more than once, it causes reloads of scenery, stuff like that, so you'd set that just the once (Zulu and Local) and then use your time value to time the injection of the other data. You don't say how often it supplies the data, but if it is less than, say, 10 times per second, you'd probably need to interpolate between values to get smoother operation. Of the other information, you can set Pitch Roll Yaw (Heading) and Altitude, but not airspeed, turn rate, G's or AofA -- all those are "effects" of simulation, not "causes", if you see what I mean. The most important thing that appears to be missing in your data is position -- Latitude and Longitude! How will you determine that? Regards, Pete

I assume you are talking about FSUIPC's Keys page? You don't say. If so, then there's no reason. Ctrl + 1 (whether on the main keyboard or on the the keypad) is equally programmable. There's no distinctions in FSUIPC, and the combination of Shift, Ctrl, or Tab with any of the main keys works fine here. Perhaps CTRL+1 was stolen as a HotKey -- either in FS's HotKey page, or by WideServer, or by, for example Radar Contact, or some other external program? Hotkeys take priority. Pete

If you use FSUIPC's visibility smoothing, the visibility shouldn't change immediately. But I can't do much about clouds -- you should be able to see them in the distance and approach them, though. I've never had them suddenly appear or disappear, at least not the 3D ones. Pete

Nor I, I'm afraid. You'd need to look at a specific aircraft, see what's being done. Sorry. The aircraft I'm more familiar with have either fuel selector switches OR a crossfeed switch. I have no idea what happens when you have both. Regards, Pete

I've not heard of any solution to this yet. One user was trying to get the TeamSpeak folks to advise. With Roger Wilco I used a pair of Registered Messages which RW provided for PTT on/off, but I don't think there's any equivalent at all in TeamSpeak. I think it may need a program change to allow external program access. See what you can find out from the authors or support. Regards, Pete

Customer Services via http://www.simmarket.com. Only SimMarket have the details, I am not in the loop. You need to quote the same name and email as originally used. Best to print out the email with the details as soon as you get it next time. Regards, Pete

That does sound promising, yes. Please let me know. If it needs any other NMEA messages I can even add them to GPSout if you know what they are. Regards, Pete

Yes, but it is pretty much the exact opposite of what GPSout is about. GPSout is effectively "pretending" that FS is just a big GPS, and is producing the same output on the serial port that a real GPS would on its serial port. So in effect you are connecting two GPS's together. Normally you'd be connecting a GPS (FS in this case) to a PC or similar in order to follow or record the route on a map or something. What it sounds like you really want is some module that outputs something which looks to the GPS like the signals it gets normally from the satellites. I'm not sure if that is possible. If it will accept standard NMEA as input, rather than output, then it may do what you want. The Garmin I have doesn't. Regards, Pete

Hi Bob, I'm working on version 1.72 of PFC.DLL and I have list of possible enhancements, but I want to get some defaults sorted. Perhaps you can help by saying what you see in your problematic throttle inputs. These are the proposed facilities: 1. Small jitter smothing with adjustable timescales. Currently the smoothing operates on ANY value of change in quadrant inputs which causes a reversal of direction within 150 mSecs. i.e. current (smooth) value is x read value y at time t1, ok, new value = y read value z at time t2 .... if t2-t1 > 150 mSecs, ok, new value = z if z >= y >= x ok, new value = z if z <= y <= x ok, new value = z else, its a change in direction: discard value z, keep value y This works for short-term jitters and spikes caused by power supplies and many other physical factors, but it won't fix "slow" changes by 3 units due to pot position being just on a border. So I'm proposing to add another check, similar to the above, but where the difference between y and z is less than 5 PFC units. For this the time difference will be larger, and adjustable. I was thinking of a default time of more like 500 mSecs, but what are you observing as the jitter period? 2. Throttle + Prop + Mixture sync assignable control A special control internal to the PFC driver to copy engine 1 values or all of these to the other engines. Assignable in the Yoke and Avionics button assignments. I'll check what the FS Prop Sync control does, and maybe trap that for the same use. 3. Throttle + Prop + Sync connection toggle control I'm less happy about this. If I did it it would be an assignable toggle to disconnect / reconnect the inputs for these three controls on all engines. Would this really be necessary if the other things above were done? If I did it, should it automatically re-connect on a large change in any one of the axes? If so, how large? Half full range (eg 50 PFC units), or what? I'd rather not do this if it isn't warranted. I can envisage folks complaining that their throttle quadrant doesn't work! I'd appreciate your views on these things, as soon as you can please, as I need to get 1.72 out this week -- 1.70/1.71 don't work properly on Windows 98 (I'm having to make the restart/sync facilities conditional on Win2000/XP). Regards, Pete

While I have your attention, I sent you an email and it was rejected as follows: =========================== This report relates to your message: Subject: Registration of FSUIPC, Message-ID: <015f01c39a24$704b7780$df00a8c0@newleft>, To: of Mon, 27 Oct 2003 11:47:52 +0000 Your message was not delivered to: rickalty@aol.com for the following reason: Diagnostic was Unable to transfer, Message timed out Information Message timed out =========================== Is you ISP unwell? Regards, Pete

You closed down the client after only 2.6 seconds? It can take longer than that before they connection is confirmed! Here's a typical start of a WideClient Log, using TCP/IP: ********* WideClient.DLL Log [version 6.101] Class=FS98MAIN ********* Date (dmy): 28/10/03, Time 00:17:59.171: Client name is NEWLEFT 2484 Attempting to connect now 2578 Trying TCP/IP host "OFFCENTRE" ... 2578Okay, IP Address = 192.168.0.170 9750 Connection made okay! Try deleting the IPAddress parameter from your WideClient.ini file. See if it can find your Server by name rather than address. You only need to give one in any case, and the name is less error-prone. And you don't need to tell the server its own name and address. those parameters don't belong in there at all, though they won't do any harm. And where's the rest of the Server's Log? There will be much more than this! If FS is closed down there will be a summary of WideServer's performance, just like when you closed down WideClient. Are the times correct on both PCs? Was the Client actually started 12 minutes after the Server? Please delete the IP address parameters, and also let it run for a few minutes, then tell me what is wrong! Regards, Pete

If you are talking about a user key for FSUIPC, it will work if you enter exactly the same name, email and key as you did originally. Every character must be the same, the same as notified to you originally. If it is not working it is because you are making an error. If you are talking about the FSUIPC.KEY file, then it won't work like that if you had to reinstall Windows or reverse the registry to some point before you registered. In that case you will have to register again -- just cut and paste the details from the KEY file. It is effectively the same as installing on a new PC. Regards, Pete

What does? Sorry, you started a new thread with only "Thanks" as the title, so it is a puzzle. Best to post in threads to keep continuity. :wink: Pete

Two things I've now discovered: 1) Setting "SyncInit=No" won't help, sorry. The facility was originally designed defaulted off, and the parameter checked is SyncInit=Yes. Ooops! :oops: 2) I cannot make the restart sequence work at all on Windows 98. I've narrowed it down to the SetCommState API call. If seems to always crash the process when used for the second time on the same port, even with exactly the same data. It works completely on Windows XP. :cry: For now I will test for Windows 98/Me and switch these new facilities off if those operating systems are detected. Look out for PFC version 1.72 later this week. Apologies for the hassle. Regards, Pete

AFCAD2 already contains the key so you don't need to edit it, but Lee made a small mistake. Here's a quote from Lee: Regards, Pete