$Id: BUGS,v 3.38 1994/03/09 19:56:15 bert Exp $

#
# Each bug has its unique number and some additional info.
# The <BUG> field has the number (this marks the start of the bug entry).
# The <STATUS> field can be: open|fixed|unconfirmed|deferred
# Additionally, one may have an extra /-separated priority modifier
# (low|medium|high), for example: <STATUS>open/medium.
# The <VER> field is the version the bug was reported against.
# The <DESC> field holds the person (+email) who reported the bug
# plus the description of the bug.
# The <WORK> field reports progress made on fixing it
# (same format as <DESC>).
#
# The six digit dates used here are in yymmdd format for easy sorting.
#
# When refering to bugs one may use B+<the bug number>,
# i.e. B001 refers to the ball-string bug.
#

<BUG>	001
<STATUS>open/low
<VER>	2.0
<DESC>	kenrsc
	The ball-string has doesn't take heavy tension, it produces wild,
	lethal occilations.
<WORK>	kenrsc
	What to do we do with this one. My suggestion is to drop
	the ball when the string stretches too far. What is yours?
<WORK>  930919: bert
	I don't see this bug as a problem.  When manouvring the ball
	the player should take care not to have it oscillate too strong
	or the player should find a way to reduce to oscillations.
	But I may not have seen the effect this bug refers too.

<BUG>	002
<STATUS>open/low
<VER>	2.0
<DESC>	bjoerns
	Ball should be affected by object collisions. 

<BUG>	003
<STATUS>deferred/low
<VER>	1.2
<DESC>	unknown
	Players can fly through walls at high speed, this isn't the case for
	objects (they use different collision detection methods).

<BUG>	004
<STATUS>open/low
<VER>	3.0.4
<DESC>	930900: kenrsc@stud.cs.uit.no
	Limited lives.  New human players are dead when entering a game
	where somebody has lost a life. This is not true for robots.
<WORK>  930915 kenrsc@stud.cs.uit.no
	Bert did you not change it so that if robots where left in the game
	it would start over again ? If so, does it do anything harm having
	the robots entering. Lowered the status to low since robots wont
	join in to often.
<WORK>  930919: bert
	I don't expect that adding more robots will be a problem.
	If only robots are alive then they have won the game and the
	game resets.

<BUG>	005
<STATUS>open/low
<VER>	2.0
<DESC>	930900: kenrsc@stud.cs.uit.no
    	The treasure is not correct. Sometimes the ball disapears for
	good.  There are also other things, but I don't remember now.

<BUG>	008
<STATUS>open/low
<VER>	3.0.3
<DESC>	930912: chc@dale.ksc.nasa.gov (Charles Curley)
	Has anyone else noticed that on when you get near the edge of a
	wrapped map that you can't shoot when you nose is within say 20
	pixels of the edge?
<WORK>	930912: bert
	The problem is that when the center of a player is close to the edge
	then the expression "shot->pos = pl->pos + ships[dir].pts[0]" may
	result in a value bigger than the mapwidth/height.

<BUG> 	011
<STATUS>open/medium
<VER>	3.0.4
<DESC>	930930: Charles Curley (chc@dale.ksc.nasa.gov)
	Cloaks don't seem to work sometimes.  Mostly with three of more
	people we will have a situation where some players can see
	others all the time regardless of the others cloak situation.
	eric@soda.berkeley.edu (Eric van Bezooijen):
	We here have also noticed the cloak problem.  We are running
	everything on Solaris 2.x on Sparc-boxes.  It is quite rare,
	however.  It is just like he describes.  Once in a while there
	will be a player playing who I can always see, regardless whether
	or not he has cloaking or not, with dashed lines around his ship...
<WORK>	931001: bert
	Had a thorough look at all of the visibility code and made
	a possible fix.  The updateVisibility flag is now explicitly set
	when a player reenters the game.  It appeared that the lastChange
	flags in the player visibility structure were nowhere initialised.
<DESC>	931007: Jonathan Katz (jonathan@cad.ucla.edu)
	There seems to be a bug in the current release (3.0.5)
	and the last couple) that allows usually a pair of people
	on our server to be unable to cloak from each other.
	The cloaked individual will be 'ghosted' but visible....
	Also they will show up on the world map and radar...
<DESC>	931011:  Gary O'Brien <gary@hpmtlgo.lvld.hp.com>
	We're using xpillot 3.0.5 on HP 700 series.  We still have the
	cloak bug problem.  We see the problem if there are more than
	2 human players in the game.  The general rule is if your cloaked
	and can see them, then they can see you.  A player which is cloaked
	and not visible cannoot seee you either.

<BUG> 	014
<STATUS>open/low
<VER>	3.0.5
<DESC>	931005: Mark Boyns
	I have a problem with robot's Ids disappearing.  Sometimes I will see
	a robot flying around without a name.  The problem seems to be sort
	of random, and I have not spent any time trying to figure out why.

<BUG>	017
<STATUS>open/medium
<VER>	3.0.6
<DESC>	931125: bert
	There is a problem with the client getting corrupted frame updates.
	In a frame update the `loops' variable is printed twice.
	Once at the start of the frame and another time at the end of the
	frame.  The problem is that the client prints that the first value
	differs from the second value and therefore that the frame is
	corrupted and ignored.
	The second value is always the corrupted one.
	I would like to know if this is due to a bug in the sound packet
	code or not.  I.e., does a non-sound client experience this only
	with sound-packet-sending servers or with all servers.
	The sound packets are printed at the end of the frame, therefore
	that might (?) be a possible cause of this problem.

<BUG>	018
<STATUS>open/medium
<VER>	3.0.6
<DESC>	931210: ferhati@aremihp.univ-lille1.fr (Ramdane FERHATI)
	In the maps where there are no team bases, and you specify
	team play, nobody can join the server.
	I propose that the server randomly choses a team number for
	each non-team home base when in team mode.
<WORK>	931210: bjoerns
	At least, the server should warn about this condition.

<BUG>	019
<STATUS>open/medium
<VER>	3.0.7
<DESC>	940113: ferhati@aremihp.univ-lille1.fr ( Ramdane FERHATI )
	In a team mode, if you are in pause mode
	and the other team blow up all your targets
	you automatically quit the pause mode,
	the "P" character is still  before your nick name.
	You must press twice the "P" key to return on
	the pause mode.
<WORK>	940115: bert
	I think I know where to look for a fix (collision.c, targetKillTeam).

<BUG>  021
<STATUS>open/medium
<VER>	3.0.7
<DESC>	940309: Tony Plate <tap@cs.toronto.edu>
	Suppose we have 3 players, A and B, on one team, and X on the other.
	This is how the bug manifests itself (I think):
	    A is locked onto X.
	    X is locked onto B.
	    A fires a smart at X.
	    X ECMs the smart, now it locks onto B.
	    Smart chases B, but can never hit B, because B is
	    immune to this smart because it was fired by a
	    team member.
	My suggestion: change effect of team immunity so that it
	applies only to simple shots.  (Would be a pretty simple fix).

