The current local METAR based weather system is not really good on either scale - it sets the weather everywhere around the aircraft to the weather parsed from the METAR.
Yes, weather in FlightGear is inevitably "glocal" weather, so no matter where you go - the weather will be the one that you configured previously.
This is of course pretty powerful in that you can easily change the surrounding weather without having to lookup your position (or what "weather tile" you are on), because changes to the environment will inevitably also reference your current position, but it falls short at supporting realistic weather where weather should be different at different positions/times and where weather phenomena should have a mutual effect on each other.
This is obviously still fairly powerful because Nasal can be used to dynamically modify the surrounding weather while in-flight (as you have no doubt noticed during your recent experiments).
But at the moment there is simply no way to tell FG to instantiate certain weather phenomena (think turbulence) at a certain given position (or time of day).
I would imagine, this type of optional granularity would also be handy for many instruction-like scenarios or even "missions", where weather phenomena need to be configurable to this degree.
Also, it's worth keeping in mind that the current model is totally unaware of multiplayer being used or not, in other words each client using multiplayer can still have its own weather settings no matter if these make sense or not.
So weather settings are not synchronized across multiplayer clients and so there may be a lack of consistency under some circumstances.
And while multiplayer consistency should probably only be considered a very low long-term priority, it makes probably sense to keep in mind that some people may not want to use a common/shared "weather system" on multiplayer, even if it should eventually exist. So, a decoupled approach seems to make sense.
Creating a weather system that may eventually work similar to a metar server should make it possible to allow multiplayer clients to optionally subscribe to server-side weather or not.
In a local sense, this fails to create a situation in which I fly in sunshine over Berkeley and see San Francisco vanishing in rain showers. In a global sense, longhaul flight weather becomes a series of disconnected sudden changes whenever a new METAR is fetched.
Yes, absolutely - this is also about the issue of weather not being configurable on a specific position/time basis.
To some extent, his could possibly be addressed by providing and using METAR-like data at a finer granularity, so that one METAR isn't directly applied to a complete "weather tile", but instead multiple METAR reports are used to dynamically populate a weather tile, and interpolations/extrapolations are used in transition zones (or those without any METAR data available).
And still users may want to individually set up custom weather (clouds, winds) at certain positions.
I believe pretty much everything can more or less be done with the existing technology (the Nasal + xml structure is incredibly nifty) , although some things would presumably be faster when coded in C++, and eventually it's probably cleaner to hard code it when it works.
Yes, that's true.
The usual approach in FlightGear is to use Nasal scripting for prototyping and as glue code, and hard code performance-critical code using Nasal helper functions, so that the code itself would be run in C++ space but would still be accessible to scripts by using a new custom functions.
Regarding Nasal coding, you only have to keep in mind that Nasal code is by default run inside the fgfs main loop, so the framerate you get is directly tied to the update rate of your scripts (i.e. something like 20-30 hz should usually not be a problem).
So either subsystem may currently slowdown the other one (rendering <-> scripting).
This makes it also unsuitable for implementhing high frequency computations, which is good to know.
If you do need things to run at a higher rate, you will either need to see if Nasal threads (without using any of the non threadsafe FG APIs inside the thread!) can be used or if the code in question can be moved into C++ space (this will however a require a recompiled/updated fgfs binary, recompiled binaries are frequently made available as CVS snapshots by some developers).
Some time ago (can't find the discussion now), I was able to easily run Nasal computations inside a dedicated helper thread at rates of several khz.
For prototyping purposes, Nasal is however very powerful and can often be used without touching any C++ at all.
When we were discussing the ridge lift system last year, we also found that it could have been largely implemented just in Nasal.
But for example the heuristics determining the global weather situation from METAR doesn't need to be fast - this can take minutes and still is fine.
Yes, and such complex computations that may take long but whose results are not necessarily required right away, can also be split up to be executed across several frames or even seconds, so that the results can be accumulated slowly.
The only thing that really needs to be fast are transformations of 3d clouds whenever they need to be rotated - and here I'd have a few more animation tags besides the spherical and non-spherical billboard on my wishlist (see the Wiki for that).
I am still not really very familiar with the latest code for 3D clouds in CVS since the migration to OSG, however the last time the 3D clouds system was discussed here, our forum moderator "stuart" was able to provide some feedback about how the 3D cloud system is designed and implemented and what its restrictions are.
So he is probably also the best person to talk to for requests regarding additional animation tags.
If there's serious interest in working on that kind of weather model, I'll make a Wiki page summarizing the ideas.
Last year when we were discussing the new "ridge lift" system, there was already one page added specifically about improving glider realism:
http://wiki.flightgear.org/index.php/Im ... er_RealismIt already has a small section about weather modeling, but adding a new page specifically about weather modeling might actually be a good idea.