Pete Dowson

Yes, of course. As detailed in the announcements here, I do offer free registration of FSUIPC for those who donated enough early on. But I don't have the mechanism here. Can you please send the details to my email address petedowson@btconnect.com? Thanks. Regards, Pete

Ouch :wink: Sorry, I haven't the patience to work through that, I'm afraid -- at least, not unless I realy have to! :) If you are talking Buttons, then you should note that, as mentioned in the Release Notes for FSUIPC 3.10 in the Announcements above, there's been a bug in recent versions of FSUIPC that stopped the repeat option working. Try again with version 3.10, which is now available. It should work with any button programming system -- at least there's nothing I've put in to stop it doing so. Regards, Pete

[quote name="John EGPF Does leaving the maximums settings unchecked give my unlimited visibilty at lower levels' date=' regardless of what the MS weather thinks it should be?[/quote] No. You get whatever the MS weather says. But if the METAR is "CAVOK" then you'll get the maximum FS visibility, which really in not very realistic for the UK, and is going to be greater than your 60 miles upper visibility for graduation. If you don't want the odd upside down effect, then the maximum values need to be less than or equal to the maximum upper level visibility, do you see? Imposing maxima of 60, 50, 40 or whatever at surface level won't destroy the realism from the METAR reports, as they don't give such high visibility values in any case. I find the default maxima quite suitable for UK flying, or possibly a little lower than those -- maybe 30 miles in clear skies, down to 10 when it's overcast and raining. Regards, Pete

One way to see what is going on, which may help, is to enable FSUIPC's IPC read and write logging. Then first use WeatherSet2 (supplied with FSUIPC) to read the weather at a specific ICAOand then do the same with your program. Now just compare the logs for the two actions, this should show you what is wrong. If you need any help interpreting the logs show the extracts and I'll see what I can do. Regards, Pete

I don't think there's necessarily a "problem", as such. The difference in wind direction, from the example you gave, does look likely to be the Mag Var (magnetic variation -- the difference between TRUE north and MAGNETIC North, which varies from place to place). I suspect that the panel makers are showing the wrong one, but it is correct in its own way, just incorrect on the cockpit if the ND is set for Magnetic indications -- which it would normally be. Certainly, you should report this to the panel makers. Such errors were quire prevalent throughout the life of FS2000 and FS2002 too -- I think some were deliberate so that the value shown was the same as the Shift+Z value, but they were errors nonetheless. Regards, Pete

Key press repeating is surely dealt with by the keyboard itself repeating? This is why I provided no repeat options for keys, only for buttons. I'm really not sure why you'd need anything extra, nor how I would program it and avoid the standard keyboard repeats interfering. Can you explain? Regards, Pete

You can't have the throttle+reverser AND speed brakes (spoilers) all on one axis. You can have a throttle axis with part of it calibrated for reverse, but the spoiler axis is always separate. Instructions for setting up a throttle with a reverse section in FSUIPC's Joysticks section are given in the FSUIPC documentation. Basically you go to the main throttle (on the same page as aileron, elevator and rudder), and check the option to map it to the four separate throttles. It is those controls in FS which have a reverse range, you see. Then you go to the 4 throttle page and calibrate the 1st throttle with a reverse range and a dead zone at "centre" which is then your Idle position. Regards, Pete

Okay. I'll find some unused space and map these -- FS2002 and FS2004 only. If I need to access them procedurally (which is normal when I can't locate their storage allocations efficiently or reliably) they won't be updated on every frame, but I presume pretty much any fraction of a second delay won't matter roo much? I'll email you a Beta to check when I do it. Won't be today though, but probably some time this week. Regards, Pete

Oh, right. Yes, I've found the part of the Aircraft Container SDK which allows the definition of (any?) numbers of flap sets. And I've tried it with the 777 in both FS2002 and FS2004. You are right. Odd then that there's no gauge tokens defined for anything but "Left Flaps" and "Right Flaps". I wonder how the panels manage to show these things correctly? I've just found these variables in FS2002's SIM1.DLL TRAILING EDGE FLAPS0 LEFT PERCENT TRAILING EDGE FLAPS0 RIGHT PERCENT TRAILING EDGE FLAPS1 LEFT PERCENT TRAILING EDGE FLAPS1 RIGHT PERCENT LEADING EDGE FLAPS0 LEFT PERCENT LEADING EDGE FLAPS0 RIGHT PERCENT LEADING EDGE FLAPS1 LEFT PERCENT LEADING EDGE FLAPS1 RIGHT PERCENT TRAILING EDGE FLAPS0 LEFT ANGLE TRAILING EDGE FLAPS0 RIGHT ANGLE TRAILING EDGE FLAPS1 LEFT ANGLE TRAILING EDGE FLAPS1 RIGHT ANGLE LEADING EDGE FLAPS0 LEFT ANGLE LEADING EDGE FLAPS0 RIGHT ANGLE LEADING EDGE FLAPS1 LEFT ANGLE LEADING EDGE FLAPS1 RIGHT ANGLE and there are similar ones in FS2004. I can try to map these into FSUIPC's address space and see what they provide. I assume the 0 and 1 sets are inboard and outboard? If not, what? Alternatively, I could try to interfere with the value going to offsets 0BE0 and 0BE4 -- "correct" them according to these other values. Though I'm really not sure how I should combine them all. Currently the offsets 0BE0 and 0BE4 are actually two of the very few still in GLOBALS.DLL and still updated directly by FS, no FSUIPC involvement. This is applicable to FS2002 as well, so how come the first request comes two years late? Very strange. No! Check your arithmetic :) 2910 + E0 (=decimal 224) gets you to 29F0. I don't do silly things like that, honestly. :D Regards, Pete

Sounds like it could be one of two things. 1) The ND implementation is wrong, in that it is showing the direction in degrees TRUE, not MAGNETIC. Assuming you are using FS2004 the Shift+Z display shows the wind in degrees magnetic -- this is different from FS2002 and before where it was shown TRUE. If the difference in direction is the same as the local Mag Var, then that's your answer, and warrants a bug report to the panel makers. The difference in wind speed will be just a rounding thing. One is rounding off the other up. OR 2) The gauge code is actually getting the wrong wind data. I think this is unlikely, but it is possible and would certainly be indicated if the difference in direction was not pretty close to the Mag Var all the time. I should add that neither of these phenomena are related to anything FSUIPC can do. Those panels will be dealing direct with the relevant internals of FS, normally via PANELS.DLL. BTW, it may be that the lack of mag var correction in the ND's is because, in FS2002 and before, the same programmers wanted to make the ND show the same as the Shift+Z display. This would have been wrong, because if the ND is showing MAG directions (track or heading), the wind arrow should, of course, also be Mag -- but maybe when it didn't show the same as Shift+Z folks complained and the programmers gave in! As an aside, I see that FSNav is still showing the wind direction in degrees TRUE as well. Regards, Pete

Not for FS weather, no. I can't get at any of that. I could filter it off if coming from an external program, but really I think it would be better to have that option in the weather program -- after all it would save it a lot of time downloding the stuff in the first place. Really? But surely if it idn't actually downloading winds aloft then the ones it generates won't be conflicting so much? If it does generate upper winds of its own volition I wonder what system it uses? That really is news to me. I have never actually experienced any such wind problems, but then I fly in Europe. I have reproduced them using FLT+WX files from FS downloads, supplied by others -- most noticeable around the Chicago area. I assume that this is down to conflicting reports from different but closely spaced WX stations, possibly derived from different times of day, but I really would have thought that FS's own interpolation would have smoothed these out. Certainly it should be possible to get smoother changes using external weather programs, but this does require pre-processing of the data before sending it to FS. I've suggested various methods to try to Marc, for FSMeteo, but I don't know if he's had time to consider these. Regards, Pete

Sorry, I really don't know. I only provide a window onto what's available. Try using the Monitoring facilities in FSUIPC (see the Logging page) and watching what they do. But I don't think they have worked since FS2002. If you do find out, please let me know and I'll add more data to the Programmer's Guide. I notice that FS2004 has added two new gauge variables: TRAILING_EDGE_FLAPS0_LEFT_ANGLE TRAILING_EDGE_FLAPS0_RIGHT_ANGLE so I could try to locate those and map them for 2A98 and 2AA8, assuming they don't work as they are ... I can't see any reference anywhere at all to Leading Edge flaps. Additionally there seems to be no way to define these in the AIRCRAFT AIR or CFG files, so I can only assume these are only simulated visually on your aircraft and in fact do nothing to the flight. I don't actually have a 767 for FS2004 so I am unble to check this for you. But from everything I can locate to do with FS's handling of flaps internally, for performance all it seems to care about is a flap position "name" and the corresponding effects on performance and limiting speeds. It doesn't appear to distinguish else. Regards, Pete

Okay, got it now -- it's SR2Z PO0O 5L56, I've added it to the list above now. Regards, Pete

Ah, so you didn't set any maximum at ground level for the graduated visibility to start from? It seems daft restricting visibilty to 60 miles at 35,000 yet letting it be completely unlimited at the surface. If you want to get the best from the facility, all the four values in the "maximum" settings should be LESS than your topmost level visibility, else you will get such an odd topsy-turvy effect. Regards, Pete

You have to apply to Customer Services at . I am not involved in this, I don't issue the keys.Regards, Pete

Sorry, I've absolutely no idea. That is surely a question for the IVAO folks. Seems like they have something wrong, doesn't it? Do they have a forum or group where you can ask questions? Maybe someone else here uses Squawkbox and can help you. I don't use it at all I'm afraid. Regards, Pete

I don't think it will. The spike suppression was specifically programmed to get rid of apparent software bugs in certain well-known popular panels -- they seem to deliberately sent maximum deflection controls on occasion. It isn't a hardware thing. If you are getting spikes with the default panels then it is likely to be a bad pot, bad connections, or some sort of interference. >> is there a way to check if the joystick produces a spike out of FS9? That way I can check if the spike is coming from panels (only in fs9) as you say or from the joystick. << If it is doing it in the default panels, then it isn't the panels. If it is frequent enough you should be able to see it in the Windows Game Controllers calibration. Regards, Pete

Your visibility increases as you descend, not decreases? You've not got graduated visibility enabled, then? It should be the other way around. I cannot imagine why you'd want more visiiblity at lower altitudes than higher? When you say "it goes from 5800 to 6000 when the visual change is abrupt", abrupt to what? The difference between 58 miles and 60 miles is not going to be a very visible change, that's a pretty small increase (less than 3%). So if you saw "an abrupt" change of some sort (which way?), and there was no abrupt change in that value, it was definitely forming or dissipating cloud, as I said. Regards, Pete

Sorry, the pics don't seem to arrive. What's the problem? Rather than pictures, wouldn't it be easier to describe it in words. Some folks say pictures can tell more, but I don't think that is always the case :) Pete

That's a thin cloud graphic deliberately laid on the top of the visibility layer (at the upper altitude for this as seen in the Weather dialogues). It was added by MS in response to copmaints with FS2002/2000 that after climbing up out of the fog when looking down the view is perfectly clear, when obviously you should see the haze/fog below, masking or at least fogging the ground somewhat. I assume that since visibility is a video card fogging mechanism, this apparently couldn't simply be applied only to the ground textures, so instead they added this cloud graphic. However, being effectively a cloud, it is only drawn to the distance set by the cloud "view distance" slider (one of the sliders in the Options-Settings-Display-Weather dialogue). For best results, set all the sliders in there to maximum, but beware of lower frame rates then. That's a personal choice. Depends whether you want more varied weather I suppose. Regards, Pete

Hi Daniel, I attach Esound 2.572. Can you try this and let me know? I couldn't find anything wrong, so I recompiled it and tried it here and it seems okay -- if it is okay with you I can only think 2.571 was some sort of mis-compile. Regards, Pete Esound2572.zip

Yes, I have seen this too, but I am pretty sure that this is some cloud phenomenon, even so. At least every example I've seen has been, so far. One way to check. Go to FSUIPC's Logging page and enter the offset "0E78" in the first entry, with a type of "U16". At the bottom select "AdvDisplay". This makes FSUIPC continuously show the value in 0E78 in the FS text display bar on screen. It is this value which FSUIPC uses to manipulate the visibility. The units are hundredths of a statute mile. When it happens, see if the value so displayed is low, matching the apparent visibility. If it is then I'll need to know how to reproduce this so I can deal with it. If it isn't, then what you are seeing is certainly related to cloud formation. As I say, every case I've come across has been down to the latter. Check whether you have the weather dynamics enabled (the slider for changes in the weather menu). If that isn't set to the very left, then you are quite likely to get cloud formation, and it can happen at the aircraft location. I think this is what is happening. Let me know, please, Regards, Pete

I don't know. I'd need some details in order to be able to generate one. I assume this is for FS2002? I think multiplayer has changed in FS2004 and you'd need an update. I don't know if Jose is making one yet. Regards, Pete

That sounds like cloud layers. I cannot, and would not even try to interfere with those. This sudden appearance of clouds at the aircraft has hapened in previous versions of FS, and it certainly also happens in FS2004. In the recent versions of FSUIPC, it works universally, with all weathers. But it is only the visibility. Clouds suddenly appearing or disappearing are totally different. I am not getting involved in that mess. Sorry. Regards, Pete

Yes. That's why I've not updated the "Latest Versions" announcement yet. I post the details when I distribute the ZIPs by Email, then I have to wait for the web site folks to upload them, then I'll update the Release list. Sorry. I expect everyone's enjoying themselves at the AVSIM do this weekend. That's why it's taking longer than usual I expect. Regards. Pete