Christian Mayer writes: > > 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)
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: 1. We now have an FGSubsystem base class declared in Main/fgfs.hxx (this didn't exist when you wrote your code). Your top-level access class, whatever it is, should extend this interface and implement the abstract init(), bind(), unbind(), and update(int) methods. That way, we can move the bindings out of fg_props.cxx, which is a kludge. 2. You should consider storing the top-level pointer to your subsystem in FGGlobals. 3. Concentrate on JSBSim and YASim for the FDM integration at first. LaRCsim is pretty much deadweight now (except for some of the UIUC stuff). I wouldn't worry about GUI stuff for now. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
