Pete Dowson

Hmm. Seems to confirm that the problem is due to the superfluous multiple wind and temperature layers, as the only real difference left is the rather stricter layer elimination used in 4.256. Thanks for these tests! It has been very useful. I think I know what defaults to use now -- did you notice any particular frame rate difference with any of these settings, BTW? Best Regards Pete

At which stage is your compiler converting the integer in "deger" to floating point? If this is AFTER the multiplication by 360 you are likely to lose most of the value though overflow! Try rDeger = deger; // Convert to floating ponit rDeger = (rDeger * 360.0) / (65536.0 * 65536.0); // convert to degrees Pete

Yes, ok! Thanks, Pete

I assume you have "OwnWeatherChanges=Yes"? Otherwise the test doesn't mean much. That would be okay unless you switched "allow changes to FS weather" off to have a 'fun' flight. Yes, please. I need to know whether it is just the time allowed to "phase in", or the frequency, or because I'm being more ruthless discarding extra layers. You can't really because you can't make it less aggressive in removing layers. With the WeatherReWriteSeconds at 10 and the WeatherReadFactor at 2 you otherwise have 4.255. Best Regards Pete

Depends on the aircraft -- the battery use varies, and of course it also depends how much stuff you've got switched on. There's an APU in FSX (wasn't in FS9) but I don't know if it works [-- you'd have to switch it on though, even it it is in the model you use. I use the pmSystems one. Some of the better add-on aircraft have one. Alternatively leave most things turned off till you are ready to start an engine and its generator. Pete

Sounds like your battery is running down. Have you got the engine(s) running and generator/alternator switched on? Or else got the APU running (if you are using PMsystems). If you don't want the battery to run down and haven't got the facilities to get power in time, look at using the "magic battery" facilities in FSUIPC (Miscellaneous page). Most of the things you ask here are PM related and you should be dealing with PM support. The MCP question was another one in point. I did say I'd see if I could corroborate it, but I've run out of time now till late March. Sorry. Pete

Correct. The main problem really is that the dialogues are "modal" -- that is, nothing else in the same process is being run when you are in a dialogue. The simulation is stopped, as is FSUIPC and everything else in FS. It really is a common thing to happen in most Windows programs. Those which do have activities continuing are using multi-threading and have taken special steps to get continued message processing. For most dialogues that makes sense when you think about what they tend to be for -- changing FS's video settings whilst the video actions are still happening would be a nonsense, for instance. Unless there are dialogue shortcuts available (often with the ALT key), dialogue buttons are often only usable with TAB to move from one to another, then Enter or something to action them. Regards Pete

Sorry, FSUIPC doesn't implement any of the FS controls 65536 onwards. It simply lists those that are tabulated in FS's "CONTROLS.DLL". These are also the same as the "KEY EVENTS" listed in the Gauge development SDK and assignable to buttons and keypresses in FS's CFG files as well as via FSUIPC. Whether they actually work or do anything is often questionable -- the only way to see is to try them. Many were invented back in FS98 days and quietly forgotten in later versions, and I suspect some were never actually implemented. If you know how to do it from keyboard or button in FS directly, then you can use FSUIPC's Logging to see what FS Control is being used, if any. Just enable Event logging and read the control name and number in the FSUIPC Log. That said, which "map" are you talking about? If this is the one in the Dialogue, showing the aircraft route, VORs, ATC zones etc? Or do you mean the top-down type view? If it is in the Dialogue then I'm afraid none of the FS controls apply to menu modes -- nothing of the simulation side is really active then, it is paused. You also really do need to state FS version as these things may change. Regards Pete

Go to http://www.schiratti.com/dowson. Click on the FSUIPC.ZIP labelled version 3.75 (scroll down abit -- it is under the "FS2004" heading). When it has downloaded, open up the Zip and read the User Guide you'll find inside, or at least the first few pages. Pete

By "as is" I mean exactly as you have it which you know causes the super fog. Obviously I am trying to make it work, so it needs testing in conditions you know causes the fog! For the first test, as it says, I wanted those left alone, to "default". That's what I meant by "as is". Sorry for my brevity. The other settings are additional tests, as it says -- small changes in those parameters, to see what effect they may have. I have two more small tricks up my sleeve. After that I must give up till late March as I'm running out of time before my holiday (visiting son in Spain). Pete

3.71 is too old and not supported in any case. The oldest supported version is 3.75. If it is satoisfactory why do you want to buy it? Go to SimMarket and search on FSUIPC. You'll soon find the sales page. Pete

You write the number corresponding to the FS control you want to execute to 3110, exactly as it says in the Programmers guide. The flight reset control is called "Situation reset" (flights used to be called situations, or .STN files). Pete

Not sure why you are asking here, still .. I have nothing to do with "VAFS", and in fact don't know what it is even. I thought you were just explaining a mistake you made asking about FSUIPC? Pete

Presumably a bad download then? Pete

No ideatell me exactly what they say. Which FSUIPC? Whick FS? Pete

Good. That's the second "good news only" message in one day! That beats all known records! ;-) Thank you! Pete

I'll cross-check here, hang on ... ... Oh, yes, you are right. How odd. Not sure when that crept in. I'll fix that for the next update, maybe over the weekend. Thank you! Did you actually get something in the visibility tab working? I've been struggling for months to control visibility, and all that stuff is so unpredictable I thought it was rather unfair on the user providing a tab which promises much yet doesn't deliver. What did you find worked? What weather source are you using? How did you do it? Did you download 4.256 without reading any of the Release notes for it? You should surely have seen this section: But please tell me all about what you got working properly and how! Regards Pete

The installation of FSUIPC is only "FSUIPC.DLL" sited in the FS Modules folder, so it isn't a big deal either way. You deleted the KEY file? No backup? I do advise you to backup your KEY file in the User Guide. If you are re-registering you must get all three parts exactly correct -- exactly as they were when you bought the Key, not necessarily as they are now. If you cannot remember the details, you may need to open your account at SimMarket to retrieve them. Regards Pete

Well, not quite, but I have done a lot more investigation today, and I am convinced that this "super-fog" is brought about by corruption in FSX's internal weather tables by the furious generation of multiple spurious wind and temperature gauges when it is interpolating and developing weather changes. I still have not generated your "super-fog" which obscures everything, even the virtual cockpit gauges (i.e. a true zero visibility), but I have managed to get "ZERO VIS" reports generated in the Log for surrounding WX stations, and a couple of times it has affected the weather at the aircraft -- down to 16 metres, though, not zero. I could still read the VC gauges and see vague building shadows in the gloom. Maybe the real zero you get is related also to the video driver's rendition. Anyway, it certainly seems to be harder to make happen if I speed up the spurious layer removal, and make it more severe. So this is what I've done, by default, in version 4.256, now downloadable. There are several tests you can make with that -- please see the Release notes in the Announcement. I'm expecting this to fail too, by the way. Well, I'm hoping it won't, but my hopes aren't too high. I have two more options I've thought of, to work out and build in, but I need to know the results of this first. The only remaining options would tend to lessen the abilities of FSUIPC to provide the weather filters it currently does. For instance, one would be for FSUIPC to detect "custom weather mode" -- i.e. weather controlled by an external SimConnect program, or by the user via the weather dialogues -- and butt out completely when this is happening. Best Regards Pete

Weird. Thanks for letting us know! Pete

Greatnice to read good news once in a while! Thanks! Pete

Sounds like a typical video driver bug -- either switch to Windowed mode (ALT + ENTER), which generally works much better with FS in any case, or look for a better video driver. This really isn't a function of FSUIPC and it has no control over Windows displays. Regards Pete

Please tell me which FSUIPC version you are using. All of the weather features have been undergoing a lot of changes since Christmas. If you are not using it, try the current interim release, 4.255 from the FSX downloads Announcement above. Please never post a report or question about any of my programs without also saying which version number you are using. Regards Pete

It isn't related to what's in the libraries. It's the difference between running in the same process as FS, or running in a separate process and so facing process switches for each information exchange. If you think about that you could expect faster response times with an internal gauge or DLL than with an external EXE -- after all the latter has to post a message onto the FS message queue, wait for it to be processed and answered. All that is internal for a DLL or Gauge (but the library still uses messaging to avoid problems with FS's threading). However, writing a DLL or EXE isn't the best course necessarily, for two good reasons: 1. A program running internally in the FS process must take great care to avoid performance degradation, pauses, jerks and so on in the simulation. It has to be designed specifically to run cooperatively with FS in all its facets. With an external program you leave time sharing worries to the operating system. 2. By making it a DLL or Gauge it cannot be run on a separate PC across a Network via WideFS, so wasting one of the valuable ways of off-loading work from the FS PC. By the way, never use the external library for a DLL or Gauge. Although it may seem to work, it is very inefficient (using memory-mapped files for inter-process communication within one process) and is dangerous because the memory-mapped file identification process uses the Process ID, which of course is the FS Process ID, and therefore may not be unique. Regards Pete

Er, sorry, what do you mean? FSUIPC only runs internally to FS. Pete