On Fri, 19 May 2006, William Balcerski wrote:
> > What are you talking about, observer sound?
> >
> I added in more sound support for observers (they can now hear shields
> up/down for the ship they are observing).  This is where the shield sound
> problem shows up with short packets on.  Oh and I forgot to mention one

This works fine in Paradise-2000, it must be a bug in your code.

> other pretty important thing.  All robots (iggies, practice robots) always
> show their shields being down when short packets = on, even if the robot has
> shields up.

I see the problem.  The short packets 2 flag sampling is turned off for robots
and for observers.  I see why observers is turned off, there is no reason to
tell other clients what observers are getting.  I'm not sure why it is turned
off for robots.  Can't think of any good reason.  Can anyone else think of

> > Short packets should be extended for more ship positions.
> >
> Agreed but how to make it compatable with older clients?

One way is to find some spare space in a packet and stuff it in there.  That
was done for a number of things, extra self flags and visible tractors are two
I can think of off the top of my head.

Another is to add a feature packet that turns it on.  Like I did for 19_flags.
Then you could modify a packet, VPlayer is the obvious example, to add more
bits of ship rotation.

There is also the short packets version, you could create short packets
version 3.  That is more work than a feature packet.

> > Short packets handle packetloss much better than old packets.  They provide
> > messages and warnings in a form which the client can do more with.  You can
> > get custom kill messages, phaser messages, planet take, and so on.  Short
> > packets reduce the network bandwidth to the server.  Short packets should be
> > considered the standard.  Old packets are just for backward compatibility.
> > Old packets should not change.  If protocol enhancements are desired, they
> > should be incorporated into short packets.
> >
> I'm all for making enhancements to short packets, but the impression I got
> was that it was a by design tradeoff - less information for less
> bandwidth, and that increasing the information in short packets (i.e.

Not at all.  Originally the client and server were both the ntserv program.
It was split into two programs, without changing the code any more than
necessary.  All the data structures between the client and server were the
same.  Then the most obvious, simplest protocol was used to send these
data structures from the server to the client.  No thought to bandwidth
or packetloss was given at all.

Then short packets was made as a real protocol.  It is supposed to send ALL
information a non-borg client can use.  It was never a design trade off to
send less information; it actually sends MORE information.

The original client only had 16 ship positions, so only an aim-borg would need
more.  Now clients have 32.  When I first added 32 ship positions to Paradise
2000, Niclas said it was borg.  Extra rotations!  Unfair advantage!  It only
shut him up when I told him Steve Sheldon had added it to his client much

I think adding a new feature to send 32 positions via short packets would be a
good idea.  I had been planning to do just that, when the netrek CVS went