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 T-mode. 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 observee). 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 limitations) 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. Bill