> So, maybe we could find a better method of switching between the weather
> systems - though this isn't the main issue here. Using radio buttons or
> a drop-down list would be a more standard way to toggle between
> alternatives. Otherwise, just updating (and maybe moving) the button
> descriptions might already help (something like "enable advanced weather
> system" rather than just ">> advanced weather", and "disable ..." rather
> than ">> basic weather").
I guess more generally this requires some brainstorming just where we want to
go with the weather systems. The idea to merge some features has been around
for a while, but I'm still in the dark how to do this in detail.
For instance, both systems could share an aloft wind dialog. Both systems could
share a METAR dialog. In principle, Advanced Weather could be made to parse a
dialog which allows to manually set cloud layers (and to some degree even
cloud type in the layer) like in the Basic Weather case. Basic Weather could be
run based on the offline weather model of Advanced Weather - you'd lose the
transition between tiles, but the weather would change in a reasonable way even
without METAR input. And so on.
I'd basically like to know what of this is desirable - do people want to have
more control over cloud layers in Advanced Weather? Pro - you can control
clouds. Con - for realistic appearance, lots of other parameters (haze, light
attenuation, Mie factor of the skydome,...) need to be changed in sync with the
clouds and the virtue of an integrated weather system is that you don't need to
think about this. And so on. I basically know what I'd like to have (and that
tends to get coded), but I am a little in the dark what others would like to be
able to control in a weather system (also, one has to be careful that the GUI
doesn't get out of hand - Advanced Weather has so many internal parameters
which one could *potentially* expose that we could fill two or three
screen-sized dialogs with them...).
For the time being, perhaps renaming the buttons is the best solution.
> With the current GUI concept, I'd expect "advanced weather" to be
> disabled and "basic weather" to be enabled when I switch back from
> advanced to basic weather dialog. So adding your call to disable (and
> maybe another to properly enable basic weather) makes sense.
Will do. After all, it's a single listener which can be removed easily if
needed.
> Or, maybe we can move METAR to a completely separate dialog (independent
> of advanced/basic weather). This would also shrink the basic weather
> dialog considerably (it's huge! ;-) ). And we could still add a tiny
> button to open the METAR dialog from the weather dialog(s). And we could
> have a "METAR" main menu item.
I think I would perfer this solution, because internally METAR fetching and
parsing is also decoupled from using the information (cf.
/environment/params/metar-updates-environment). So you could get a METAR, have
it parsed and decide if you want to really fly it or not.
> Torsten(D) really needs to comment though...
Yes.
> Which properties exactly enable basic weather? Again, I guess Torsten(D)
> should know (I'll give a bump shortly, unless he's reading this anyway
> ;-) ).
The interesting parameters for weather as such are
/environment/config/enabled determines if Basic Weather is active or not
/environment/params/metar-updates-environment determines if parsed METAR info
is used or not
Relevant to avoid overlapping clouds between systems are
/sim/rendering/clouds3d-wrap determines if cloud layers are wrapped (Basic
Weather) or computed cloud by cloud (Advanced Weather)
/environment/clouds/layer[0]/elevation-ft is the location of the lowest layer -
since Advanced Weather manages cloud altitudes by cloud and not by layer, this
is always set to zero when Advanced Weather is on, but it should be reset if
Basic Weather comes on
/environment/clouds/layer[i]/coverage-type needs to be 5 to prevent
layer-defined clouds from being shown while Advanced Weather is running
/environment/clouds/layer[i]/coverage should be 'clear'
> I'm not sure whether that's the expected behaviour. Someone who opts to
> advanced weather probably wants to keep using it - even when he's
> resetting/relocating.
Yes, but that's not trivial to achieve technically because you need to
distinguish rest without relocation from reset with relocation and you need to
get timing right.
Reset for the same location is not problematic - the system can be kept running
and as long as the Basic Weather parameters above are not touched, everythig is
fine.
Relocation has the problem that the tile manager has been written under the
assumption that you move continuously with a sane velocity ('sane' is tested up
to Mach 5, i.e. what I got out of the X-15). If you start up in San Francisco
and relocate to Denver and the tile manager keeps running, it will keep all
weather in San Francisco. It will correctly deduce that you are now east of the
original location, so it will start to build new tiles just east of KSFO. At
the same time, it will conclude that you are more than the tile unload distance
away from all weather and trigger removal of everything. What it will not do is
assume that you jumped location and start building there (which would also be
wrong, because it still has all terrain information from the previous location,
and since San Francisco is essentially at zero altitude and Denver is a mile
high, this will be a terrible mismatch...).
So in this case, what we really want to do is end the system and restart it -
which is reasonably fast now. But this requires to compare position before and
after the restart and make a decision based on a distance cut. There may also
be more subtle issues having to do with timing of 5 second interval loops and
so on.
I think if someone can prevent Basic Weather from being switched on for a
restart, I *should* be able to make it work if we want to go that path.
> And maybe you could
> add a comment on the bug tracker, so I could add your account as a
> contributor - which would be handy. We could directly notify you about
> any advanced weather-related issues then - just in case there ever were
> any! ;-)
Hm, seems one needs a google account for this - frankly, I'm not too
comfortable with google...
* Thorsten
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
