I've today changed the runway selection behavior. In the past, runway 28R was pre-selected in preferences.xml, and a heading of 270 was hard-coded in options.xml.
So, if you started from another airport, fgfs first checked for a runway 28R, and if there was none, chose the runway with heading closest to 270. This was totally independent of the wind, and often one was dropped on a silly grass stripe because that one matched the required heading a little better than a perfect concrete runway in almost the same direction, or even parallel. (e.g. in LOXZ, LOWL) Now the algorithm works like this: - check if a runway was defined on the command line, and if so, take this runway; otherwise ... - check if there was a heading defined, or if none was defined, take the wind-from direction, and ... - search for the best runway matching this direction, whereby longer/wider runways and such with better surface are preferred, even if they are a bit farther off the desired heading The last point is done with weighting factors, which are for now configurable in the property tree and might need some more adjustment. Please check problem cases and report any unwanted behavior. Unfortunately, wind is only considered when set via --wind option. The live-METAR wind comes too late for this phase, and we still have to find a solution for that. m. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
