Ok I'm going to attempt to list and analyze some features I'd like added
to Vanilla.  Let's start with the most pressing one:

1) Ship headings to 256 with SP2
Current ship headings are only sent to 16 positions with SP2.  All modern
clients use 32 position bitmap sets, and my client uses 256 position
bitmaps.  Ship headings are sent to 256 positions with long packets on -
this is the last major holdup for me to have my client use short packets
as default.  Please please Trent could you do this one, I'd do it myself
if I could make sense of short packet code.  You are the expert for sure.

Pros: support for modern bitmap sets, better looking ship turns, full
support for client bitmap rotation
Cons: are there any?  Can one argue more accurate ship headings gives an
unfair advantage in dogfighting?

2) Ability to bomb enemy 3rd space planets in your T-mode opponent's space
As often happens in T-mode games these days, there is some 3rd space
action, and often planets of the main 2 races get taken by a 3rd race.
These planets then become unbombable by Team B, if the planets are in Team
A's space, even though A and B are T-mode opponents.  In the worst case
scenario, team B can take all of team A's planets, but not be able to win
due to a 3rd space planet in team A's space that is full of armies and
unbombable.  Solution is to add some sort of variable that keeps track of

Pros: Minimizes impact of 3rd space activity in T mode game.
Cons: Can't think of any

3) Have server send info on torp and plasma fuses
If a player can see the torp/plasma fired, knowing the fuse times of the
various ships, and assuming no packet loss, he can pretty accurately
predict when a torp or plasma will run out.  Thus, I don't think it would
be too borgish to have server send this info (but only for torps fired on
screen, off screen torps from distance plinking should not have fuse info
sent).  The main reason I would like this is to determine the "newest"
torp for sound purposes - right now, if there are 20 torps on the screen,
I can't tell which one to play the torp sound for.  2 clients (NetrekXP
2006 and Paradise 2000) now have 3d sound - this would help make the sound
events more accurate.   It's the same for plasma, but it's a much bigger
deal for torps.

Pros: Accurate sound reporting for 3d sound clients
Cons: Possible borgish behavior to make torps visibly fuse out as they
reach end of life cycle, perhaps by blinking?  Of course, any clued player
will pretty much know when a torp is going to expire anyways.

4) Have SP2 send p_whydead to observers
Currently, when there is a genocide, observers get sent to team select
screen with an unknown p_whydead (it equals 0).  Once there, observers
then begin to get the right p_whydead info from server.  This causes 3
problems (at least for my client).  One, the observer gets wrong death
message on motd window.  Two, observer doesn't get the geno bitmap that
display on a geno.  Three, if observer rejoins game with new conquer code,
and then quits at some later time, he sees the geno bitmap (because his
p_whydead is still KWINNER).  Solution would be to add observer support to
sndSSelf packet (I think).

Pros: correct behavior for observer geno situations.  Also, added bonus of
maybe having an observer get info on how his observee died (perhaps having
a message flash across screen that describes the p_whydead state of his
Cons: extra bandwidth for observers in SP2 mode

5) Have server send estimated repair time to players in repair mode
It's currently possible for the client to calculate the estimated repair
rate by mimicing server code, and server defines (such as repair bonuses
for repair planets/bases, and ship defined repair rates).  However, there
are several issues.  One, observers don't get war/hostile info on planets,
so if their observee if at peace and orbitting a repair planet, the client
can't mimic server code calculating repair rate - it has to make an
educated guess as to whether that ship is at peace.
Of course, one could make a much more complex system to determine repair
rate, by tracking sequential packets to determine an average repair rate
empirically.  This system would need a lot of conditionals to work right.
Certain ships repair faster than others, and it may not be possible to get
an accurate repair rate for slow repairing ships, within the first second
or two of repair.  Secondly, damage taken to the ship while in repair mode
has to be taken into account from the repair rate averaging.  Thirdly, in
the case of constant damage (i.e repairing in range of an enemy planet
which slowly damages your ship) it may be quite hard to make sense of the
sequential changes in hull damage to get a repair rate.  My opinion is the
best way is to have the server send the information.

Pros: Eliminates a lot of client side copying of server code, guesswork
and/or laborious data tracking to get the repair rate
Cons: Client can sort of back calculate the repair rate already (with

6) Have server send info on what planet you are orbitting
Currently, server will tell you that you are orbitting, but not what
planet you are orbitting.  I can envision several uses for this
information.  The client could perhaps have a little popup box that shows
a zoomed version of planet (on the galactic map) when you orbit.  Also, if
client is going to calculate repair times, it needs to know if you are
orbitting a repair planet or not.

Pros: Allows future client features
Cons: Client can sort of get this information already by finding closest
planet to your x,y loc.  Works in all situations except if planets move
and are almost on top of each other

Enough food for thought I hope.