G'day Bryan, There is torpedo target tracking in the server. Plasma torpedoes have a level of tracking that is standard. Ordinary torpedoes can probably have this tracking turned on through configuration of ship parameters in the etc/sysdef file. I've not checked recently. Enabling full tracking on a ship (which can be done using "xtkill SLOT sA") generates torpedoes that are useless for anything except random spraying. They turn toward the nearest enemy. Changes to the server can be negotiated in the protocol using the SP_FEATURE and CP_FEATURE packets. The client key "l" sends a CP_PLAYLOCK packet to the server, which causes the server to set flag PFPLOCK (not PFPLLOCK) and the ship navigates towards the selected other ship. Often used for docking to a base. Rarely used for locking on to a ship that you suspect may cloak, since the lock is retained after cloak is begun. Often used by new players to target an enemy in a way that allows the enemy to most rapidly kill them, since their vector is predictable and straight-on. The same client key is also used when observing; it causes the observing client to display the view as seen by the observed ship. The CP_PLAYLOCK packet is handled differently for server slots that represent observing clients. You should evaluate the code quality in Vanilla and Paradise before you pick one based purely on available features. We've worked hard to bring many features into the Vanilla code, as selectable options. I can't give you an opinion on Paradise code quality. I'm not aware of any other actively used server source apart from these two projects. No, my client does not currently work with Paradise, and avoids listing Paradise servers obtained from the metaserver. Regarding the technical question you had about how data from the server is processed: 1. client.py dispatches packets based on the packet type to server packet handlers (they all start with SP_ and are in __init__.py), 2. the server packet handlers then call into the model objects, such as galaxy, ship, planet, 3. the model objects call into the view objects, such as the ship and planet sprites to update certain details, 4. when the data from the server has apparently finished for the moment, the view objects, or sprites, are redrawn on screen, in PhaseFlight and descendent objects. The constructor of the server packet handlers creates a hash or dictionary which describes the packet lengths and handling function. The functions contain packet decoders using python struct semantics. You can find the pystruct stuff also in the server, in file include/packets.h ... this file also answers your question about protocol documentation; it's the best documentation we have, and it is kept in the code for rather obvious reasons of synchronisation. -- James Cameron http://quozl.linux.org.au/