Jim Wilson wrote: > That has nothing at all to do with what I said. We are controlling > individual control surfaces. Period. I don't think we should have > subclasses for each desired action/process. Only each control > surface type. Roll control ends up being intrinsically part of > aileron control is it not?
I'm half with you. We certainly don't want separate subclasses for every conceivable action, that's madness. But assuming a set number of "standard" control surfaces isn't right either. A helicopter has roll control yet no ailerons. The harrier has ailerons *and* roll jets, with an autostabilizer that uses both depending on conditions. I'd strongly suggest an architecture where the autopilot specifies a black box, with all input and output done via property nodes: ../roll-rate -+ +-----------+ /controls/elevator ../yaw-rate -+--> | Autopilot | --> /controls/ailerons ../heading -+ +-----------+ /controls/... No control system assumptions in the C++ type system, and it's still perfectly configurable. Just remap the input and output nodes per-aircraft if you want, maybe via an override in the -set.xml file. Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
