On Thu, 8 Oct 2009, James Turner wrote: > > That sounds bad :)
It is, but in my experience there is no core developer feeling particularly responsible for the MP subsystem - most of the few patches that has been submitted in the past years have disappeared into the mailing list archive without (re)action. > Eurgh, that sounds bad too. Well, it isn't ideal but it works for my purposes - without breaking MP compatibility and without me having to spend a large effort on developing something reasonable and more complete and then try for ages to get it committed to the code. These days I don't have time to do significant development, anyway, with work + commuting taking about 12 hours out of every day. > The 'usual' way to handle this would be to interleave the current > update packets with 'event' packets, for properties that change more > slowly. Using a sequence number for each event packet, and using the > regular update packets to send the current sequence number, it's > possible to make the event packet delivery reliable - without > incurring the overhead (or complexity) of TCP. Well, I would rather try to reduce what we send and mostly only send property values when they have changed. Currently every packet contains all (active) MP enabled properties - and many of them are constant or change very seldom. In that model a string property that rarely changes would not be a huge problem. Perhaps some type of publish-subscribe model could also be useful - so the receivers only receive the properties they care about (usually position and velocities and those driving external animations if within visual distance). Of course, this adds up to a rather sophisticated protocol so if some suitable existing middleware could be found that might be more preferable than trying to go our own way (certainly if one considers the current level of activity in this area:). > There's quite a lot of improvements that could be made to higher > levels of MP, if arbitrary properties could be synchronised over MP :) Yes, indeed. Cheers, Anders -- --------------------------------------------------------------------------- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel