@HHS:
Just using "Local Weather" and defining some values like Convective System freezes FGFS.
I get an error message: nil used in numeric context local_weather.nas, line 967 called from local_weather.nas, line 1141, called from gui/bindings[31] line 1
The freeze for a certain period of time is (sort of) normal - the setup calls are all done in a single frame - which may take forever to execute. In tests, I had times ~minute freeze to set up 500 barrier clouds in a tricky situation. I'll soonish work on moving these calls to worker threads outside the simulation frames, I believe this will solve the freeze problem.
As for the error - can you give me details what you did? Line 967 would place a rain model within a layer call, but that wouldn't be executed from the convective system. It has the potential to cause the error if you ask for a cloud of which the size is not in the hash map - I have to fix that - but it should not be executed when using the convective system.
Now there are only some small stutterings: every two seconds FGFS hangs for a very short time. Maybe the limit of Nasal is just reached... ?
Hm, I have the effect volume loop timed to run every second and the interpolation loop every 3 seconds, so there is nothing which could have a 2 second period... I have seen the Nasal loops causing a brief delay every interval with the characteristic frequency of their timing - but these loops had vastly higher workload (trigonometry for 500 clouds). So if it's really two seconds, I simply don't know, and I don't see it on my system.
If you want to check, set
local-weather/effect-loop-flag and
local-weather/interpolation-loop-flag both to zero (that should stop the loops) and see if the problem disappears.
I can readily imagine that the infight between the interpolation and real-weather-fetch who gets to set the weather causes performance issues...
@WooT:
Maybe something that needs refinement too, is the way the closest cumulus are drawn / rotated. When spiraling under the cloud, it rotates in a way that would make one dizzy quickly !
I hadn't thought about that...
Of course when soaring, you'd see the clouds from where the trafo breaks down quite frequently... You'd get the same problem with the standard 3d clouds (same trafo). The problem is, one cannot simply 'freeze' the cloud beyond some distance, because the shader doesn't really rotate the model, just its appearance, so if you stop the trafo beyond a distance, the model just snaps back to a default state. I have to think about this a while, I don't see a quick fix.