Curtis L. Olson writes: > - respect runtime property changes (i.e. new altitude or location) > > I would respectfully suggest that this one not be implimented or at > least be put at a low priority. We tried to do this in JSBsim and it > can really get messy.
The problem was that the startup trimming routine and the properties always ended up arm-wrestling. In principle, this should be very easy: 1. Before each iteration, copy all state variables in from the bus/property tree. 2. After each iteration, copy all state variables back out to the bus/property tree. YASim already does #2; it simply needs to add #1. JSBSim retrims automatically when certain values are changed outside the FDM unless certain properties are set, etc. -- it's all fairly confusing. Over all, I think it would be better if none of the FDMs trimmed automatically. FlightGear, which provides the primary user interface, is in a much better position to know when trimming is required; for example, you do want to trim when an altitude and speed are selected on the command line, but you do not want to trim when a flight is being restored from a save file. If the FDMs simply retrim for steady state when requested, we can make sure the request is issued when needed. That should clean up the JSBSim/FlightGear interface code a bit as well. Tony: what do you think? > I think it would be much cleaner to force a reset to a new location > each time we warp to a new location. This allows us to delete the FDM > instance and create a new one so it can be freshly inited and trimmed > for the new conditions. Otherwise, it's really hard not to carry over > some state from the previous location which can cause obscenely large > forces and other wierdness. The problem is that when we restore a saved flight or start a premade scenario, we'll get bumps (etc.) from the trimming routine, when the saved state was already (presumably) steady. I think we're pretty close -- you want to force a reset, and I want to be able to request a retrim. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
