Re: [Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim
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
[Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim
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
Re: [Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim
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 basic weather disabled. I just tried that one, but I didn't get the
