Woot wrote:I'm also trying to think a way to generate thermal and ridge fields for multiplayer
At the moment, thermals are mostly based on custom AI models that aren't exposed via the multiplayer protocol.
Also, thermal modeling is still relatively crude overall and needs to be individually configured using static XML files, that are local and specific to each fgfs client.
So, various clients could use different "thermal scenarios" on multiplayer and would all get to see and experience different thermals, because the multiplayer system is not thermals/AI-aware.
Most of this can probably be better achieved by using a glider with a null/nasal FDM whose velocities and orientation can be directly written to the property tree.
Implementing ridge lift is a pretty neat idea because it would be multiplayer agnostic as it would logically occur on all clients with ridge lift support, in fact the phenomenon itself would also affect non-gliders (in the form of naturally-occurring turbulence).
Woot wrote:depending on real weather, thought this one will probably be a hard one
Depends on if are you aware of any raw data sources (=easy to parse/process) for gliding/soaring weather?
The ridge lift thing is probably very well possible to implement without too much work - here are some unsorted thoughts:
Modeling ridge/orographic lift requires a way to interactively query your aircraft's environment for certain properties that are characteristic/required for ridge lift to occur, that's mostly the terrain elevation in the direct vicinity of your aircraft in order to determine if the terrain beneath your aircraft is a "hill", "mountain" (or "ridge"), and then also the predominant winds and temperatures/moisture.
This terrain querying or sampling needs to take a segment/area of a certain size into account, not just your present position - so that you can compare the ground elevation for a whole area in order to determine if the terrain's curvature is typical for ridge lift to occur (and where it would logically need to occur).
If it is, you'll probably want to factor in the wind speed and relative AoA of the wind on the ridge, in order to compute the resulting vertical airspeed and vector to emulate rising/failling airmasses at the appropriate locations above the ridge.
Factoring in the wind is the most straightforward thing because the current weather system in FlightGear isn't location-specific, everything applies to your aircraft's current position - all the required data is to be found in the property tree under the "environment" branch, and can be easily accessed and manipulated using Nasal.
While all this would be ideally done in C++ space and could be exposed via a handful of properties by FlightGear (e.g. "/environment/aircraft-is-above-ridge", "/environment/ridge-left-intensity"), implementing this doesn't necessarily require C++ or recompilation, because Nasal scripting could very well be powerful enough:
In the FlightGear base package, you can find a Nasal module called "geo.nas" this provides basically most of the code (a terrain query API) that you need in order to implement support for ridge lift as a nasal module (script), so that you don't have to recompile FlightGear.
Given that gliders are not high performance aircraft, sampling the aircraft's underlying terrain at a rate of 0.5 to 3 hz should probably be sufficient for most situations, this could be implemented using Nasal based timers, so that the sampling code isn't run too frequently. Indeed, by emulating the concept of coroutines you could increasingly update the sampled area, so that not the whole area is sampled at once, but instead incrementally.
In fact, you could make the terrain area to be sampled runtime configurable using properties and listeners, so that you can manually tweak the sampling area's dimensions to determine suitable values while developing this ridge lift module.
Also, I am sure there must be some scientific papers on simulating ridge lift, so that one could try to reuse algorithms in order to emulate proper ridge lift behavior.
Similiarly one could approach the task of modeling thermals using Nasal for different landcover types, and weather situations.
I don't know however if it's currently possible to dynamically place 3D clouds in the appropriate areas using Nasal or the property tree, but that could probably be added easily if needed - as a crude workaround you could fall back to placing 3D objects in these spots using the same geo.nas module for thermal clouds.