On Sunday 22 February 2004 14:38, David Megginson wrote: > Curtis L. Olson wrote: > > I vote for some sort of simple approach that just warps the values when > > ever they change. Once we get the nearest station updating working, > > then we could do something slightly nicer by "interpolating" the old/new > > values over time so they change smoothly. Personally I think that > > interpolating data between stations is probably way over kill. Weather > > reporting is never that exact, and things could have changed since the > > last official reading, etc. etc. A simple interpolation scheme should > > be all we need and I think it would work great. > > Here's my suggestion: forget about the internal environment manager > (disable it, if possible) and for now, manage the weather entirely though > an external daemon written in Perl, Python, Java, C, C++, PHP, or > what-have-you. That makes it a lot easier for us to experiment with > different approaches -- all the external daemon has to do is check the > current lat/lon/alt every couple of seconds and update the /environment > variables appropriately. > > A really clever external manager could handle things like thermals and > ridge lift for the soaring pilots, mountain waves for the mountain fliers, > etc., using its own coarse-grained DEM data. > > Once we have an external manager that we think is really, really good, we > can recode it into C++ and embed it in FlightGear, but since the amount of > network traffic is very small, there's no reason not to start out external. > > > All the best, > > > David
Interesting to read about the possiblity of stuff like like thermals, ridge and wave - it would further broaden FG's appeal quite a lot, I'd have thought. I'd love to do some glider models too:) LeeE _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
