Sid wrote: "Maybe you already looked into this , but to me it would make more sense to bind the joystick buttons to activate the <enable> properties in the actual autopilot.xml files rather than modifying the author's specialized scripts.Or write a generic nasal file to handle the variety of different enabling methods?"
This is the path I was hoping to take, but I haven't found out a good way to handle issues that differ from one plane to another. For example, in the Seneca, the key properties are autopilot/CENTURYIII/controls/"x" and "/autopilot/CENTURYIII/locks/"y", where "x" and "y" are pitch-hold, roll-axis, etc. But in the B1900, the key properties are "/autopilot/locks/yaw-damper" and "/autopilot/locks/passive-mode", which don't exist in the Seneca. For the Comanche w/ Century III, I haven't found a set of properties that work correctly when triggered through joystick xml. How can a script that does not have aircraft-specific versions handle them all? The best approach I've come up with so far is to have the joystick xml file call "controls.autopilotEngage()" and controls.autopilotDisengage()", put a generic version of the engage and disengage scripts into $FG_ROOT/Nasal/controls.nas, and override this function for aircraft that need to modify it. In effect I'm using object-oriented inheritance, overriding the method in the Aircraft nasal from the pseudo-base-class in the root. The hidden agenda to all this is that it gives me an excuse to figure out how Nasal works. :-) Thoughts welcome -- you guys are the experienced developers. Cathy ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
