> > It's actually surprisingly intricate. For instance, Local Weather allows > for boundary layer gusty winds. For some problems (the wave pattern) you'd > like to have the base (mean) wind at the surface, for others (windsock) > rather the actual wind that the aircraft is feeling. > > I am now internally storing the interpolated wind (wind at aircraft > location and altitude based on all available 3d interpolation points), the > current wind (interpolated wind after local boundary layer correction and > gust effects), the interpolated surface wind at current location and the > current surface wind at current location. > > May I suggest a subfolder /environment/surface (and possible subfolders > /environment/location[i] in case a location other than aircraft position > is needed? > > /environment/surface/ could then contain > > surface-base-wind-speed-kt > surface-base-wind-direction-deg > surface-actual-wind-speed-kt (for gusts) > surface-actual-wind-direction-deg (for variable winds) > > In addition we could maybe use > > effective-cloud-coverage-octas (how much is covered by the sum of all > relavant layers) > wetness-flag (boolean - in case we want to use wetness-dependent textures) > snow-level-ft I have to postpone all this for a few weeks, but I have starred this mail. Please ping me, if I don't wake up after the release ;-) >> I hope we find a way to integrate "global weather" and "local weather" >> into just "weather" one day which provides the full range, from simple >> .. > I wouldn't have any problems with that. Hehe - you will! That will most likely require some restructuring of code from both, the local weather and the fg core. > It's just difficult for me to > imagine how it would look like, as the philosophy is rather different. > Although the boundaries become more and more blurry since now both systems > refer to the same set of cloud textures and to the same rendering system. > If anyone has a vision how the finished product should look like, please > let me know :-) FSweekend and LinuxTag are excellent places for a brainstorming ;-) > > By the way, Torsten, could you clarify the status of > > --prop:/environment/terrain/area[0]/enabled=1 > > to start the terrainsampler in 2.6 - will this be needed at startup (i.e. > should I re-activate the check at startup if this is on), or will the > sampler be available automatically, i.e. can I assume that the system will > be available? The property /environment/terrain/area[0]/enables is set to a boolean value of false on startup. This ensures the sampler is instantiated but not running. You should set it to true when you enable local weather and reset it to false when you disable local weather. Also, make sure to set /environment/terrain/area[0]/input/use-aircraft-position to true if want to sample the area around the aircraft's position. So, No: the --prop switch will no longer be needed at startup, the sampler is there but disabled, you can assume the system will be available.
HTH, Torsten ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
