--- "Ampere K. Hardraade" wrote:
> On Monday 14 May 2007 04:38, Stuart Buchanan wrote:
> > If what you are suggesting is that to use MP, we will have to run the
> FDM
> > on a server and accept a much lower refresh rate on the client, then I
> > don't think that is acceptable as it will make the civil MP experience
> > much worse.
> 
> This isn't as big a deal as many have advocated.  There's no requirement
> that 
> the FDM server has to be run at a central location.  The server can be
> run on 
> the client machine as well, serving FDM functions to the client only,
> and 
> latency wouldn't be an issue at all.

Sure, but as I understand the current proposal, running the FDM on the
client will only be done for non-MP use. For any MP environment (civil or
military), the FDM will reside on the server. 

I apologize if I have mis-understood the proposal.

> From what I can see, a FDM server brings in tremendous potentials to 
> Flightgear, whereas enhancement to the present architecture would offer 
> little.  For example, to enable multiple users to fly a single aircraft,
> 
> there must be some sort of server to recieve inputs from multiple
> locations 
> and to multicasts FDM outputs.  There's no reason why one would want to
> hack 
> a client to make it do the jobs of a server when this can be very easily
> implemented if a dedicate FDM server is present.

This is getting somewhat off-topic, but I think the current MP protocol
could be enhanced to provide this function fairly easily. The first step
would be to (re-add) function to export arbitary properties. Then define
the FDM properties to be exported from the master computer (running the
FDM), and define control inputs to be passed the other way from the slave
(running null FDM). Write a bit of Nasal to mix the ai tree with the
normal tree and you're done.

There are obviously some issues regarding shared controls, but I think
those are going to be present no-matter how you split the FDM.

> > My conclusion is that the dog-fighting MP protocol (using a server
> FDM) is
> > going to have to be completely separate from the civil MP protocol
> (usign
> > a client FDM).
> >
> > -Stuart
> 
> That's an absolutely awful idea.  You will end up with two development 
> branches to keep track of, and inevitibly the more "popular" protocol
> would 
> end up being much more advanced than the less "popular" one.

Yes, it is awful. However, requiring a remote server FDM for civil MP is
worse.

-Stuart



                
___________________________________________________________ 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. 
http://uk.docs.yahoo.com/nowyoucan.html

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to