Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Am Wednesday 20 July 2005 03:46 schrieb Pigeon: I suppose using an invisible aircraft would work now as an observer. If the server could handle something like if someone connecting with a callsign observer, then it would simply send packets to the observer about other real players, but don't need to get another info from the observer itself, except, perhaps, logging on or off. That will also mean the server needs to be happy with multiple connection with the same callsign. So I'd say it might be better to just treat them as a special class of clients. I was thinking about oberservers, too. So it will be possible to build radar stations (human operated) and tower controll etc, without disdurbing the other clients (which would try to render the observer). Using the callsign observer to mark observers is possibly the best approach for the moment, as it will work with the current client (unless there are more then other 10 clients). But then again the question about reach arises. Does an observer only get information about clients in its reach or about all clients connected to the server? For generating a map of current clients connected to the server this way is not appropriate. The map generator would have to listen some seconds to the server in order to get information of (hopefully all) clients. A better way is to implement some kind of admin protocol in the server based on TCP rather then UDP to get (and maybe set, too) information on connected clients. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
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. 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... 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. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Oliver Schroeder wrote: I was thinking about oberservers, too. So it will be possible to build radar stations (human operated) and tower controll etc, without disdurbing the other clients (which would try to render the observer). Rather than special casing this (special case abstractions are the work of the devil), why not implement the priority sorting update scheme I mentioned in the previous message and have the observers be motionless objects at some sane position like the center of the earth, so they see all clients with the same priority. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
So, basically you get an invisible UFO and don't show up as a player, right? Hmm I would imagine the server doesn't need to broadcast these observers to others. It's not an actual player. I suppose using an invisible aircraft would work now as an observer. If the server could handle something like if someone connecting with a callsign observer, then it would simply send packets to the observer about other real players, but don't need to get another info from the observer itself, except, perhaps, logging on or off. That will also mean the server needs to be happy with multiple connection with the same callsign. So I'd say it might be better to just treat them as a special class of clients. Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Pigeon wrote: So, basically you get an invisible UFO and don't show up as a player, right? Hmm I would imagine the server doesn't need to broadcast these observers to others. It's not an actual player. I suppose using an invisible aircraft would work now as an observer. If the server could handle something like if someone connecting with a callsign observer, then it would simply send packets to the observer about other real players, but don't need to get another info from the observer itself, except, perhaps, logging on or off. That will also mean the server needs to be happy with multiple connection with the same callsign. So I'd say it might be better to just treat them as a special class of clients. Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d 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. 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. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
