On Fri, 20 Mar 2009, Torsten Dreyer wrote: > I followed your advice and didn't rush ;-) > No problem with the nasal wrapper for the animations. > Do you have a "generic" interface for the properties for the remote aircraft? > Are they transmitted via the generic multiplayer values?
Hi, They are "packed" into a set of generic MP properties for transmission using a set utility components (in ZLT-NT/DualControl/pilot-dual-control.nas). The best structure I currently have is that the instrument's nasal module provides functions that return the configuration pieces needed to configure such utility components for the instrument (which is done at the per-aircraft level). E.g. the aircraft might use a MP property to encode 32 switches/buttons - that encoder component would be configured with to handle switches from from several instruments. > It should be cool to have a single instrument to be used for both of the > dual-control aircraft. Hmm, I suppose you mean for both the normal and the dual control aircraft? To make an instrument dual control enabled one does not, at least in principle, need to modify the instrument 3d object at all, and the XML model file only if the pick animations isn't already going through Nasal wrappers. So what is needed is a modified Nasal module for the instrument but (except for the code bloat) it would work fine also for the single user case (since it anyway has to work when there isn't any copilot around). However, in practice I ended up forking the 3d objects too for quite a few instruments since I wanted to use a different pick animation style (I don't fancy the "hotspot" rectangles :) (But OTOH my input style is not friendly to people without a mouse wheel and/or MMB.) Speaking of that, maybe we should try to figure out a common style or best practice for pick animations? I like the "point at the control", LMB inc, MMB dec and mouse wheel inc/dec style, but it isn't too friendly to people without a fully featured :) pointing device. I'm not too fond of the flat "hotspot like" rectangles since they end up in non obvious places when the instrument is far away on the other side of the cockpit. > I am very much interested in this feature to implement it into the SenecaII, > but I feared so far, that I have to double all instruments. > I haven't spent to much time yet to understand how dual control works, though. Gearing up the SenecaII for dual control will be a handful, yes :) But I think you can do it with it without changing your 3d objects - only XML and Nasal work needed. Look in Aircraft/ZLT-NT/Systems/ZLT-NT-dual-control.nas to get some idea of the per-aircraft configuration. Aircraft/ZLT-NT/DualControl/Instruments/VHF-22/ctl22.nas is an example of a dual control instrument. One could imagine splitting such a instrument module into the basic single user instrument and a module that (when needed) can wrap around it and add the dual control parts while still using the original module for the actual operations of the instrument. Hmm, that's yet another item on my TODO list :) Cheers, Anders -- --------------------------------------------------------------------------- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
