#2486 Manual weather completely broken.

I had to force some weather for testing, and it turns out manual weather is completely broken, at least on next.

Issue 1. Detailed weather does not completely go away and breaks Rain and Snow sliders until restart.

1. Go to Weather settings, enable Detailed weather. Press "OK".
2. Open the dialog again. Switch to Basic Weather and turn on Manual configuration, then open "Manual configuration..." and drag Rain or Snow slider all the way to the right. See precipitation appear.
3. Close the manual dialog
   4.
4. Press "Apply" in the main weather dialog. Precipitation disappears, when opening the Manual configuration again both sliders are off.
5. If you press "Close" in the main dialog instead, it will work as intended.

Issue 2. --metar no longer respected, neither if also setting --disable-weather-fetch or even forcing --prop:/environment/weather-scenario="Manual input". For example try this METAR: --metar="XXXX 000000Z 00000MPS 1000 +SHSN OVC010 M10/M11 Q1013" it will not work unless you open the dialog and type it each time.

[James Turner]

Is this about 2020.3 or next or both? And how about 2018? Basically I'm trying to understand when this changed/broke.

[Anonymous]

next as of 2020-12-22. I will check other versions to see if they are broken

[Anonymous]

Please cherry-pick 39d616a0 (building fix for Boost >=1.75) because they won't build unless I locally cherry-pick

[Anonymous]

Both issues exist on all 2020.x branches. I can not test 2018.3 because it won't build anymore because of Boost 1.75, and the fix is not cherry-pickable to there.

[James Turner]

Thanks for the update, that helps somewhat.

[Anonymous]

Looks like I managed to make 2018.3 build: while cherry-picking that commit does not work, manually changing PathSplitIterator itr to auto itr works.

[Anonymous]

Strange, but 2018.3 is broken too. But I remember it working in at least 2020.2...

[James Turner]

That sounds really weird, 2020.2 and 2020.3 should be the same, at least no changes were made in this area on purpose. We should ask some more people to test and confirm, becuase we might be chasing this issue from a mixed-up direction.

[legoboyvdlp]

Issue 2 might well be simply the launcher not considering a manual METAR case passed through "additional settings". You can also pass manual METAR through the Environment tab --> manual input. But it probably should respect the additional settings tab selection (detect it and override the selection on the environment tab perhaps, just like it does for locations)?

[Anonymous]

But I was launching FG from command line?

[Anonymous]

Both issues are there on 2020.3 and 2020.2 as well.

In case of Issue 2, the only thing that works is putting METAR string in the launcher. It never works from command line. So there is absolutely no way to spawn FG from command-line with predefined weather for quick weather testing.

[Anonymous]

I have just fixed Issue 1, it turned out to be not Local Weather itself but the dialog repeatedly cleaning up Local Weather outputs that it has already cleaned up. So only Issue 2 remains now.

[Anonymous]

Issue 2 is not present in the launcher is because it is setting many more arguments than just --metar in order for it to work:

Basic Weather:

--prop:/nasal/local_weather/enabled=false
--metar=XXXX 000000Z 00000MPS 1000 +SHSN OVC010 M10/M11 Q1013
--prop:/environment/weather-scenario=Manual input

Advanced Weather:

--prop:/nasal/local_weather/enabled=true
--prop:/sim/gui/dialogs/metar/mode/global-weather=false
--prop:/sim/gui/dialogs/metar/mode/local-weather=true
--prop:/sim/gui/dialogs/metar/mode/manual-weather=true
--metar=XXXX 000000Z 00000MPS 1000 +SHSN OVC010 M10/M11 Q1013
--prop:/environment/weather-scenario=Manual input
--prop:/local-weather/tmp/tile-management=METAR
--prop:/local-weather/tmp/tile-type=manual

To make things weirder, it only works when I paste them to ~/.fgfsrc, and simply putting them on command line (with necessary quotation of metar and scenario strings) does not.

Would it be possible instead of requiring so many properties to be set, to:

1. add an argument like --{enable,disable}-local-weather that selects the weather engine and updates the weather dialog properties;
2. make --metar also set Manual input weather scenario and in case of Local Weather also set tile properties?

[Anonymous]

James forwarded me a ML thread which is likely related to Issue 2 here, saving it here for completeness.

Hi Michael, this issue ‘arrived’ while you were away, I didn’t have time to investigate it further so far, and I think you have been looking at nearby code.
Basically when selecting a weather scenario in the launcher, and using local weather, the ocmmand looks okay (Benedike and I think, anyway) but until you go into the in-sim weather dialog and click ‘Apply’, things don’t seem to start correctly.
And it’s not even so clear: some of the scenario settings seem to work, but not all. There was a little bit of Nasal ugly-ness to make local weather start immediately when the launcher tells it (Nasal/local_weather_auto_init.nas) so maybe something has screwed up there.
If you have any idea, I would take it :D
Kind regards,
James

Begin forwarded message:

From: Benedikt Hallinger
Subject: Re: [Flightgear-devel] Launcher weather selection does not switch anymore?
Date: 24 June 2021 at 15:46:23 BST
To: James Turner
Cc: FG Developers List

Yes, James, that's what i observe too!

Am 2021-06-24 16:22, schrieb James Turner:

On 21 Jun 2021, at 12:17, Benedikt Hallinger
wrote:
I was just guessing from the produced command line you can display
with the launcher.
The generated Metar does hit flightgear, however it seems it does
not honor it.
Can you reproduce?
Just checked, and for me the METAR string passed, is show in the
‘weather’ dialog box.
But indeed only some settings seem to be picked up, I need to click
‘Apply’ in that dialog to get the rest to take effect. Is that
consistent with what you observe?
Assuming it is, we probably should do some bi-secting to work out when
it broke.
Kind regards,
James