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
[... 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!) transmit
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 ac
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 sing
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 m
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 Cy
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 &
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
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 gene
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, he
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
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 bottlene
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 defin
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.
--- 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 reli
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 fir
"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 loc
--- 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,
"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 essen
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.
Th
20 matches
Mail list logo
