> A Sigma-Tek attitude gyro, for example, looks and works pretty-much > the same as a primary instrument for a Cessna 150 or as a backup > instrument on a 747 -- the differences (such as different voltage for > the backlighting) are pretty trivial. I'd hate to see 100 copies of > the same Sigma-Tek attitude gyro in the base package. What we probably need for shared instruments is a well defined set of properties for each instrument. Currently most of our instruments animations are tied directly to the output properties of the signal source. In vor.xml the TO-flag is animated from /instrumentation/nav[0]/to-flag. It's only usable for nav1 and a second set of animation xml is needed for nav2. What we need are unique properties for each instrument that are responsible for the animation of the instrument on on side and unique properties that reflect some state (like a TO-flag signal) on the other side. What's left for the A/C designer is the linkage between these two side. When you buy the Sigma-Tek attitude gyro at you local avionics dealer (the base package), you get your device with a well known interface connector and your avionics technician (A/C designer) needs to do the wiring. Almost everything needed for that "three-tier-design" is already in fg. Probably we need some kind of "relative mount point", so a single vor.xml can be loaded (mounted) into /instrumentation/vor-indicator[0] and /instrumentation/vor-indicator[1].
Torsten ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel