Pete Dowson

It is more likely to be a problem with your user key. Remove your FSUIPC.KEY file from the FS Modules folder and try again. If that works it sounds like you have registered FSUIPC or WideFS with an illegally generated key. If you believe it to be genuine, zip up the KEY file and send it to me at petedowson@btconnect.com. Otherwise simply stop using it. Regards, Pete

Try AdvDisplay 2.133, being sent at present. Regards, Pete

Version 1.10 of GFdisplay, on its way to you and the usual websites now, supports options for delayed indicator 'off' actions and the extra timed flashing options I mentioned. Please see the recent Changes notice near the top of this Forum. Regards, Pete

That's rather strange. Doesn't it give any clues as to why, an error message or something? I don't know. Basically it closes the server port and re-opens it so forcing everything to re-connect, so it is more of a restart than just the client trying to reconnect. But whether this will reset whatever is stuck on your Network I couldn't say. You'd have to try it. What normally clears it? For instance, if you close down FS and restart it, effecting restarting WideServer the log way, and that clears it, then restarting WideServer in situ using the hotkey may well really do the same. But it will depend on the cause. The fact that it happens does indicate something rather dodgy going on in the server PC. For instance, if it's due to a memory leak in FS or an accessory which is gradually using up real memory space until the buffering on the network is affected, then restarting WideServer without FS and the add-ons may not clear the cause. There are some known FS memory leaks -- one, I understand, can happen just by placing certain scenery types (autogen?) in the wrong folder (Addon scenery folder?). I'm not sure of the details, I just recall reading these things. Maybe, after trying the WideServer restart, if that doesn't help, or only helps for a short time (i.e. re-using the little space freed by closing the server port), you should ask around, for instance in the FS2004 forum, and see if you can discover other possible causes. Regards, Pete

Probably writing the velocities and even maybe accelerations to all or some of the offsets 3060 - 30B8 and 3178 - 31D0. These are all "writable" but have temporary effect, or at some have an effect and others may not. I know, for instance, the the aircraft carrier operations programs uses these for tailhook decelerations and, more importantly, catapult launchings. But I'm afraid I don't know which, if not all, would need to be written and which are totally ineffective, if any. If you went down that path you'd need to experiment. Regards, Pete

No. Just that is FSmetar is frequently setting the visibility to 6.2SM (9999 metres), and FSUIPC is randomly extending that each time, then sometimes it will be set less than FS's threshold of 10.4 or whatever and sometimes more. Please review the detailed explanations I've already given. I really don't think I can explain it any clearer. Sorry. Hmmm. Not sure what I should be looking for. Is that the weather DLL you are using? Is it for FS9.0 or FS9.1? Try restoring the original. Regards, Pete

I think the "View1 mode set" control should work. The parameters go like this (I think): 1 = cockpit 2 = virtual cockpit 3 = tower 4 = spot Regards, Pete

I'll see if I can find a way to do it. Regards, Pete

Sounds like the normal jerkiness on finals when approaching a densely designed airport, one with a lot of buildings or AI traffic or autogen scenery. It may be exaggerating the sort of slow-down you'd normally see because your process is being starved of sufficient time to do the updates at the intervals you need. What are the relative frame rates in FS, between your smooth results and these? That should give you an indication of what is going on. If you are running on a P4 with hyperthreading, check the Windows task manager -- see if you are using one "virtual processor" whilst FS is using the other. that should make things run smoother. If you are not using a P4 3.0 Gz or better, think about upgrading. Reduce your autogen density -- the autogen scenery has a greater and greater effect on performance as you near the ground. Once you land it is less because the views are then effectively two dimensional. See if reducing other density adjustments help -- scenery density and AI density. Regards, Pete

I don't know. There are several values displayed. What are they? When you press the Set above each column, that merely records the incoming reading at the time. You will have 4 of those. What are they? Then, on the left there are two values shown -- the input value (the ones recorded for the 4 positions), and the resulting output values after calibration. When you pull back below the lowest of the centre values, the output value will go negative -- that gives you the reverse thrust. When the input value reaches the lowest value, the "full reverse" value in the left column, the output will be at maximum reverse thrust. Nominally this is -4096, but that will then be rescaled according to the maximum reverse thrust available on the specific aircraft. Most offer less than this (25% of full forward), but some may offer slightly more. Don't forget that reverse will not engage unless there is no forward thrust at all -- check that you don't have any other throttle inputs operating. Also, of course, reverse thrust is not available on all aircraft. For the CH throttle quadrant I think you will find a lot of advice specific to that device on Bob "Sticky" Church's website. http://www.ch-hangar.com Regards, Pete

Good. The other key was a fake then. Thanks for letting me know. Regards, Pete

No. I'm not sure why you would want that. Reverse thrust levers pull back to increase thrust. No. Isn't that the same thing? The CH quadrant has a detente position for idle. You'd normally want to program reverse thrust below that, pulling back. You can, alternatively, employ a separate reverser axis -- either one for all engines, or up to 4 separate ones (using the current interim release 3.475 available above). In both cases you can, if you wish, reverse that axis, though it still seems to me an odd thing to do. Also in both cases you have to reduce the normal throttles to idle before reversers can be engaged. It isn't that you "can" assign reverser(s) to mixture control(s), they are already assumed assigned that way in FSUIPC. That can be changed by editing the FSUIPC.INI file, but the default is to assume mixture control inputs. Whether those mixture controls are actually assigned on your quadrant is another matter -- you do that via FS's Assignments, not FSUIPC. The reverser action is not programmed unless you actually calibrate the reverser (or reversers) in FSUIPC. Then they will operate, optionally on Jets only (there's a checkbox for that), but only when the forward throttles are brought back to idle first, as in real aircraft. It is best to calibrate the main throttles with a good reliable idle zone so that this can be assured. There is also a parameter in the INI file which allows you to set a higher value than 0 for the "idle" acceptable for reverse engagement -- but FS usually needs a true zero idle. When it is a separate axis you can choose to reverse it if you wish, just like all other axes calibrated through FSUIPC. Regards, Pete

It cannot make any difference for FS9's weather. I really don't know why you are seeing sudden visibility changes there. With FSMetar it reall depends what it is setting. If is doesn't determine its own variations in visibility when faces with a "9999" or "10SM" visibility report in a METAR (both of which merely indicate "above ...", with 9999= metres, or about 6.2SM, and 10SM obviously 10SM), then what might be happening is that, each time it sends new weather with "9999" or "10SM", FSUIPC is operating its "extend METAR max" option and generating a new visibility value greater than the 9999 or 10SM. In the case of 10SM, the likelihood of alternate random values being above and below the FS threshold of 10.4 (or whatever) is very small. However, when in Europe with 6.2 SM as the "max" there is obviously more scope for it to drop below FS's threshold. Maybe I should change the option so that it always treats both 10SM and 9999 as "greater than 10.4" in future, on FS2004 at least. If it is this option which is causing the problem then that would fix it. But try it. Turn it off and see if you still get the problem with FSMetar. If, as you say, you get it with FS's own weather, then it does seem unlikely that the option has anything to do with it. I don't know about that. Any details? You can do that easily in FSUIPC's joysticks section. Check the step-by-step instructions in the User Guide. You can also select a response curve which gives you more control near the centre (i.e. less sensitivity) whilst increasing sensitivity towards the extremes so you can still reach full deflection. Regards Pete

Okay. That's probably the correct legal way to do it in any case. I don't think these keys are intended to be transferable -- you'd need to check SimMarket's conditions to be sure. Regards, Pete

Because that's a better way to trap the pirates and thieves. Pete

Sounds fishy to me. But I can't tell unless you send me the file. Pete

Okay. That usually is an indication that something is wrong with your registration key. Can you zip up the FSUIPC.KEY file and send it to me at petedowson@btconnect.com and I'll check it. If you include the details you received from SimMarket when they notified it to you it will make it quicker for me to work it out. It is still sounding like a bad user key for FSUIPC. You did get it from SimMarket, didn't you? If not, where please? Regards, Pete

I assume that upper panel is undocked, then, a separate window? It sounds like it is constantly re-drawing itself. Have you tried "Locking" AdvDisplay in place instead of docking it. If it makes no difference, which panel part are you docking it too (check the panel.cfg file). I had one devil of a job getting it to work on the main FS window without flickering. I'm not sure that I would be able to come up with a solution, but I'll make a note to look at it. But please try locking it first. Regards, Pete

No. If it's the grey sky versus blue sky business I explained, then it could only happen on a change of visibility around the FS threshold, 10. something miles, I think. It cannot smooth the graphics representation. FS is presenting a blue sky when the visibility is, say, 10.40000 miles (or close), and a grey sky when the visibility is 10.39999 miles (for example). No matter what smoothing occurs, if the value crosses the threshold FS changes graphics. It's completely insane, I agree, just like the 4 mile threshold in FS2000 and FS2002 was insane -- but 4 miles is, in my opinion, less insane than 10 miles! I don't think much will make any difference, except possibly disabling the Extend METAR max option and/or using a good weather program. Same here. :wink: Sounds like a combination of joystick calibration differences and the silly dynamic time-related reaction FS started by default in FS2000. You need to add "stick_sensitivity_mode=0" to the CONTROLS section of your FS9.CFG file. That makes the response linear as it was in the good old days of FS98. :) Well, some of the "realism" options are known to be somewhat overdone, but it also does depend a lot on the modelling. You may like X-Plane, but that's even more sensitive to the modelling and you need to get things right. In FS I would advise you to first put all the realism sliders about centre, or not much higher, then try a variety of third party add-on aircraft. Some are excellent, some are awful. You should always trim out any pressure, once in stable flight, whether climb, cruise or descent. Real aircraft vary a lot too. The Cessna 150A I trained in was very twitchy in comparison to the Piper Cherokee 180, for instance. I had to give up real flying because of my eyes (retinitis pigmentosa, causing deteriorating peripheral vision to the point of extreme tunnel vision, as I have now). Regards Pete

Grey overcast is surely to do with clouds, not visibility? What do the weather read-outs say in the two cases (in FS Weather dialogues and in WeatherSet2)? If it isn't due to clouds it will be because the visibility is set very close to the threshold above which you see blue sky (and stars at night) and below which you see mist (your grey) and no stars at night. In FS2002 and FS2000 I think this used to be around 4 miles, but in FS2004 for some reason they extended it to around 10. Someone did measure it precisely once, but I don't recall what is was. Something like 10.4 sm (1040 FSUIPC units of 100ths of a statute mile). You could check yourself using WeatherSet2. What's "default weather" in this context? Visibilty settings of 50, 18, 15 and 10 represent half a mile, 0.18 mile, 0.15 mile and a tenth of a mile, respectively. You should have 5000, 1800, 1500 and 1000 respectively! The units are 1/100ths as clearly stated. By "extended random weather", I assume you must mean "random extend METAR max"? That's important if you use an external program but it has no effect for FS's own weather. For an external program providing METARs in Europe, the variation it is setting will vary from 6.2 miles upwards, so if the weather program is re-sending the visibibilty changes regularly you may get fluctuations above and below 10 miles, so you could try switching that off. What "smooth changing" is set to 2%? I don't provide any smoothing adjustments by %. The visibility smoothing is 10%, you can only vary the timing. Baro smoothing doesn't work in FS2004 with FS's own weather, though it can with a weather program. Why have graduated visibility off? My only recommendations would be as per documentation. All variations are then a matter of taste. You cannot stop FS hiding the blue sky when the visibility drops below its threshold -- if you never want to see a grey sky you'd need to set the minimum to 1100 or so -- it defaults to 0. But that will only apply to externally set weather. Quite honestly, I've never seen sudden loss of blue sky except when descending into a poorer visibility layer, and that does approximate to what can happen in reality. The main thing which is totally unreal in FS is that the visibility restrictions apply in ALL directions (except, stupidly, down!) -- and the least realistic part is that a 10 mile or less visibilty makes the sky directly above grey too, whereas of course it should graduate from grey to blue (or grey to cloud textures). I regret the changes in FS visibilty since FS2000, which I think had the best visibility effects. FS2002 was totally naff in that area, but the improvements made in FS2004 are offset by rather insane blunders like this 10 mile (approx) cut off. Finally, you may find the payware alternatives like Active Sky and FS Meteo are far better. I've used both for years and have never suffered from the sorts of problems you describe. Regards Pete

Ooops. Sorry. Fell through the net. Actually there are a couple of other bits there which may just possibly be useful too. One of them is 2^2 which is set if FSUIPC is fully registered. Regards, Pete

What's the "Elite" tab? There's nothing in any of my software like that. Ah, you have a separate "Elite" driver which uses FSUIPC? In that case it sounds like one of two things. Either the driver checks the version number of FSUIPC, and specifically doesn't work with version 3, or your FSUIPC user registration isn't actually valid. To check the latter, try removing the FSUIPC.KEY file from the FS Modules folder and see what happens when Elite tries to run then. In either case, check the FSUIPC Log file (also in the FS Modules folder) to see if there's anything relevant recorded there. In fact, close FS after getting one of those "Elite FS needs FSUIPC version 2.9x or ..." messages and show me the entire FSUIPC Log file. Are you saying that, before this, you only used your Elite driver with FS2002? If so, it sounds very likely that you need an update from them to work with FS2004. Have you contacted their support at all? Let me know what you find. Regards, Pete

Sorry, I've been too busy with other things to really spend that much time on it. I did dedicate a whole week to it last year, and in nearly 80 hours got nowhere. Maybe I'm getting too old. :cry: I'm not starting to look any deeper into FS2004 now. I'll maybe look again when FS2006 is out and dealt with. I also don't really like the current built-in ATC very much, preferring to use Radar Contact, so my heart is not in it. Sorry, I don't really understand that part. Regards, Pete

If this is using keystrokes, then surely keyboard users must be complaining too? If it is using keystrokes but the keyboard use doesn't suffer so much (i.e. having to press the key a hundred times to get one degree change, or hold it down for 10 seconds or so), then the reason will because you/they are not programming all 4 button numbers for the rotary, and not using both the press and release -- as Ii said, a single click is a press or release. They alternate. I can't really help much more as you are not actually telling me anything. :wink: Regards, Pete

It doesn't work like that. If you are having problems it isn't likely to be with the Keys -- if it is there will be entries in your FSUIPC Log file saying so. The SB3 program has several of its own DLLs in the FS Modules folder and they each have their own key already, built in. I'm sorry, but that's as much as I know. Every request for keys from the SB3 team has been met and they've all been programmed in -- there are several. If you have problems (I understand it is still in Beta and what you have will be a "release candidate" in any case) then you need to tell the programming team, as this is why they make these pre-releases. If you have a paid up user key for FSUIPC, and it is legitimate, you won't get any registration problems with any FSUIPC programs in any case. If you have an illegal key then you will get problems with most programs -- in that case delete your FSUIPC.KEY file and run FSUIPC in unregistered mode. Regards, Pete