Re: [Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim

2012-04-26 Thread Renk Thorsten
> 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 th

Re: [Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim

2012-04-25 Thread ThorstenB
Am 25.04.2012 12:50, schrieb Renk Thorsten:
>> From my perspective, switching between GUIs runtime and trying to
>> mix features is problematic input in the first place. My

Agreed. And I don't think it was the intention of the current GUI to 
toggle between both dialogs, while keeping advanced (or basic) weather 
enabled.

However, I'm not too happy with the current way of switching between the 
weather systems in general: I don't think "normally advanced" users 
understand the concept. This bug report/feature request (i.e. show METAR 
in basic weather dialog when advanced weather is enabled) shows the 
issue: users think they are toggling between a basic and an advanced 
_dialog_ (likely surprised by the "basic dialog" looking a lot more 
complex than the "advanced dialog" though). It's easy to miss that this 
actually switches between two completely different features: the basic 
vs advanced _weather system_ - in the same way as they can switch 
between 2D and 3D clouds.

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").

>> inclination is if this needs to be hardened against problematic
>> input  to treat the usage of the '->  Basic Weather' button as
>> intention to leave Advanced Weather and just add a call to
>> local_weather.clear_all(); to the code of the button which ends
>> Advanced Weather when ending its GUI. That would leave Basic
>> Weather still in disabled state though, so to go beyond I would
>> need to save the state of Basic Weather at startup of Advanced
>> Weather and write these parameters back when ending it.

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.

> But where should the METAR string be? My idea was that you can get it
> in-sim via the radio, or if you want to cheat there's always the
> property browser to look it up. Displaying it on the Advanced Weather
> GUI as well is also not really a problem if that's what people think
> should be done. Any opinions?

Users (like me! :) ) probably want to see the METAR string in some 
dialog - not just in a property.

I'd suggest to display METAR also in the advanced weather dialog.

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.

Torsten(D) really needs to comment though...

>> Also, after selecting 'Advanced Weather' then Shift-Esc restarting,
>> clouds flash repeatedly and then segfaults .. only when Shift-Esc
>> after selecting Advanced wetather
> Well, yes - a restart implicitly starts up Basic Weather again
> without terminating Advanced Weather and results in a fight between
> systems.

Ok, so that's what's causing it. Once advanced weather is running, basic 
weather should stay disabled - even if the user resets/relocates. The 
issue might be a result of our generic method resetting all properties 
to their initial value on sim reset. We need to explicitly protect 
(exclude) those properties, which should not be affected (enable the 
properties' "preserve" flags).

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 
;-) ).

> Again, probably the best solution is to end Advanced Weather for good
> on restart (if anyone can tell me what property to tie the listener
> to?) because it's impossible to guess the cause for the restart - a
> restart at the same location would allow to keep the whole calculated
> cloud configuration and just leave it running and not restart Basic
> Weather, a restart at a different location however needs a lot of
> re-computation.

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. Similar to switching between 2D or 3D clouds - you 
don't want to loose your selection on reset.

Anyhow, you should tie a listener to
/sim/signals/fdm-initialized
This triggers on _every_ FDM reset, which is when the aircraft "knows" 
its new position. You could use this to disable advanced weather - 
though I'd prefer if you used it to reset and adapt the advanced weather 
system to the new location, while we sort out how to keep bas

[Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim

2012-04-25 Thread Renk Thorsten

Hooray alerted me to that one, and I would like to ask a few opinions on what 
to do and offer my own thoughts.

> *What steps will reproduce the problem?*
> 1.F10-Environment-Weather-Advanced Weather
> 2.Select METAR
> 3.Return to Basic weather

> *What is the expected output? What do you see instead?*
> Should still  be able to see METAR string for information, it's now showing 
> 'Disabled'  

>From my perspective, switching between GUIs runtime and trying to mix features 
>is problematic input in the first place. My inclination is if this needs to be 
>hardened against problematic input  to treat the usage of the '-> Basic 
>Weather' button as intention to leave Advanced Weather and just add a call to 
>local_weather.clear_all(); to the code of the button which ends Advanced 
>Weather when ending its GUI. That would leave Basic Weather still in disabled 
>state though, so to go beyond I would need to save the state of Basic Weather 
>at startup of Advanced Weather and write these parameters back when ending it. 

But where should the METAR string be? My idea was that you can get it in-sim 
via the radio, or if you want to cheat there's always the property browser to 
look it up. Displaying it on the Advanced Weather GUI as well is also not 
really a problem if that's what people think should be done. Any opinions?

> Also, after selecting 'Advanced Weather' then Shift-Esc restarting, clouds 
> flash 
> repeatedly and then segfaults .. only when Shift-Esc after selecting Advanced 
> wetather

Well, yes - a restart implicitly starts up Basic Weather again without 
terminating Advanced Weather and results in a fight between systems. 

Again, probably the best solution is to end Advanced Weather for good on 
restart (if anyone can tell me what property to tie the listener to?) because 
it's impossible to guess the cause for the restart - a restart at the same 
location would allow to keep the whole calculated cloud configuration and just 
leave it running and not restart Basic Weather, a restart at a different 
location however needs a lot of re-computation.

A problem in practice might be that Advanced Weather has some long-running 
loops with a timer of ~ 5 sec for things which only need to be checked now and 
then, so it doesn't die immediately, the loops expire only after they've been 
called one more time. Also, repeated 'add-cloud()' calls are apparently 
buffered and continue to be executed even after stopping the whole Nasal code.  

> To get the segfault I have to select Metar Live Data as above, go to Advanced 
> Weather, select OK
> twice, get the message about Advanced Weather already enabled, select 
> Clear/End, then 
> re-open advanced weather and select OK.

I just tried that one, but I didn't get the segfault, the system behaved as 
expected for me. I suspect there may be a timing issue involved - clouds from 
the previous call are still buffered somewhere and not yet in the scene, only 
clouds which are in the scene are deleted when the clear_all is executed, 
deleting clouds also isn't instantaneous, new clouds from the next call arrive 
with overlapping parameters - so I'd be interested if this occurs dependent on 
the coverage (I had a METAR with very few clouds) and if it depends on METAR at 
all and if it helps to wait 10 seconds between every operation. I do know that 
if I try hard, I can click the GUI faster than the system can add and remove 
clouds and produce inconsistent configurations.

All in all, I suspect that one may have more to do with the internal structure 
of add-cloud and remove-cloud than with the Nasal part of the operation.

* 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