What would be the added value of this as opposed to hooking up two 
sticks to the same machine running fgfs? I'm not sure whether that will 
work as well under Unixes, but there is no trouble in using that on 
Windows machines, simply assign the axes of both sticks to the same 
controls. I've been running dual control setups like that for a long 
time now, have yet to seriously test it with FlightGear but have no 
trouble using it on FS9.

Anders Gidenstam schreef:
> On Sat, 10 Nov 2007, Vivian Meazza wrote:
>
>   
>> Anders is hard at work extending this into a co-pilot facility - watch this
>> space. Meanwhile - if you are on MP we're aboard and watching you :-).
>>     
>
> In case that made you curious, I can provide a preview since my 
> prototype has now reached a somewhat useable state.
> Pilot and copilot currently have shared control over aileron, elevator, 
> rudder, throttle, mixture, elevator trim, flaps and brakes. The copilot
> has a limited subset of the instrumentation.
>
> The system consists of two "aircraft":
> - The pilot uses a modified variant of the c172p from FlightGear/CVS.
>    The pilot need to specify the callsign of the copilot (other copilots
>    will be ignored). Note: if your designated copilot uses another aircraft
>    than c172p-copilot some of his/her control input will still affect your
>    aircraft..
>
>    Usage example:
>     fgfs --aircraft=c172p-pilot --prop:/sim/remote/pilot-callsign="copilot"
>
> - The copilot uses a special "aircraft" c172p-copilot which
>    piggybacks on the designated pilot and captures the local control
>    inputs. A current limitation is that only the cockpit view (ctrl-v)
>    is jitter free. There is also a noticable delay between control inputs
>    and effect, since they are passed via the the multiplayer protocol.
>    The severity of this delay depend on round trip time and some other
>    factors - the delay seems significantly longer than the round trip time
>    itself.
>    Since being part of a control loop most likely wasn't in the
>    design spec. for the multiplayer protocol I think we can improve this.
>    E.g. by allowing the pilot side to bypass the deliberate
>    delay/interpolation of control inputs from the copilot.
>    That said, I have flown successfully as copilot in a setup with
>    100-120ms round trip time between both pilot and server and copilot and
>    server (total delay >500ms). Landing is a bit exciting in that
>    case, though.
>    The deliberate delay added by AIMultiplayer can be significant - I have
>    seen (rare) >5 sec delays on my LAN - I think some unfortunate
>    interaction during the startup of the pilot and copilot fgfs instances
>    messed up the AIMultiplayer lag tuning.
>
>    Usage example:
>     fgfs --aircraft=c172p-copilot --prop:/sim/remote/pilot-callsign="pilot"
>
> The prototype is available here:
>
> http://www.gidenstam.org/FlightGear/misc/c172p-dual_fgfsCVS.tar.gz
>
> (See http://www.gidenstam.org/FlightGear/misc/ for updates and some other 
> small projects.)
>
> Observations/Comments:
>
> - In FlightGear/plib the fixed nearplane setting of 10ft cuts away most of
>    the aircraft for the copilot.
>
> - The AIMultiplayer processing of incoming MP data adds a deliberate delay
>    which sometimes seems to become excessive (> 5 sec on a LAN?).
>    I know some extra delay is needed to make animation of MP aircraft
>    smooth and avoid extrapolation, but it would be nice to be able to
>    reduce or disable it for the control inputs from the copilot. A property
>    below multiplayer[x]/controls/ in the AI/MP subtree to control this
>    would be nice.
>
> - In the long run I think we'd want the MP system to support something
>    similar to publish/subscribe - e.g. the properties sent from the copilot
>    is only interesting for the pilot and the extended aircraft state
>    sent(/published) by the pilot aircraft is only interesting to the
>    copilot or anyone else riding in the cockpit.
>    Currently everybody in the neighbourhood receives the data.
>
>
> Have fun piloting!
>
> Cheers,
>
> Anders
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to