We really need to look at an the best way of doing this. Once the
multiplayer code is changed we will probably be stuck with is for the next
few years. Getting it right is fairly important.
We shoud consider what we want in terms of features, flexibility and numbers
and then find the most efficient way of achieving it.
While recycling code might be easier, remaking all of the code is a lot less
restrictive. Both have pros and both have cons, it is would be nice if we
could find the most beneficial way of doing it.
Cheers,
Mostyn
****************
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:
> 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
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
