There's a TODO message in multiplaymgr.cxx that says:
// A static map of protocol property id values to property paths,
// This should be extendable dynamically for every specific aircraft ...
This static list grows and grows and that's becoming a problem. I
hardly ever take part in MP, because the amount of incoming data
is just too big for my connection. And that's no surprise when
even an UFO sends rotor angles, gear compression, tailhook angle,
etc.
This problem is the cause why I decided to make /sim/model/variant
only an integer. But I agree very much with Syd that a string would
be much better, or rather with Anmaster, that several strings etc.
should be supported.
I'm not an fgms or MP expert, but as far as I've understood the
protocol is now relative simple. After an initial package containing
e.g. the aircraft path, all further packages always contain all
properties of the static list. There's no response from the clients
necessary.
But this method can't be continued ad infinitum. Only the absolute
minimum of data should be transferred, and this should be configurable
on a per aircraft basis. I could imagine these types of data, in
addition to the initial data package containing the aircraft path:
(1) properties sent in every package without expecting confirmation
(a) always sent
- position & orientation
- additional properties as configured by the aircraft
(b) like (a), but only start to send them after they changed to
a non-default value (zero/empty string) for the first time.
This can be predefined so that not every aircraft has to list
them all, but they wouldn't be sent when not necessary.
/gear/gear[0]/compression-norm
/rotors/main/rpm
(3) send initially and whenever changed until confirmed
(configurable by the aircraft)
/sim/model/foo/livery=Aircraft/foo/Models/Liveries/blue.rgb
Whether we can afford to transfer a livery path already with the
current system in place must be decided by the MP gurus.
m.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
