ace project writes: > Ok, here is the summary: > > This will be a engine for gaming, not 'pure' > simulation, thus only visible charateristics are > considered. > > Protocol will be UDP, it has the follow > charateristics: > - unreliable, will be fixed by ACKS,packet numbering > and timeouts > > - Position (delta) updates will (atleast) be 20 > upd/sec, this can be set.
If an aircraft is flying a relatively consistant speed/direction, you could get by with far fewer than this. The local end can send a starting set of position, velocity, acceleration. The remote end can then predict future movement accurately for the short term. The local end can also run the same prediction algorithm based on the same data that it has sent to the remote end. When the 'predicted' value becomes different enough from the actual value, the local end can send new data. This is a higher level way to 'compress' the data and reduce redundancy. It would be a bit more work to impliment, but could save a *huge* amount of bandwidth. > > - Full position update every sec, after that we will > tweak them some further. > > - Other 'non-essential' ones will be set when needed > > - We are still thinking about how to use deltas best, > so lets discuss this further... > > - Compression will be optional, both > zlib(http://www.gzip.org/zlib/) AND lzo > (http://www.oberhumer.com/opensource/lzo/) will be > implemented to test their impact. > May the best system win !(remember, this is a > prototype, no user will ever see this version !) > > - There wil be NO client-server interface AT THIS TIME > (and don't want ppl hacking my server) > > - Multicasting and broadcasting will NOT be in this > prototype, but base protocol should be able to handle > broacasting (without any change with current specs) > > - Variables put forward at this time are: > position (GPS+altitude only ?), roll, pitch, speed, > climb rate, orientation, time mark(why? should > sequential numbering at high rate accomplish the > same?) > More exact (the actual variables) are appriciated to > take away and uncertaties. > > - Another question popped up, what Endian do we want ? > > TCP/IP-protocol wants Big Endian, most of the Flight > Gear PC's are little Endian, what will it be... > > - I will post the encaptulation protocols tommorrow, > when I have translated their essence to English (they > are in Dutch atm, anybody wants them in Dutch ?) > > - There is another totally different design possible > (as long as the players dont interact with each > other!) > Delayed transmission, delay EVERYBODY 1 sec and the > will all they exactly 1 sec out of sync. I dont think > its the way to go, but its worth mentioning it. > > BTW, the reply of Andy Ross (with the +'es) needs > further discussion, he has a good point. > > BTW 2, don't look at typos, English is *not* my > primary language :) > > __________________________________________________ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes > http://autos.yahoo.com > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
