[Flightgear-devel] reality issues in MP, Was: Flying at/for LinuxTag (fwd)

[Joacim P. <no...@tu...>]

Looks like my sendmail was feeling ill today (DNS deficiency) and needed a 
cuddle and a restart. Second attempt:

On Sat, 2 Jun 2007, Torsten Dreyer wrote:

> http://www.t3r.de/fg/lt2007/dragonfly_an225.jpg

Was that me in the 225? ;) I did take off with it from EDDI/09L on Friday.
(Didn't notice an ultralight being sucked up by engine #5 though)

Anyway, look at the wind strut. It looks as if the 225 was lining up to
take off in a tail wind. And this brings up the issue of MP and reality:

The metar weather for EDDI on Friday was wind from 50 degrees, and the
default FG weather is 270 degrees. Some pilots where using runways 27L and
27R and others where using 09L and 09R, depending on if they had enabled
METAR weather or were using the default wind from the west. (Or perhaps
didn't care if they had headwind or tailwind?)

I've nagged about this on IRC from time to time: IMO, using
--enable-real-weather-fetch/METAR ought to be mandatory in combination with
MP. Or in the least to use the one and same weather. (There is perhaps the
possibility to consider that someone rigs up an MP server on an isolated
LAN, without having access to an online metar service, or don't want that
weather for some reason.)

So how about a default logic of enabling real-weather-fetch automatically if
--multiplay is used, unless an explicit --disable-real-weather-fetch is
set?

And as others may or may not have noticed, using
--enable-real-weather-fetch does not set the menu/dialogue option
"Weather->Weather Scenario->Weather source" to "METAR". There appears to be a
difference; not in wind but in cloud layers.

Maybe a few other reality options should be maintained in MP mode too,
like --timeofday=real, --time-match-real? ...disabling the "pause" and
"speedup" functions perhaps?