On Wed, Sep 26, 2001 at 08:20:32PM -0500, Darryl Palmer wrote: > > It appears that commands sent from the players modify the shared memory > immediately and there is no mutex or semaphore controlling access to it. Yup. It's important to note the order in which the server (daemonII) and the subservers (ntserv) access shared memory. The daemon synchronization essentially tries to work around the racing conditions by letting daemonII read/update/modify the shared memory first, then waking all the ntservs (which do not have racing conditions against each other, for the most part) so that they may read/update/motify the shared memory afterwards. Presumably all the ntservs complete their critical work before daemonII wakes up again to repeat the process. Quite clever at the time it was designed, but there are known problems that do occur due to the lack of semaphores. > The second question is concerning the fuel update routine. It appears to > be flawed in some rare cases. When a player is at warp 6 while cloaked > and runs out of fuel in a CA, the routine correctly disengages the cloak > and keeps the player at warp 6. If the player is at warp 9 while cloaked, > it appears that the routine incorrectly sets the players speed to warp 5 > and decloaks him. Isn't the player still supposed to be at warp 6 because > this is where the energy output equalizes his expenditures? These are bugs that eventually turned out to be features. You'll notice that you can spam maxwarp when you're out of fuel to gain (effectively) another half warp or so of speed. Players have created all kinds of clever "clueful" skills or strategies based on what are essentially minor bugs. -- Dave Ahn | ahn at vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2