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 one? > > 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 earlier. 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 down.