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
