Hello James. Thank you for your extremely detailed response! I've taken time to respond to be sure that I had a chance to investigate much of what you talked about, though I'm still following the threads. I've come to the conclusion that, at minimum, people using the audio client won't be able to play on a typical public Netrek server. However, I'm now attempting to find ways to adapt game play without having to fork the server. I'd appreciate an answer on the following from anyone. If I decide that a particular feature is necessary to play with the audio client, can that be easily added as a configurable option on the server? As an example, suppose that the audio client games will need torpedoes that support some degree of automatic tracking. People obviously wouldn't want that in standard games. If torpedo tracking were a configurable option (meaning that I can set it without having to edit source and recompile), would it play nice with the standard clients? If a standard client joined a standard game, they would be notified that the server was set to use torpedo tracking? As long as people are notified if special conditions are in affect, then adding special conditions like this shouldn't be a problem. Right? Regarding the old speed setting in daemon.c, I might need that put back. *smile* Presenting map information in an audio client will be much slower, and so I'd need to be able to slow down games where audio clients are present. A question, though. What was affected by that old setting? Slowing down the speed of the physics in the game is all fine (motion of ships, speed of torps, etc), but does it also hopefully scale down the other time-based elements in the game (army growth time, repair speed, bombing speed, cloak time, etc)? All of those would need to slow down for the entire game to run at a slower pace. It seems like the clients have complete information about everything in the entire galaxy at once. If this is so, then there is probably some standard about how much should be revealed at any given time. Is it up to me as a client developer to restrict the tactical to a certain range, or to not allow players to know certain things about planets until they are close enough (some fog of war type situation)? I have some questions about the protocol, but those aren't strictly related to the audio client, so I'll start another thread for that. Bryan -----Original Message----- From: netrek-dev-bounces at us.netrek.org [mailto:netrek-dev-bounces at us.netrek.org] On Behalf Of James Cameron Sent: Thursday, March 18, 2010 1:35 AM To: Netrek Development Mailing List Subject: Re: [netrek-dev] Audio-based Netrek Client 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/ _______________________________________________ netrek-dev mailing list netrek-dev at us.netrek.org http://mailman.us.netrek.org/mailman/listinfo/netrek-dev