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