> > > um ?? for code/data local to an a/c instance ?? remoting that would slow > > > down the response time to realtime events > > > > > For virtual cockpits, you're correct. however, when you're working with a > > physical cockpit, you need to have your displays on separate physical > > hardware. > > > > If the simulation reacts within 150ms of the real thing, you're still good > > for Class D anyway. 150ms is an eternity for most computers. > > > > Even on a 10BaseT network you should be ok > > whoa whoa whoa !!! thats more slaving the kb/mouse/stick inputs to an > exterernal source, and feeding out info that would normally drive the > panel/hud -- arent there native_ctrls/native_fdm/native_gui that handle > that ?? (though I would be much happier seeing that handled completely > seperate from any network multiplayer -- i.e. a plugin cockpit i/o module, > as you could have a physical cockpit sim driven by FG hooked into a network > multiplayer server) >
I'm just getting back into rooting around in the code and I don't yet have a solid grasp on all the parts. AFAIK, the only "native" support for an external module is OpenGC from what I've seen so far. I was referring the creation of a universal method of obtaining data from the sim via network - but only if such a mechanism doesn't already exist. If it does, point me to it and I'll go away. :) g. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
