On my transoceanic flights after METAR changes I observed many Nasal bugs like this one :Nasal runtime error : Undefined symbol : cs at /usr/share/games/flightgear/Nasal/local_weather/compat_layer.nas line 560

Variable cs is defined only if buffer_flag=1, but when I monitoring this flag in property browser for local_weather/config/buffer_flag, I never see other value than zero. Result is clear - no clouds at the scene after runtime error. Can someone deeply analyze that error ?I have solution - move var cs=.... before line with if (buffer_flag == 1), but I'm not sure with other consequences.

This looks like inside legacy code - so the relevant question is how the problem is triggered in the first place? I've done a number of tests in METAR mode and never seen it (and to my knowledge most people fly with METAR mode and I've not seen other reports either).

from the bit of code posted, it would appear that the buffer_flag should be on... the question is what setting(s) turns it on?

"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up.""Why not?" said Gurder."Dunno. It's frightened of heights, I guess."

5 minutes ago I found another bug vector index -1 out of bound in the file weather_tile_management.nas at line 1488 :

var s = cloudShadowArray[index_min];

But index_min is initiated with value -1 and when in the scene doesn't exist any cloud with shadow, value is always zero. This bug has been initiated with manual weather type from Fair weather to Stormy monday.

I manualy changed local_weather/config/buffer-flag from false to true, restarted FG and this property was true. Why was false, I don't know.Then checked second PC with fresh installed Lubuntu 18.10 and FG 2018.2.2, property was true after FG started. On third PC I found same behaviour - property was allways true.

Is there any reason to some aircraft should modify that property ? I tested many aircrafts from many sources other than fgaddon.

the error "Undefined symbol : cs " was not repeated again under any circumstances. Problem "vector index -1 out of bound in the file weather_tile_management.nas at line 1488" solved as described in viewtopic.php?p=338439#p338439.

Is there any reason to some aircraft should modify that property ? I tested many aircrafts from many sources other than fgaddon.

There's really only two possibilities to set this: Manually with the property browser (I suppose since the flag is a boolean it could potentially be clicked by mistake by a super-user who delves into AW inner workings) - but it seems hard to do this without being aware that manual modifications are being done to the AW state.

Or via a setprop. The only pieces of code that should legitimately write into the AW property tree are the AW subroutines and the AW GUI - nothing else inside FG should write there. The GUI option is, as I said, disabled (and has been for many years), and AW Nasal does not write this.

A malicious aircraft on the other hand (for whatever reason) could set this - the huge configurability FG offers unfortunately means that simply using an aircraft can wreck the configuration of your existing FG install for good. FG is protected to the degree that such operations are fairly restricted and simply wiping your user-side config files should take care of things - but it is a possible scenario that someone with insight into FGs workings offers an aircraft that intentionally (or by mistake) causes such problems - you just need to run the aircraft once and then delete it in this case and your config would already be faulty.

But index_min is initiated with value -1 and when in the scene doesn't exist any cloud with shadow, value is always zero. This bug has been initiated with manual weather type from Fair weather to Stormy monday.

I'm unable to reproduce this - for me changing from Fair weather to Stormy Monday works fine. So I need a recipe to reproduce this, not hacks to conditions.

variable grad is defined localy in the procedure create_cumulus, but error occured in the other procedure recreate_cumulus where grad is not defined...

Early morning programmers warmup - this doesn't matter because the routine in question is an experimental, six-year old code path which is disabled by default and can't be enabled in the GUI - you have to manually edit a config file or use the property browser to activate it, and if you opt to do so, it's kind of your own problem to deal with the consequences.

Please do not do super-user type things with the AW config and report them as bugs.