Re: [Flightgear-devel] Overhaulling the networking code (was: Multiplayer crashes with unknown aircrafts, any solution?)
Am Friday 15 July 2005 23:34 schrieb Ampere K. Hardraade: I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. Properties under /position are basically what being exchanged right now. As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. The existing code only needs some minor modifications to allow any kind of property to be send over the wire. There are only a couple of functions to modify in order to do this. That way it is possible to configure the network protocoll via XML-files and let NASAL do the logic (as suggested by hfitz on the AVsim forum, see http://forums.avsim.net/dcboard.php?az=show_mesgforum=198topic_id=913mesg_id=934page=) NASAL only has to fill a message structure and let the network-code send it over the wire. There are, however, some issues with networking. To actually send diefferent kinds of properties over the wire, you have two possibilities: 1) chain properties in one packet 2) send each property in its own packet In case 1) it may be possible to blast the capacity of packets (MTU) in which case the packet becomes splitted. And it may be difficult to handle splitted packets. In case 2) you possibly interfere with the frequency used to send packets and thus make it very difficult to keep clients in sync. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. In general you don't want to send large amount of data using UDP. You will eihter have to deal with lost data (which is getting worse with every additional client) and have to calculate approximations for values in the property tree or have to use some kind of data-received-confirmation machanism producing overhead. And it may be unnecessary to broadcast the tree. Assuming a normal startup of clients, every client can be initialized as they were local. This should give already a good approximation of its status at startup. And as packets arrive with updated property values, the data becomes more and more right. And calculate approximations for the property tree of other clients is necessary anyway to 1) deal with lost packets, 2) deal with low frequency rates of network packets and 3) temporary performance leaks of the local instance of fgfs. just my 2c, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Ampere K. Hardraade wrote: I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. I got started on something like this a few months back. Maybe I should work harder on it now that there is clearly demand for such a thing. It sent the position/orientation and 1st and 2nd derivatives as part of the position packet, and not as properties. Note that this isn't enough: another really important feature is proper time synchronization between the clients (not wall clock time, necessarily, but time of data validity). Otherwise network latency will cause skew, where different clients see different aircraft in different positions. This makes things like formation flight and dogfighting difficult. The other feature that sounded cool was automatically detecting the needed properties for animation from the aircraft model file during parsing. It requires some way of limiting the number of panel properties that are sent (I was thinking about doing it via the size of the animated object's bounding box), but should be pretty robust in practice. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Ampere K. Hardraade wrote: How about creating root-less nodes to act as seperated property trees for these aircrafts? This way, it will be easier to fool the animation files of these aircrafts into taking the proper values. Yes, exactly. They don't need to be rootless, just detached from the normal property scheme. Under /multipler/callsign/... for instance. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Andy Ross wrote: Ampere K. Hardraade wrote: How about creating root-less nodes to act as seperated property trees for these aircrafts? This way, it will be easier to fool the animation files of these aircrafts into taking the proper values. Yes, exactly. They don't need to be rootless, just detached from the normal property scheme. Under /multipler/callsign/... for instance. Just like the AIModel objects ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code (was: Multiplayer crashes with unknown aircrafts, any solution?)
Hi, this is a very good idea IMO. I was thinking about a very similar approach but never had the time and not yet the actual need to follow that. If you do something like that, you might take care for the MATHWORKS guys which use the network code like it is at the moment. So one will need probably some compatibility mode here. Greetings Mathias On Freitag 15 Juli 2005 23:34, Ampere K. Hardraade wrote: On July 15, 2005 05:41 am, Erik Hofman wrote: Looking at the Multiplayer code I can see this code can use a good overhaul anyway. It needs to adapt the SGSubsystem style and use the AIModel code to display the models, which will also allow it to show up on the radar. It's probably not too much work to do since most of the current code could be reused. Erik I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. Properties under /position are basically what being exchanged right now. As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Ampere K. Hardraade wrote: [...]As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. Displaying an animated aircraft won't be easy. Animation code in xml file is refering properties from the FG property tree (ie the user property tree) so we need a way to change some properties during the rendering of a MP aircraft. Perhaps can we do this with a temporary aliasing in the tree so that some branches point to the MP aircraft ? To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions. Good idea, with that we can handle all special cases. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. There is also some data/properties that can be guessed depending on the current 'action'. We can do a good guess of the different surface position for some standard manoeuvres. We can draw a smooth gear up/down animation without knowing the real value of /gear/gear[0]/position-norm for example, and if we were using this value it would be impossible to have a smooth animation because of the latency of the network. Of course in a client server configuration there is also optimisation to be done based on distance. No need to send any other data then position.velocity if the other MP aircraft is just a point on screen or on the radar, and no need to send any data at all if it is 1000 miles away. In the future we could also consider to have one server handling all AI objects for the clients to have a coherent environment. Imagine that you are training landing on the Nimitz with your friends but the ship is at a different position on each client. This would be very weird. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Overhaulling the networking code
Harald JOHNSEN Ampere K. Hardraade wrote: [...]As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. Displaying an animated aircraft won't be easy. Animation code in xml file is refering properties from the FG property tree (ie the user property tree) so we need a way to change some properties during the rendering of a MP aircraft. Perhaps can we do this with a temporary aliasing in the tree so that some branches point to the MP aircraft ? Multiplayer models are already animated - gear goes up/down correctly. The problem is that all models are controlled by the receiving player, not the transmitting one. Shouldn't be too hard to fix. There is also some data/properties that can be guessed depending on the current 'action'. We can do a good guess of the different surface position for some standard manoeuvres. We can draw a smooth gear up/down animation without knowing the real value of /gear/gear[0]/position-norm for example, and if we were using this value it would be impossible to have a smooth animation because of the latency of the network. Is this the right approach? Could we include e.g. the gear up command in a message, and let the rx system sort it out? That's almost what happens now. Smooth transitions already happen, but, as I said, under the control of the rx player. In the future we could also consider to have one server handling all AI objects for the clients to have a coherent environment. Imagine that you are training landing on the Nimitz with your friends but the ship is at a different position on each client. This would be very weird. Very good idea, and weather. I don't suppose clouds would be easy? Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Vivian Meazza wrote: Multiplayer models are already animated - gear goes up/down correctly. The problem is that all models are controlled by the receiving player, not the transmitting one. Shouldn't be too hard to fix. Is this the right approach? Could we include e.g. the gear up command in a message, and let the rx system sort it out? That's almost what happens now. Smooth transitions already happen, but, as I said, under the control of the rx player. Yes, so we can say they are not animated atm. receiver property tree using the c172p model root0\ |-position/* |-surface/* |-other properties 'player' 1 property subtree in receiver memory using a Concorde model root1\ |-position1/* |-surface1/* |-eof 'player' 2 property subtree in receiver memory using the ufo model root2\ |-position2/* |-surface2/* |-eof So on the receiver side the c172p.xml, concorde.xml and ufo.xml animation code point to the root0 property tree so all animations will reflect the receiver plane animations. An apparent simple hack is to change the root while rendering other 'player' models but this will break because the root1 root2 don't contain all the necessary properties to render a model. That's why I was thinking of doing this while renderering a model : root0\ |-position/ = point to /root1/position1 |-surface/ = point to /root1/position1 |-other properties So the receiver should manage a subset of the property tree for each transmitters. Concerning animation command I won't pretend that it is the way to do it in FG, but this is done like that in all MP games. Sending keyframe animation sequence is a waste of bandwith and worse of all it gives ugly results. This can work on a local network with a 50 ms ping but not on the internet with a 250ms ping. But this is only an optimization and has no impact on the design of the mp code. Very good idea, and weather. I don't suppose clouds would be easy? Vivian Cloud movement is based on wind direction and speed so it should be the same at all time if the initial situation is the same. To construct the initial situation I think it's enought to send the cloud layer information and the delta time during the connection to the server. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Overhaulling the networking code
Harald JOHNSEN Vivian Meazza wrote: Multiplayer models are already animated - gear goes up/down correctly. The problem is that all models are controlled by the receiving player, not the transmitting one. Shouldn't be too hard to fix. Is this the right approach? Could we include e.g. the gear up command in a message, and let the rx system sort it out? That's almost what happens now. Smooth transitions already happen, but, as I said, under the control of the rx player. Yes, so we can say they are not animated atm. receiver property tree using the c172p model root0\ |-position/* |-surface/* |-other properties 'player' 1 property subtree in receiver memory using a Concorde model root1\ |-position1/* |-surface1/* |-eof 'player' 2 property subtree in receiver memory using the ufo model root2\ |-position2/* |-surface2/* |-eof So on the receiver side the c172p.xml, concorde.xml and ufo.xml animation code point to the root0 property tree so all animations will reflect the receiver plane animations. An apparent simple hack is to change the root while rendering other 'player' models but this will break because the root1 root2 don't contain all the necessary properties to render a model. That's why I was thinking of doing this while renderering a model : root0\ |-position/ = point to /root1/position1 |-surface/ = point to /root1/position1 |-other properties So the receiver should manage a subset of the property tree for each transmitters. Concerning animation command I won't pretend that it is the way to do it in FG, but this is done like that in all MP games. Sending keyframe animation sequence is a waste of bandwith and worse of all it gives ugly results. This can work on a local network with a 50 ms ping but not on the internet with a 250ms ping. But this is only an optimization and has no impact on the design of the mp code. Now I'm not sure I understand the problem, let alone the answer. I'm sure that you can come up with a good answer. Keyframe animation? Very good idea, and weather. I don't suppose clouds would be easy? Cloud movement is based on wind direction and speed so it should be the same at all time if the initial situation is the same. To construct the initial situation I think it's enought to send the cloud layer information and the delta time during the connection to the server. It would be highly desirable to get at least the gear and flap animation, and the weather/clouds sorted. I'm not sure that I feel a pressing need for flight-control surfaces to be animated. I guess the first player will set the environment for all subsequent players, or would the server have some say in this? How would the initial conditions be the same, since players enter and leave at any time? What would happen when the first player left the sim? Would METAR data be updated? Could/should the server provide METAR data and time? Pretty much thinking out loud here. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Very good idea, and weather. I don't suppose clouds would be easy? Vivian Cloud movement is based on wind direction and speed so it should be the same at all time if the initial situation is the same. To construct the initial situation I think it's enought to send the cloud layer information and the delta time during the connection to the server. Harald. Why is there any need at all for the cloud info to be sent over the network? Since it's obvious that the FDM is local anyhow, and one could always cheat with it, some conventions must be needed anyhow. If everybody uses the real-time WX feed, everybody will fly consistent and see consistent clouds on the screen. Or are you talking about making everybody having the same clouds at the precisely same spots, not just the general cloud layer properties? At this moment, I am skeptical about getting WX updates from the server. Does server-side push of WX update to everybody make sense at all other than the fact that this way it might be possible to cut down on the traffic to the metar NOAA feed? The downside is that probably the WX update comes less frequently than other planes' position update; if a a plane update is dropped, it's not a big deal, just its next movement will be a bit more jerky; whereas if a wx change is missed, things will fly differently. Another downside is that everybody needs metar from different places, so in the worst case, with N players flying in N different places on the Earth, the total data sucked off NOAA is the same, yet the server now must be the one doing it all. Of course, if everything is just doing pattern work at KSFO, there may be some saving achieved... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
On Sunday 17 July 2005 16:55, Vivian Meazza wrote: Harald JOHNSEN I guess the first player will set the environment for all subsequent players, or would the server have some say in this? Such things should be allways done by the server to prevent cheating. How would the initial conditions be the same, since players enter and leave at any time? What would happen when the first player left the sim? That's why the server needs to control it. Then entering and leaving the server at any time isn't a problem. Would METAR data be updated? Could/should the server provide METAR data and time? Yes. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Overhaulling the networking code
Vassilii Khachaturov Very good idea, and weather. I don't suppose clouds would be easy? Vivian Cloud movement is based on wind direction and speed so it should be the same at all time if the initial situation is the same. To construct the initial situation I think it's enought to send the cloud layer information and the delta time during the connection to the server. Harald. Why is there any need at all for the cloud info to be sent over the network? Since it's obvious that the FDM is local anyhow, and one could always cheat with it, some conventions must be needed anyhow. If everybody uses the real-time WX feed, everybody will fly consistent and see consistent clouds on the screen. Or are you talking about making everybody having the same clouds at the precisely same spots, not just the general cloud layer properties? Ideally cloud layers, thickness, types etc. should all be the same. Same for wind and turbulence. I'm sure that we can do it. At least by ensuring that initial conditions are all consistent. At this moment, I am skeptical about getting WX updates from the server. Does server-side push of WX update to everybody make sense at all other than the fact that this way it might be possible to cut down on the traffic to the metar NOAA feed? Well that's probably worth doing. The downside is that probably the WX update comes less frequently than other planes' position update; if a a plane update is dropped, it's not a big deal, just its next movement will be a bit more jerky; whereas if a wx change is missed, things will fly differently. They certainly will fly differently if they don't get the same weather by some means. Have you now countered your own argument? We could make life interesting by having 2 duty runways crossing each other, and no ATC. Another downside is that everybody needs metar from different places, so in the worst case, with N players flying in N different places on the Earth, the total data sucked off NOAA is the same, yet the server now must be the one doing it all. Of course, if everything is just doing pattern work at KSFO, there may be some saving achieved... N players at N different places. Not a lot of fun in that, but I guess it could happen. Then the load on NOAA is the same in either case. In all other cases there would be a (small) saving. Don't forget, in FlightGear realism is everything. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
On Sunday 17 July 2005 20:20, Vivian Meazza wrote: Oliver C On Sunday 17 July 2005 16:55, Vivian Meazza wrote: Harald JOHNSEN I guess the first player will set the environment for all subsequent players, or would the server have some say in this? Such things should be allways done by the server to prevent cheating. Does that imply we always use METAR? Should we have some choice if the real weather is unsuitable? What about turbulence? Should we be able to choose time of day? No, this does imply, that the server should allways have the control over the weather and time of day settings. This means, that the server is telling you if Metar or something else is used. How would the initial conditions be the same, since players enter and leave at any time? What would happen when the first player left the sim? That's why the server needs to control it. Then entering and leaving the server at any time isn't a problem. The first player could set the conditions, and then providing that these were updated at regular intervals, other players could also enter and leave at any time. Who is the first player when the first player leaves the server? That's why normally such things are set by the server administrator or by the users who have to vote for a change of the settings. In latter case we need a voting system. Would METAR data be updated? Could/should the server provide METAR data and time? Yes. Would this cause an unacceptable interruption in player positional data? When the METAR data gets updated all 15 min. there shouldn't be much overhead. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
On July 17, 2005 08:08 am, Harald JOHNSEN wrote: receiver property tree using the c172p model root0\ |-position/* |-surface/* |-other properties 'player' 1 property subtree in receiver memory using a Concorde model root1\ |-position1/* |-surface1/* |-eof 'player' 2 property subtree in receiver memory using the ufo model root2\ |-position2/* |-surface2/* |-eof So on the receiver side the c172p.xml, concorde.xml and ufo.xml animation code point to the root0 property tree so all animations will reflect the receiver plane animations. An apparent simple hack is to change the root while rendering other 'player' models How about creating root-less nodes to act as seperated property trees for these aircrafts? This way, it will be easier to fool the animation files of these aircrafts into taking the proper values. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Ampere K. Hardraade wrote: On July 15, 2005 05:41 am, Erik Hofman wrote: Looking at the Multiplayer code I can see this code can use a good overhaul anyway. It needs to adapt the SGSubsystem style and use the AIModel code to display the models, which will also allow it to show up on the radar. It's probably not too much work to do since most of the current code could be reused. Erik I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. Properties under /position are basically what being exchanged right now. As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Might be nice to share the pos-norm type values, but of course this is eye-candy and should possible to turn off. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Vivian Meazza wrote: Harald JOHNSEN Ampere K. Hardraade wrote: [...]As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. Displaying an animated aircraft won't be easy. Animation code in xml file is refering properties from the FG property tree (ie the user property tree) so we need a way to change some properties during the rendering of a MP aircraft. Perhaps can we do this with a temporary aliasing in the tree so that some branches point to the MP aircraft ? Multiplayer models are already animated - gear goes up/down correctly. The problem is that all models are controlled by the receiving player, not the transmitting one. Shouldn't be too hard to fix. There is also some data/properties that can be guessed depending on the current 'action'. We can do a good guess of the different surface position for some standard manoeuvres. We can draw a smooth gear up/down animation without knowing the real value of /gear/gear[0]/position-norm for example, and if we were using this value it would be impossible to have a smooth animation because of the latency of the network. Is this the right approach? Could we include e.g. the gear up command in a message, and let the rx system sort it out? That's almost what happens now. Smooth transitions already happen, but, as I said, under the control of the rx player. In the future we could also consider to have one server handling all AI objects for the clients to have a coherent environment. Imagine that you are training landing on the Nimitz with your friends but the ship is at a different position on each client. This would be very weird. Very good idea, and weather. I don't suppose clouds would be easy? Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d And instead of simply substituting the glider for unknown aircraft, perhaps a slow gentle bittorrent like system could be implemented to share new models. I realize that this presents both bandwidth and trust problems of course. Another option would be for aircraft -set.xml files to include a url where they can be found, though these would be prone to becoming out of date. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
