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.


Flightgear-devel mailing list

Reply via email to