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
