> 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

Reply via email to