Re: [Flightgear-devel] MP what data to send
[... Norman wrote ...] Andy Ross writes: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. [...] Yup.. using deltas should be a big win I have the impression you might want to have a look at IEEE 1278 alias DIS protocol - at least to steal some ideas, maybe to implement at least a subset. ACM has an implementation of this - it appears the source for the Unix version is released under the GPL. Have a look at (http://www.websimulations.com/download.htm) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Frederic Bouvier wrote: And what happens with deltas and positions when you will lose UDP packets ? How will you restore the correct position or orientation ? Perhaps, from time to time, it will be good to send absolute positions to resynch. Yes, this is a requirement. Sending unreliable deltas requires that there be a reliable transport for the value that the deltas are computed from. That was the idea behind the zone suggestion I made. The zone coordinate change packet would be sent rarely, and would require and ACK from the client and retransmition on failure. Blindly relying on the packets to arrive correctly and in-order is not an option*. Andy * Except on a local network. On a single physical network, the ethernet standards handle retransmission on collision for you, so packet loss at the IP level can be ignored. I'm not sure if this is true for ethernet derivatives like WiFi, though. -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Tony Peden wrote: Huh? The relationship between control surface positions and aircraft speed will, at the very best, vary considerably from aircraft to aircraft and, at worst, there will be no relationship at all (e.g ailerons, rudder) You can guess the the rough positions from the acceleration (which is derivated from the speed as we know). This guess will bequite inaccurate. But we don't care, as you'll only see that guess applied on aircraft over that you've got no control. So it only has to look reasonable, it doesn't has to be correct. Oh, and when you are that close in a multiplayer environemt that you can see the control surfaces of another aircraft move you're either refuling or in trouble... CU, Christian PS: I'm talking here about the elevator, ruder, ...; flaps and speed brakes are different as they change the bahviour too drastical -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
From: Christian Mayer [EMAIL PROTECTED] Norman Vine wrote: Andy Ross writes: But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like zip are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. Yup.. using deltas should be a big win Yes, but make sure that you deal with the precision loss smoothly. E.g. x-Position (in base 10), every 10 steps you'll transmit the real position and no delta: data data Source to transmit: transmitted: result: 1. 100.00 100.00 100.0 100.00 And what happens with deltas and positions when you will lose UDP packets ? How will you restore the correct position or orientation ? Perhaps, from time to time, it will be good to send absolute positions to resynch. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Frederic Bouvier wrote: From: Christian Mayer [EMAIL PROTECTED] Norman Vine wrote: Andy Ross writes: But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like zip are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. Yup.. using deltas should be a big win Yes, but make sure that you deal with the precision loss smoothly. E.g. x-Position (in base 10), every 10 steps you'll transmit the real position and no delta: data data Source to transmit: transmitted: result: 1. 100.00 100.00 100.0 100.00 And what happens with deltas and positions when you will lose UDP packets ? How will you restore the correct position or orientation ? Perhaps, from time to time, it will be good to send absolute positions to resynch. Just read what I've written. In my example I wrote every 10 steps you'll transmit the real position and no delta: which is the absolute position. You'll need that, not only due to the lost packages but also due to the precision loss My post was about how to handle the difference that occures between the absolute position and the position the other computer thinks where I am. This difference is caused by precision loss and lost packages. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MP what data to send
Status update on Multiplayer. We got our multiplayer-deamon up and running SunOS 4.7 and will port to current codebase to Linux (RH 7.3) and Cygwin(or VC++ 7) somewhere next week. Next step will be defining the protocols. Basic outline for first-time handshake should be finished by wednesday. The next question will be: 1)What information do you guys *really* want updates every data-packet send every 1/x second (x=20 atm, but changable) ? It has to be enough information to predict the next position(s) but not too much because we need to stay inside a 512BYTES(or 576 including headers) packet limit. 2)What information do you guys want updated every second ? (same limit applies here, but packets would just be appendable) 3)What API do you guys like for position prediction ? We scheduled the discussion for the entire next week, after that we will make up our minds and start implementing these things in our PROTOTYPE (no FG involved yet), just data-gathering/debugging client-server communication. Leon Otte __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
ace project [EMAIL PROTECTED] wrote: First question is what do you have in mind when you mean multiplayer. Supporting for example combat multiplay vs. GA multiplay vs. FSD multiplay are very different. For something like FSD, TCP is required. For something like combat multiplay, UDP is essential as performance is critical require minimal overheads. Btw, for you guys that do not know, FSD is the server software used by VATSIM and IVAO on their networks for hooking up ProController and SquawkBox clients. There are going to be changes to the FSD protocol spec (there are lots of ideas on the ProtoDev list being thrown around), but UDP for example will be a bad choice for running the FSD protocol. Next step will be defining the protocols. Basic outline for first-time handshake should be finished by wednesday. TCP, UDP, or a mix? 2)What information do you guys want updated every second ? (same limit applies here, but packets would just be appendable) Why 1 sec updates? This is over and above the 20/sec positional updates, right? For status changes (e.g. engine 1 off), I would think about sending it only when the status actually changes. Also, not using UDP but TCP. The receivers get the status change and then can (if they are able to) update the visual model to reflect the status change (engine 1's prop stop spinning). Each FG client should ideally also support a server command processing interface (either on the same TCP socket, or by running its own little TCP server). This will then allow the server to send client commands (e.g. push data down such as metar updates, tell the client to disconnect, etc.) 3)What API do you guys like for position prediction ? Position. Yaw, roll pitch. Speed. Climb rate. We scheduled the discussion for the entire next week, after that we will make up our minds and start implementing these things in our PROTOTYPE (no FG involved yet), just data-gathering/debugging client-server communication. Sounds good. Any plans for multicasting? -- Billy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
--- Billy Verreynne [EMAIL PROTECTED] wrote: ace project [EMAIL PROTECTED] wrote: First question is what do you have in mind when you mean multiplayer. Supporting for example combat multiplay vs. GA multiplay vs. FSD multiplay are very different. For something like FSD, TCP is required. For something like combat multiplay, UDP is essential as performance is critical require minimal overheads. We already decided on UDP, because we want to play over a unreliable latency connection (Internet). TCP has never been a option. We just want to see other players (and crash into them, if enabled) with a lot of ppl (or bots) inside the same area (for starters). We need this in our engine to simulate how a (auto)pilot should handle these situations. Why 1 sec updates? This is over and above the 20/sec positional updates, right? Indeed, they would only be changed when needed, but they won't been tweaked too much for performance. Position data would be tweaked to use 'delta-frames'. All packets will (hopefully) support compression using zlib. For status changes (e.g. engine 1 off), I would think about sending it only when the status actually changes. Also, not using UDP but TCP. The receivers get the status change and then can (if they are able to) update the visual model to reflect the status change (engine 1's prop stop spinning). Each FG client should ideally also support a server command processing interface (either on the same TCP socket, or by running its own little TCP server). This will then allow the server to send client commands (e.g. push data down such as metar updates, tell the client to disconnect, etc.) No client-server command interface is currently planned. All parameters should be set during system startup/initialisation. For the server we are considering the NOHUP signal approach, but I'm not sure its portable. (Win NT supports signals, but do Win9x/Macs ?) 3)What API do you guys like for position prediction ? Position. Yaw, roll pitch. Speed. Climb rate. We scheduled the discussion for the entire next week, after that we will make up our minds and start implementing these things in our PROTOTYPE (no FG involved yet), just data-gathering/debugging client-server communication. Sounds good. Any plans for multicasting? Multicasting was considered, but we are not ready for this yet. -- Billy __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
ace project [EMAIL PROTECTED] wrote: We already decided on UDP, because we want to play over a unreliable latency connection (Internet). TCP has never been a option. The only real problem with using UDP is when dealing with state or event data. For example, this guy have a missile lock on his friend and launches a AIM9 up his tail pipe. Only, the UDP packet carrying the missile gets shot down in a collission with some other packets, or is DOA. His friend flies happily along and while he screams abuse at the monitor, curses FG, slams the keyboard, kicks the dog and get arrested that night at the local pub for his agggresive behaviour. You want to carry that on your conscience for having UDP fail at such a critical moment on him? :-) Granted, FG is not a combat sim. But nor is X-Plane and I am already running into issues with X-Plane using UDP for event and status data. UDP simply does not gurantee delivery. And there are times I do not want to send and pray. We just want to see other players (and crash into them, if enabled) with a lot of ppl (or bots) inside the same area (for starters). We need this in our engine to simulate how a (auto)pilot should handle these situations. If the intention is just sending plain positional updates, then UDP is ideal. However, as soon as you start adding event and status data to the multiplayer environment, UDP is a problem. You want guaranteed delivery of that event or status change. All packets will (hopefully) support compression using zlib. At software level? I would be hesitant to do this myself. Compression and decompression can become an overhead and result in being the bottleneck, instead of network latency. As a multiplay configurable option, it makes a lot of sense. No client-server command interface is currently planned. All parameters should be set during system startup/initialisation. For the server we are considering the NOHUP signal approach, but I'm not sure its portable. (Win NT supports signals, but do Win9x/Macs ?) Signals on NT? Can not recall ever seeing in the Win32 API manuals that NT supports Unix style signals. After all, you can define your own WM_USER messages and use send, post and broadcast. The only signal thing in Win32 I can recall is a signal API call used for sync'ing processing (part of the mutex and semapahore group of API calls). Multicasting was considered, but we are not ready for this yet. Then maybe you should consider broadcasting as a configurable option. This is ideal when running it locally on your own dedicated LAN segment where the cons of broadcasting are not a major issue. -- Billy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
On Fri 12. July 2002 09:15, you wrote: Status update on Multiplayer. We got our multiplayer-deamon up and running SunOS 4.7 and will port to current codebase to Linux (RH 7.3) and Cygwin(or VC++ 7) somewhere next week. Next step will be defining the protocols. Basic outline for first-time handshake should be finished by wednesday. The next question will be: 1)What information do you guys *really* want updates every data-packet send every 1/x second (x=20 atm, but changable) ? It has to be enough information to predict the next position(s) but not too much because we need to stay inside a 512BYTES(or 576 including headers) packet limit. IMHO you need to send at least position,orienation,speed vectors, time mark and plane ID. Maybe also orientation changes. IMHO you can also send some control surfaces position, but this could be at lower rate. And you need to send also some state information but this should be done over protocol with guarantieed delivery (lights are on, gear is up, your airplane or missile colideded with airplaine ID, etc.) Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/martin1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
--- Billy Verreynne [EMAIL PROTECTED] wrote: ace project [EMAIL PROTECTED] wrote: The only real problem with using UDP is when dealing with state or event data. ... UDP simply does not gurantee delivery. And there are times I do not want to send and pray. UDP can be made reliable with a few tweakes. (prevent fragmenting by limiting size to 512 is just one of them) using message IDs is another, the overhead is about 1.5sec on a 500ping connection (we should make some arrangements to measure ping accuretly). All packets will (hopefully) support compression using zlib. At software level? I would be hesitant to do this myself. Compression and decompression can become an overhead and result in being the bottleneck, instead of network latency. As a multiplay configurable option, it makes a lot of sense. Ok, we'll make zip optional. We heard from a ID multiplayer programmer that the overhead was minimal compared to the profit gained (bigger packet, better support for low-bandwidth connections). We will just test how much time it takes to zip a packet ask yourselfs whether its worth it. ... Then maybe you should consider broadcasting as a configurable option. This is ideal when running it locally on your own dedicated LAN segment where the cons of broadcasting are not a major issue. ok, broadcasting optional. I only have no way of testing it thoroughtly, I'm not allowed to have 5+ computers broadcasting at this site :( -- Billy b.d.w., Thanks for the feedback so far Leon __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
ace project wrote: All packets will (hopefully) support compression using zlib. At software level? I would be hesitant to do this myself. Compression and decompression can become an overhead and result in being the bottleneck, instead of network latency. As a multiplay configurable option, it makes a lot of sense. Ok, we'll make zip optional. We heard from a ID multiplayer programmer that the overhead was minimal compared to the profit gained (bigger packet, better support for low-bandwidth connections). We will just test how much time it takes to zip a packet ask yourselfs whether its worth it. I don't know if zipped packages help much for the kind of data you are sending. You can only compress redundant information (like many zeros oder ASCII text that consists only of a few different bytes and has repeasting structures like and). When you are sending lots of different floats or doubles it'll look to zlib like lots of random data. And random data doesn't compress - it'll even require more size when it's zipped. So you might decide *which* data you are compressing. Floats won't work well (i.e. position, speed, orientation, ...). But the chatting between the pilots and traffic controll might benefit.(*) CU, Chritstian PS: If it's done right by storing compression-dictionaries on each system you can get very good compression rates, but I dunno if zlib supports it. -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Martin Dressler wrote: On Fri 12. July 2002 09:15, you wrote: Status update on Multiplayer. We got our multiplayer-deamon up and running SunOS 4.7 and will port to current codebase to Linux (RH 7.3) and Cygwin(or VC++ 7) somewhere next week. Next step will be defining the protocols. Basic outline for first-time handshake should be finished by wednesday. The next question will be: 1)What information do you guys *really* want updates every data-packet send every 1/x second (x=20 atm, but changable) ? It has to be enough information to predict the next position(s) but not too much because we need to stay inside a 512BYTES(or 576 including headers) packet limit. IMHO you need to send at least position,orienation,speed vectors, time mark and plane ID. Maybe also orientation changes. IMHO you can also send some control surfaces position, but this could be at lower rate. Most of the control surface positions can be guessed by looking at the accelerations (determined from the speed vectors), so we can save that bandwidth. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
ace project wrote: --- Billy Verreynne [EMAIL PROTECTED] wrote: All packets will (hopefully) support compression using zlib. At software level? I would be hesitant to do this myself. Compression and decompression can become an overhead and result in being the bottleneck, instead of network latency. As a multiplay configurable option, it makes a lot of sense. Ok, we'll make zip optional. We heard from a ID multiplayer programmer that the overhead was minimal compared to the profit gained (bigger packet, better support for low-bandwidth connections). We will just test how much time it takes to zip a packet ask yourselfs whether its worth it. Which reminds me. About two years ago I had some interrest in a *very small* real-time compression algorithm I saw on freshmeat.net It has absolute real time (small memory footprint) decompression and semi-realtime compression (if I recall all that correclty). Sadly I don't have the link anymore. Have to search for it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Christian Mayer wrote: I don't know if zipped packages help much for the kind of data you are sending. You can only compress redundant information Amen. He speaks the truth. But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like zip are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. + Orientation can be very crude -- the eye has trouble telling degree differences less than 5 degrees or so. That means that the whole orientation can fit in something like 11 bits with creative packing (consider quantizing a 4D sphere of 2048 quaternion points and picking an 11 bit encoding for them). With a little extra work, you can transmit a zone as above, to get constant orientations (approach AoA's, for example, that the eye could tell are wrong if it looked carefully) exactly right. + Likewise, velocity needn't be terribly accurate so long as it is retransmitted regularly. No more than +/- 5 knots or so is fine for updating the position display. If you need more accuracy for ATC purposes or whatnot, that can be done with a different packet much less often. + Rotation rate, linear acceleration and rotational acceleration can be skipped entirely. These values are useful only to an FDM, or perhaps to a cockpit interface. Simply display them using a time-interpolation of the values you already have. The eye won't be able to see the errors unless the update rate is very slow. + If you really want to be macho, you could investigate fixed huffman encodings for the different values. Position changes are more likely to be horizontal than vertical. Typical velocities are very likely to be near the nominal cruise speed of the aircraft. Upright orientations are more common than inverted ones, etc... This could probably get you another few bits per value, on average. But usually this isn't worth it. It optimizes the common case, but often makes the interesting cases (say, a dogfight) perform worse. Most users are going to want better performance in the interesting situations. Most of this probably isn't worth it. But it's kinda fun stuff to think about if you really need to pack those bits in. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Erik Hofman wrote: Which reminds me. About two years ago I had some interrest in a *very small* real-time compression algorithm I saw on freshmeat.net It has absolute real time (small memory footprint) decompression and semi-realtime compression (if I recall all that correclty). Ah, here it is: http://www.oberhumer.com/opensource/lzo/ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] MP what data to send
Andy Ross writes: Christian Mayer wrote: I don't know if zipped packages help much for the kind of data you are sending. You can only compress redundant information Amen. He speaks the truth. But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like zip are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. Yup.. using deltas should be a big win You should probably take a look at how this is handled by SEDRIS http://www.sedris.org Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Norman Vine wrote: Andy Ross writes: Christian Mayer wrote: I don't know if zipped packages help much for the kind of data you are sending. You can only compress redundant information Amen. He speaks the truth. I had to proofe it as homework once :) But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like zip are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. Yup.. using deltas should be a big win Yes, but make sure that you deal with the precision loss smoothly. E.g. x-Position (in base 10), every 10 steps you'll transmit the real position and no delta: data data Source to transmit: transmitted: result: 1. 100.00 100.00 100.0 100.00 2. 100.12 .12 .1 100.10 3. 100.24 .12 .1 100.20 4. 100.36 .12 .1 100.30 5. 100.48 .12 .1 100.40 6. 100.60 .12 .1 100.50 7. 100.72 .12 .1 100.60 8. 100.84 .12 .1 100.70 9. 100.96 .12 .1 100.80 10. 101.08 .12 .1 100.90 11. 101.20 101.20 101.2 101.20 so we've got a big jump of 1.2 (the users expects 101.00 and gets a 101.20). Just letting the plane jump is a bad solution. You should interpolate, e.g. by using the following formula: position (at steps 11 to 20) = position of the step before + transmitted position + (data transmitted at step 11 - data transmitted at step 1) / 10 CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] MP what data to send
Check out 'minilzo' for fast lightweight compression. My testing shows that compression is about 1/8 memcpy speed and decompression is about 1/3 memcpy speed. And, it compresses tight. http://www.oberhumer.com/opensource/lzo/ Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: Erik Hofman [mailto:[EMAIL PROTECTED]] Sent: Friday, July 12, 2002 10:39 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] MP what data to send ace project wrote: --- Billy Verreynne [EMAIL PROTECTED] wrote: All packets will (hopefully) support compression using zlib. At software level? I would be hesitant to do this myself. Compression and decompression can become an overhead and result in being the bottleneck, instead of network latency. As a multiplay configurable option, it makes a lot of sense. Ok, we'll make zip optional. We heard from a ID multiplayer programmer that the overhead was minimal compared to the profit gained (bigger packet, better support for low-bandwidth connections). We will just test how much time it takes to zip a packet ask yourselfs whether its worth it. Which reminds me. About two years ago I had some interrest in a *very small* real-time compression algorithm I saw on freshmeat.net It has absolute real time (small memory footprint) decompression and semi-realtime compression (if I recall all that correclty). Sadly I don't have the link anymore. Have to search for it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
On Fri, 2002-07-12 at 09:34, Christian Mayer wrote: Martin Dressler wrote: On Fri 12. July 2002 09:15, you wrote: Status update on Multiplayer. We got our multiplayer-deamon up and running SunOS 4.7 and will port to current codebase to Linux (RH 7.3) and Cygwin(or VC++ 7) somewhere next week. Next step will be defining the protocols. Basic outline for first-time handshake should be finished by wednesday. The next question will be: 1)What information do you guys *really* want updates every data-packet send every 1/x second (x=20 atm, but changable) ? It has to be enough information to predict the next position(s) but not too much because we need to stay inside a 512BYTES(or 576 including headers) packet limit. IMHO you need to send at least position,orienation,speed vectors, time mark and plane ID. Maybe also orientation changes. IMHO you can also send some control surfaces position, but this could be at lower rate. Most of the control surface positions can be guessed by looking at the accelerations (determined from the speed vectors), so we can save that bandwidth. Huh? The relationship between control surface positions and aircraft speed will, at the very best, vary considerably from aircraft to aircraft and, at worst, there will be no relationship at all (e.g ailerons, rudder) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
