Hi, first I want to say that there's nothing personal in this 'case'. And I don't care too much if it's my code or David's code (or both) that 'survive' at the end.
I've written WeatherCM in an attempt to learn the ++ of the C++ and thus it did it's job for me. But what puzzels me is the 'style' in which David added his code. There must be a reason why my code isn't good enough for David (my it be lack of functionality, lack of documetaion, compiler errors, something totally different, none of that, all of that, what ever - the reason doesn't matter). So I'd expect that anybody who's got a 'problem' with some other code ask about it first before going through all the trouble to reimplement it. I can't remember such a mail (perhaps it's been in another thread; due to a very sad event I didn't have time this week) Perhaps we should focus on the technical issues: Looking at the environment code it looks quite similar to mine. That's no surprise as it's doing the same task. Apart from the class interface (FGEnvironment == FGPhysicalProperty), accessing the stored data is also very similar: > The rest of FlightGear won't have > to know about that -- all it has to know is how to get an environment > object: > > const FGEnvironment * env = globals.get_env_mgr()->getEnv(lat, lon, alt); FGPhysicalProperty wdbpos = WeatherDatabase->get(position); (where position[0] = lat, position[1] = lon, position[2] = alt) And the weather values at the current position are alredy visible through the property system: /environment/weather/wind-north-mps /environment/weather/wind-east-mps /environment/weather/wind-up-mps /environment/weather/temperature-K /environment/weather/air-pressure-Pa /environment/weather/vapor-pressure-Pa /environment/weather/air-density gives you everything you need at the current position of the plane. Through the basepackage/current.txt.gz it's possible to have worldwide current weather settings. As I didn't recieve a message about the limitations that the WeatherCM does have, I don't know the reason for creating a new one. The limitations I know about are quite easy to fix in a very short period of time (anybody who want's to help: here is a opportunity to get a lot of functionality with very little work): - there's no intuitive way to set the weather -> write a new FGWeatherParse that reads a intuitive file format (e.g. XML) -> Write a PUI menu that allows you to change the weather data during the running program - the FDMs don't react to the weather -> Modify them to read the properties that are already there (NB: that's *easy* and the most noticeable change) - the WeatherCM is too complex -> It's not. Any weather system that tries to have worldwide coverage with the ability to interpolate between the stations will have that complexity. Conclusion: It doesn't matter if it's FGEnvironment or WeatherCM or both in the end. The GPL will allow us to have the best solution. But as the project is run on our free time we should try to be as efficient as possible. So we should try to work together. If it's not possible to work together (eg. because someone wants to try a totally different approach -> YASim vs. JSBsim) it's OK to 'split'. In my humble opinion FGFS would profit much more if David (who's a great coder!) would try to fix the remaining limitations of WeatherCM than to try to invent the wheel the 2nd time. CU, Christian -- The idea is to die young as late as possible. -- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
