[EMAIL PROTECTED] writes: > When you say "weather/environment management system" what do you mean? > Do you mean something that includes the following? > > 1. weather data retrieval mechanism
Yes. I'm starting with the front-end (the interface between FlightGear and the rest of the environment code) and working backwards. FGEnvironment holds the weather information for a specific place and time; I'll also add an FGEnvironmentManager to look up the information for other arbitrary places and times (i.e. the ATIS station tuned in on COM1, or the left wingtip). > 2. conversion from raw form to a source independent format stored > either in memory, or a persistent format Yes, if you mean METAR parsing and the like. I'll probably isolate that behind a generic interface, so that we can use different kinds of information providers. It will be in the Environment/ subdirectory, but will really be a separate package behind the same front-end. > 3. logical analysis of the code to isolate relevant data I'm not sure what you mean by "code" here. If you mean interpolation among weather station data points, then yes, I'll have to support that. > 4. code to render the visible aspects of the weather No, that will be entirely separate. Right now there's a tiny bit of rendering code in FGEnvironment, left over from the old FGWeather class, but I want to remove that completely. > If so, that's cool, but to me it seems like this is sort of slicing > the pie the wrong way. I would hate to think that any alternate > "weather/environment management system would have to duplicate > functionality across so many layers of code. It just seems to me > that it would make sense to isolate the steps so that each one > could be replaced individually. Yes, I agree. I'm not touching rendering at all, and I'm going to be careful to keep the rest nicely segmented. > Also, are there any goals regarding weather in FG? If someone were to > rewrite the weather subsystem, would it be more appropriate to simply > do another system like what we have or would it be more appropriate to > plan for the day when we move beyond flat plane cloud layers? I'm following the build-for-today rule from Extreme Programming: I'll add support for (say) volumetric clouds when we can render volumetric clouds. We *can* render cloud layers today, so I will add support for that. > It seems that the current FG weather system is a lot like > X-Plane's. With the exception of ATIS reading the string > appropriate for its location, the weather for the entire world is > identical to the weather at the aircraft's current location. I think that everyone agrees that we want different weather at different locations. FGEnvironment will deal only with the data issues, not with the rendering issues (i.e. it's an open question whether you'll be able to *see* the different weather). All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
