re: [Flightgear-devel] FGEnvironment [not] vs. WeatherCM
On Sat, 23 Feb 2002, David Megginson wrote: Christian -- I'm developing my own weather DB in a separate stream (--with-new-environment) partly to give you and others a chance to integrate your code. If you can tie it in to the rest of FlightGear (including the FDMs), I'll happily stop my own work and write off the couple of hours I've spent on it. Here are a couple of suggestions: I think I might be missing something here, so please let me know if I am. Instead of taking what seems a lot like some kind of passive aggressive approach, wouldn't have been a little easier to simply propose a new interface for the environment subsystem? Also, wouldn't it be the FDM author's responsibility to integrate their FDM into FG's other components? Also, if only the three things listed needed to be altered for the existing code to be acceptable, wouldn't it have been easier to make the changes yourself? Like I said, if I'm missing something, I'd really appreciate it if someone would fill me in. Is there a mailing list or website that discusses or describes what components need to be developed or improved and how those components should fit together? I think I'm subbed to all the FG lists and I've read the docs at FlightGear.org, but these don't have what I'm looking for. To someone looking into this project from the outside, changes to the existing code and changes to accommodate external projects seem to be made in an almost arbitrary manner. If there is something that could help define a context in which these changes should be viewed, it might make it easier to attract contributors. Thad ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
On Fri, 22 Feb 2002, David Megginson wrote: 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. Yes, that's what I meant. 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. Is it safe to assume that if one wanted to add support for winds aloft reports, they would only need to add code to acquire the data and then parse it into some kind of data structure defined by your system? How much support will there be for data beyond that which is included in the METAR's? Winds aloft reports are one example of additional data sources that exist outside FG, but not all weather data would exist outside the application. It could be possible to have weather data generated from inside FG itself in the form of thermals or ridge lift. (I use that term very loosely.) Would FGEnvironment be able to accept and manage data from these various sources? 3. logical analysis of the code to isolate relevant data I'm not sure what you mean by code here. Oops, I meant data, not code. If you mean interpolation among weather station data points, then yes, I'll have to support that. Will there be anything beyond basic interpolation? 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. Good to hear! 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. I'd just hate to see a chicken/egg situation arise where someone willing to improve the cloud visuals is turned off because FGEnvironment doesn't provide the necessary data in a usable manner. While implementing volumetric clouds might not be feasible today, I don't think anyone would argue that it will be soon. Much sooner if one were to aim for faked volumetric clouds like those in FS2002 or FLY2. I don't think it would be a waste of time to put a little thought into what better looking clouds might require from FGEnvironment. It could have a significant effect on how FGEnvironment deals with the data. Thad ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
On Thu, 21 Feb 2002, Curtis L. Olson wrote: Just like we have competing FDM's with different focus, strengths and weaknesses, I don't think it is bad to have competing weather/environment management systems with different focus, strengths and weaknesses. When you say weather/environment management system what do you mean? Do you mean something that includes the following? 1. weather data retrieval mechanism 2. conversion from raw form to a source independent format stored either in memory, or a persistent format 3. logical analysis of the code to isolate relevant data 4. code to render the visible aspects of the weather 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. 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? 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. If one wanted to simulate approaching a line of thunderstorms, the weather model would need to manage the data in such a way that that different geographic areas could have different weather. Forgive me if I stepped on anyone's toes. Thad ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c310 Panel
On Fri, 7 Dec 2001, David Megginson wrote: Andy Ross writes: the C310 has counter-rotating engines (therefore no p-factor) It does? Oops. I gotta get that fixed. The YASim model has identical engines; I thought that most of the simple twins had co-rotating engines, because of the difficulty of getting the engine manufacturers to tool up for mirrored engine parts. I meant that my model does -- I haven't checked whether the real one does or not. I know that at least some Piper Navajos and Twin Comanches have, as does the Seneca III. Does anyone out there know about the Cessna 310? You know the phrase, you can lead a horse to water, but you can't make him look at the type certificate? :-) I do have to say, I have not run across a site that made it harder to get to the useful stuff than this one. The trick seems to be making judicious use of the search capability. http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/MainFrame?OpenFrameSet The TCDS No. for the 310 is 3A10. Doing a search for '3A10' from the main page will return many links to the URL from which you can download the TCDS in PDF form. Once you've done this, you'll notice that for every model, the TCDS does not distinguish between left and right engines leading one to the conclusion that both props rotate in the same direction. You're right about the Seneca having counter-rotating props and if you download the TCDS (No. A7SO) you can see how seperate left and right engines are specified. Its also worth noting that this site also contains TCDS for engines. In my experience modeling aircraft for x-plane, I found that much of what you need to know is located in the engine TCDS. If there's any data not covered in the TCDS's that you need, let me know. I've got a couple of good sources for Cessna data. Thad ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
