>> The way I did the comparison [...] > > Your rather elaborate pleadings make me feel that you've been > implementing a rather 'autonomous' (or 'uncontrollable') system for > setting weather effects, which - obviously - is destined to drive > people into a "comparing apples and pears" situation. Simply because a > certain setup is so hard to reproduce.
Sorry, but your characterization of the situation doesn't agree with mine. I don't 'plead', neither to you, nor anyone else in that list. I'm offering you an explanation, as there may be things I have thought of and you haven't. You can do with that explanation anything you like (and for all I care, you can delete the local weather system from your computer). You can also run any comparison you like - but if I give you an explanation of where the difficulties are and you disregard it without good cause, I'll just stop to take your comparison results seriously - that's all that can happen to you though. I'd kindly ask you to read the documentation *before* offering further criticism rather than dismissing my explanations. You can find it here http://www.phy.duke.edu/~trenk/files/README.local_weather.html (or in the /Docs/ folder if you have the GIT package installed). With regard to 'uncontrollable', it is obvious if you think even 5 minutes about implementing local weather that if you want to model the atmospheric conditions as smoothly changing as functions of space and time in an extended region that the number of interpolation points you need for this is staggering. If you were to specify the conditions manually, you'd be entering hundreds of numbers. Which simply isn't useful in practice. Until recent modifications by Torsten, using METAR hasn't been possible. Furthermore, METAR info is anything but complete to characterize conditions. So designing an autonomous offline weather system is about the only viable solution. If you want to control it precisely, you can still do it on the Nasal level. There's just no menu option or property to do so, because (unless you want to compare) there's no use for such an option - you can always manually determine weather conditions by using the standard global weather settings, so I see no need to reproduce that in the local weather menu. > Mmmmh, a multitude of parameters which are having effects on the > situation are easily set via properties and can thus be reliably > reproduced from command line. Local weather writes a new set of conditions every second, giving you a smooth change in visibility as you get higher or a smooth change in pressure as you fly from a high pressure region to a low pressure region. Whatever you specify in the comand line will be obsolete as soon as the interpolation loop starts getting weather conditions. That's why it is called *local* weather - because weather parameters are not globally valid but a function of space and time. > This includes but is not limited to > date, timeofday, METAR, visibility and all the nifty stuff which > controls the environment. At least this is what I've learned to be the > FlightGear way of providing a test case. Yes, it's rather obvious that this doesn't work when you want to compare two different systems which are both supposed to control the environment in different ways. If you think about it for a while. It works when you want to provide a standard environment for anything else within that environment. Cheers, * Thorsten ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
