Am Wednesday 20 July 2005 20:14 schrieb Andy Ross:
> Josh Babcock wrote:
> > Right, it would be silly to send all that data to the server when all it
> > needs to know is where your are and what you can see. Plus the position
> > data could be sent at low resolution.
>
> The best way to do this is actually dynamic: the server gets to send
> the X "most important" objects to each client per update.  Importance
> can be defined in screen space -- think of it as the number of
> "pixels" of error that the receiving client would have if the update
> were not sent.  This way your wingman always gets updated, and a
> burning/turning dogfighter will get frequent updates, but a jetliner
> moving in a straight line is nicely optimized and receives very few
> updates.
> You can also handle orientation error this way, by giving the object a
> "radius" and figuring that a 180 degree orientation different produces
> an error of that size.

I am sure that I don't understand this.

Anyway:
Sending updates based on "importance" would improve rendering of nearby 
objects, as a client would get more/better information of objects of its 
interrest?
In that case: can the server decide what is important to a client?

> > Either way the server would have to be able to handle multiple instances
> > of the same callsign. Otherwise an invisible observer could silently
> > prevent a flier from connecting.
>
> Better would be to assign a prefix or suffix to duplicate callsigns,
> so that the second "andy" to connect becomes "_andy" or "andy-0",
> etc...

Actually the server doesn't care much about callsigns. It simply checks 
Sender->Callsign == Currentplayer->Callsign and Sender->IP == 
Currentplayer->IP (Currentplayer = current player when walking through the 
list of clients) and thus preventing sending packets back to the sender.

> Also, I'd suggest defaulting the callsign to the USER (unix, cygwin)
> or USERNAME (winnt) environment variables where available, to avoid
> the problem of zillions of identical "flightgear-user" planes flying
> around.  Sane defaults are always good.

This should be easy to implement in the client.

regards,
Oliver

_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to