On 05/24/2009 02:58 AM, Torsten Dreyer wrote in part: > Step #2 > Add an option --metar=<arbitrary handcoded METAR> > - this implies --disable-real-weather-fetch and set scenario to METAR > - make the metar string editable in the weather_scenario dialog > This option needs some changes in the logic of real-weather-fetch and > scenario > usage. > > Ideas and comments are welcome. If I play in someone elses sandbox here, > please complain!
As the saying goes, it's hard to make anything foolproof, because fools are so ingenious. Let's consider the following scenario: Suppose some ingenious user specifies --metar="$whatever" --enable-real-weather-fetch in that order. Things get innnnteresting because Torsten's code uses the metar/data variable for one purpose, and ties a Nasal listener to it ... while Erik's code uses the same metar/data variable for another purpose, and ties some c++ functions to it. This can't be good. Error messages are generated, but not the sort that typical users will benefit from. Possibly constructive suggestion: Rather than have one variable with two incompatible uses, why not have two variables. Rather than metar/data we could have metar/text or metar/manual (for the text of the manually-entered metar) metar/site or metar/id (for the ICAO identifier of the metar source) A split like this would make the code more understandable and more maintainable. Another suggestion: If the --metar and --real-weather-fetch options really are incompatible, this ought to be mentioned in the user documentation, not just in some email in the archive. And there should be runtime checks that enforce the requirement, -- no matter the order in which the options are specified -- and misuse should result in user-friendly warnings. OTOH it's not entirely obvious to me that these options are irredeemably incompatible. I can imagine switching in and out of manual mode at runtime, with metar/manual be actively used during manual mode, and being only a standby otherwise. In any case, the documentation for --metar would benefit from an _example_ of its proper use. As the saying goes, an ounce of example beats a ton of BNF. I believe --metar="XXXX 012345Z 00000KT 99SM CLR 59/M01 A2992" is a correct and useful example ... but somebody should double check. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
