Pete Dowson

Have you actually tried doing this? Have you set more than 1 vis layer? FS has had the structures for multiple vis layers since FS2000, but it never uses them, and whenever I've attempted to use them it has always caused problems. If you have managed to create weather with multiple layers to do what you say, please send me a FLT+WX to look at. Anyway, FSUIPC really can't do much at all with FS's own localised weather, only global weather and weather fed in from external programs. I simply have not been able to locate the structures relevant to the weather at the aircraft when using localised weather. Regards, Pete

I tend to fly 737 or 757. I like short hops. But I've never noticed suden changes yet. Perhaps I've been lucky in flying through areas with either many WX stations with relatively compatible weather settings, or maybe just not enough weather stations close enough to cause a problem. I have, however, often noticed clouds in the distance whilst it is blue sky around, and the weather noticeably gets worse as approaching the cloudy area. This seems quite realistic to me. I think FSMeteo populates weather stations to a distance of about 100 miles from the aircraft. Perhaps you have the weather distance set too short in the FS Options-Settings-Display Weather tab? I now fly with all those sliders set to maximum, but I am limiting the visibility itself using new facilities in FSUIPC which will be incorporated in version 3.05. This helps a bit with frame rates, contrary to my expectations. I'm wondering if FS2004 has problems with conflicting weather at nearby stations altogether, not just the odd wind fluctuations I've seen? If so then the same should be seen with FS's own weather downloads. Possibly, sometimes, the METARs for neighbouring weather stations are actually for different times of the day, hence the differences. If so, then I really think the only long term answer would probably be for (optional?) massaging of the so-called "real" weather data to make neighbouring weather stations more compatible. Maybe that should be suggested to Marc and Damian? I really can't think of an alternative and would really rather not have to revert to the global weather solution. Regards, Pete

I think by default FSMeteo 6 sets localised weather, not global, so the smoothing as you fly is performed not by FSmeteo but by FS2004 itself. I've never actually seen winds pressure and clouds all suddenly change like you say, so I don't really understand how that is happening to you. The advantages of using FS's local weather system rather than the global system as enforced in FS2002 and before is exactly that the weather is local, you can see it in the distance and you can approach it then be enmeshed in it. It is quite a lot better in terms of realism. There seems to be a bug in FS2004's interpolation of winds when there are a few close weather stations with conflicting wind reports, resulting in wild swings in wind direction. This can occur with FS's own downloads as well and is completely independent of anything FSUIPC or FSmeteo can do. I'm not sure what the answer there is. If you prefer global orld-wide weather control from FSMeteo, as in FS2002 and before, I think you'll find that option is still there, but in my opinion it wastes a lot of the benefits of FS2004's improved weather engine. It is neither possible, nor should it be necessary, for FSUIPC to smooth local weather. All FSMeteo is doing is populating the weather stations with weather data, just as FS itself does when downloading real weather. Then, as you fly, it is completely FS's job to interpolate between the different nearby weather stations. It does this reasonably well a lot of the time, but does seem to have problems sometimes when there are conflicts. Regards, Pete

Ah, all that patch does is enable axis assignments for almost any control (and vice versa for that matter). With quite a list of axes now in FS I didn't think it would be necessary to update it, but I expect I can when I get some time. I'm afraid I'm off sick at present and dare not do anything so intricate, I shall probably make a right mess of it. Meanwhile, can't you find enough axes that you are otherwise not using, to assign to in the FS assignments dialogue? I wouldn't have thought you were using them all? Then you just need to find the numbers for them so you can edit them into FSUIPC.INI for the "B" control set. If the numbers aren't obvious from my current controls lists (for FS2000, FS2002), you can derive them by assigning keystrokes to them in FSUIPC "Keys" and seeing what number appears in the FSUIPC INI file. I am making a note here to do an update both to the controls patch program and to the Controls List. It's just that there's so much to do I can't do it all at once! Regards, Pete

Yes, it's quite a well known problem, and is primarily related to DX9 and your video drivers. It is not specifically caused by FSUIPC or any add-on, but by the switching between modes. There are a couple of other add-ons for Windows that also exacerbate this. Windowblinds is one, and the other is RoboForm. There may be others. Try closing down any non-essential background task before starting up FS2004. However, the main remedy appears to be in finding video drivers that work. You might like to check Katy Pluta's FS2004 FAQ on the FS2004 Forum here in SimFlight. Regards, Pete

That was only ever time, no date. I've not got that far checking things yet. It is quite likely that FS2004 doesn't bother to provide that anywhere accessible now. I think it was a surprise when found before. I'll see what I can do, but meanwhile of course you always have the standard Zulu and Local time (and date) values at 0238-0240. I think they'd be more efficient in any case. Pete

I've not had any other such reports. Sounds like some problem either with your network drivers, or possibly something else interacting with WideServer? If you've no other add-ons or add-ins running when it occurs, the main suspicion falls on the network card drivers or the card itself. Check also that it isn't sharing an IRQ with anything else. And try re-installing it and its drivers. If you have another, try a swap, maybe into a different PCI slot. Since no errors are seen by WideServer it seems likely that things at a lower level, i.e. in the drivers or card, are getting snarled up. Regards, Pete

There's only all the stuff ATC knows, at offsets 3130-3160. I've not checked yet whether they work in FS2004, but they will when I get to them. Pete

Hey, that's a novel use of an earplug! Any other interesting items being used out there? We could start a "most unusual cockpit accessory" competition! :lol: Thanks for sharing that with us! Best, Pete

There's a Zulu time and a Local time. Sounds like you are messing up the difference. I'm not sure, but I think you may have to change both. Try the other first, then both. Pete

Hey, that's GREAT news! Fancy it being cables! Just shows, even the simplest things can go wrong! Thanks for letting me know! Best regards, Pete

Yes, when it is being used via IPC from an external program. Each call from an external program needs data transferring. The system for this, designed by Adam Szofran way back in FS95 days, uses a memory mapped file. When FSUIPC receives a message from a program is has to Map a view of that file into its memory, and when it has finished obeying the data therein, it Unmaps that view, as you say. Is the slow down you've noticed only when an external program is accessing FS frequently? There should be no effect whatsoever with nothing interfacing to FS. Please keep us informed -- I've not yet upgraded from my 2.4Gb P4, but it sounds like I should go for an Athlon 3200 next time, rather than Intel? Regards, Pete

Sorry, I have no CH gear at all. Perhaps someone else can jump in on this. But don't forget, you need good calibration initially before adding in the FSUIPC effort. If the axis is not calibrated well in Windows then you wil probably lose resolution. Pete

The assignment of ports for USB devices has always been a mystery to me I'm afraid. FSUIPC only comes in when all that assignment stuff has already been done in Windows and FS. If it's the FSUIPC calibrations you are concerned with, then don't be, as it deals with FS controls not specific analogue inputs. Just use your FS2002 FSUIPC.INI file. I don't know if you can easily transfer FS settings from FS2002.CFG to FS9.CFG. You might be better off making the assignments again in FS2004. Regards, Pete

Cases like this are quite common. It's nothing to do with FSMeteo, but the weird cut-off system used in FS2004. Go to Options-Settings-Display-Weather and make sure the sight distance is a lot more than the cloud draw distance. For best results put all three sliders to maximum, but your frame rates may suffer. Try Chris Willis's faster cloud graphics. (See the FS2004 Forum). Regards, Pete

You don't say how you are controlling it, but if you are using a Spoiler Axis it sounds like your axis is not going far enough at one extreme (the spoilers retracted). You need to re-calibrate, making sure you have an adequate "dead zone" at either end. Pete

To clarify the current state (as described in the documentation): 1. The visibility options in FSUIPC versions 3.00-3.04 only operate for weather provided by external programs, or, except for the smoothing, for global weather set explicitly in FS dialogues. None of them work for FS localised weather. 2. There is only one visibility layer and this has a ceiling. Once above that ceiling you have whatever maximum visibility is set in the Options-Settings-Display-Weather tab in FS. For weather provided by external programs, or set as global in FS, you can use the FSUIPC option to override the upper limit of the visibility layer. In version 3.05 of FSUIPC, which I hope to release next week, these three visibility options should be working for ALL weather, universally: (a) The visibility upper limits (b) The visibility smoothing © Graduated visibility Regards, Pete

You've started a new thread, so there is no "previous post" for me to refer to. Neither of these are operating with localised weather, only global weather. I don't know about that ActiveSky version, but by default FSMeteo 6 sets localised weather, as of course does FS download, so those smoothing facilities have absolutely no effect on the weather you see. Not sure why any of the methods you mention would bother to clear all weather each time they change something. That seems very wrong. That's something to check with the authors. Sorry, I don't know what that is. Perhaps wind shear? FS2004 seems notoriously poor at smoothing winds between adjacent WX stations if they are reporting conflicting winds, and can actually reverse the wind direction several times in a short period. I have a saved FLT + WX file set, from an FS download, that demonstrates this quite clearly, flying into the Chicago area from the South. The phenomenon occurs even with no FSUIPC or other add-ins installed. I think it is a bug in the FS interpolation algorithm for the upper winds. Again, with FS downloads FSUIPC isn't at all involved. And FSMeteo and ActiveSky would both certainly be using only Global Weather, so there's no localisation for FS to mis-interpolate in any case. This would be FS's own wind smoothing? As I say, and as made clear in the FSUIPC documentation and on the FSUIPC option screens, none of the FSUIPC smoothing actions apply to localised weather, and in fact few of the weather options apply to FS's own downloads in any case. I have just finished wasting several days on a fruitless search for a way of imposing wind smoothing on all FS winds, regardless, as well as adding back the Taxi wind facility. It was a waste of time. Everything I tried was overridden somehow by the simulation engine. It is getting its weather data through a route I don't seem to be able to intercept. However, on a good note. I did find a way to impose visibility limits and graduated visibility options on all weathers, no matter the origin. I am working on this now and hope to have it working in version 3.05, next week some time. Regards, Pete

No, you still have it wrong. Without the "magic battery" feature operative, FSUIPC simply doesn't touch the battery. It is not "normal behaviour" in this respect, it is no behaviour at all, just as if it was nor running. FSUIPC is simply not involved. That is probably carried over from an earlier version. FSUIPC deliberately does not destroy your previous settings, just because you haven't registered. that would be rather annoying. As soon as you register, all your previous settings will come to life, as it were. At least all those still applicable. It is perhaps an oversight on their part. I'm sure the PMDG programmers could maintain the battery as easily as FSUIPC does if they wanted to. They may only use FSUIPC for the TCAS data in any case. That's what most add-on aircraft use it for. Really the battery running flat so quickly is an FS bug, and I had hopes of it being fixed in FS2004. MS folks did say it was "better", but it doesn't seem that much better to me. It applies to all aircraft that don't otherwise take care of it. Regards, Pete

That's one of the many user facilities which is only operational in the registered version. Please check the documentation for FSUIPC. How are you even trying to switch it on when you have no access to the options pages for it? This is not a "bug" caused by FSUIPC. Take FSUIPC out and the batteries will still drain. The user facility in FSUIPC is a "cheat" which keeps topping the battery voltage up, that's all. Regards, Pete

Sorry, I don't understand much of this question, insofar as it relates to FSUIPC. There are no sequences in either FSUIPC key or button programming, only combinations, unless you use a key press combination to set a flag which can then be a condition in a button setting. I don't know anything about doors, I never open or close them I'm afraid (that's the steward's job! ), and isn't Shift P to do with FS's Pushback? What has FSAssist to do with this? FS has always used sequences of key-presses for many things. The first key selects the mechanism, the next one or more operate it. Like E for Engines, followed by 1, 2, 3, or 4, or any or all of these, to select engines to be operated. Similarly M followed by + or - to change the Magneto switch, R + or - to change the Sim Rate, etc etc. But FSUIPC only deals in single keys, or combinations. Regards, Pete

I don't know the Elite avionics panel at all, but I do know that the GPS access controls in FS are new to FS2004. In FS2002 and before there was no way to operate the FS GPS except by mouse. Probably, with the FS2004 SDKs not being out yet, the Elite programmers don't know how to program the GPS yet. Why not check with them? Regards, Pete

No, sorry. They are merely read-outs, not controls. It isn't that it discards them, it is merely that they are not inputs. I don't know really where in SIM1.DLL I could tap into any place which would control the individual wheels. Sorry, no. I've never known anything about force feedback at all. Regards, Pete

I'm working on it now. It will be in the next version (3.05). It's been a lot more difficult to get into these things in FS2004 than it was in earlier releases. Regards, Pete

I don't think FS actually has a V/S mode which operates on its own. You have to set altitude hold mode and then the target altitude value. FS will automatically then set the V/S to its default for the particular aircraft (e.g. 1800 fpm for the 737). You can alter the V/S then to control the rate, in order to control the speed for instance. When the aircraft gets near to the target altitude FS automatically reduces the V/S and zeroes it to settle at the target. Whilst there is a switch called "V/S Hold" in the interface I don't recall it ever actually working without Alt hold and a target altitude also being set. Regards, Pete