On Mon, 10 Jun 2013, Erik Hofman wrote: > On 06/10/2013 10:12 AM, Anders Gidenstam wrote: >> On Sun, 9 Jun 2013, Jon S. Berndt wrote: >> >>> Can I request that the current version of JSBSim that is in our cvs as of >>> this moment be synched to FlightGear as early as convenient for the >>> synch-er? What's the proper procedure? >> >> Usually Erik does the synchronization. However, if he doesn't have time >> (please, let us know if that's the case) I could take care of it. > > Yes I do have priorities higher on my list, so it would be great if > someone else takes care of it.
Ok. Here is the first version: http://www.gidenstam.org/users/anders/FlightGear/test/jsbsim-synch-2013-06-10.diff I have, so far, (very) briefly tested it in FG with the c172p, ZLT-NT, Short_Empire and MTB_20m (not in fgdata) aircraft and they seem to work, including resets. Additionally, my JSBSim/standalone performance tuning scripts for Short_Empire still produce the same result as at the last FG release. There are (at least :) two code issues: 1. In src/FDM/JSBSim/models/FGPropagate.h there is a inline:d member function that most probably should be moved to the .cpp file instead. GCC posts a warning about returning a reference to a temporary variable for it, which indeed does not sound like a good idea (the other similar looking member functions return a reference to a /member/ variable). Additionally, calling the * operator for FGColumnVector3 is probably not going to be inlined so there'll be at least one call anyway. Input from someone C++ current appreciated.. :) const FGColumnVector3& GetEulerDeg(void) const { return VState.qAttitudeLocal.GetEuler() * radtodeg; } 2. The JSBSim class FGPropertyManager was previously derived from SGPropertyNode, but isn't now. This affects the creation of the main JSBSim object (FGFDMExec) since it requires a FGPropertyManager instance to access the property tree. I have currently changed the FG JSBSim driver, JSBSim.cxx, like this: - fdmex = new FGFDMExec( (FGPropertyManager*)globals->get_props() ); + // FIXME: The FGPropertyManager object must be freed somewhere! + fdmex = new FGFDMExec( new FGPropertyManager( (FGPropertyNode*)globals->get_props() ) ); but this will leak a FGPropertyManager object on each reset. Hopefully there is no problem to just keep track of the FGPropertyManager object and delete it at reset. I have not tried that yet. (The somewhat dubious cast of a SGPropertyNode pointer to one to its (JSBSim) subclass FGPropertyNode mirrors that of the previous code that has apparently worked ok.) Cheers, Anders -- --------------------------------------------------------------------------- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
