Known bugs:

1) Map sizes and co-ordinates must be integers, although it accepts (and 
   rounds) floats. Note this applies to player input, the internal
   represenatation of things is in fact a float.

2) Intercept commands and routes tend to favor players that are first in the
blindrc file (or towards the begining anyway).

Why? Becuase, with the Intercept command, if I intercept you and vise-versa,
the player who is first in the blindrc file will intercept the later player
over his planet.....

Similarily, with routes, if we both have routes to a planet X for COL, 
and we both have cargoships of COL arrive at the same time, the first player's
COL will claim the planet....

Solutions:
  Well, we could randomly go through the list. Would this break anything?
Hmm. Interceptor A is going after B who is going after C who is going after A.
Code will send A to B, B to C, and C to A; leaving A & C at B's old location!
Random choice won't change the type of result, just the particulars.


3) #galaxy game "empire name" not handled  FIXED 2.46

4) Galaxy's with more than 1000 systems not handled correctly in forecasts
[fix seenlist to be automatically sized, rather than a constant]

5) CARRYOVER data is only updated when reports are generated. If you 
generate reports but do not save the blindrc file, the new tech levels do not
get saved. Note that this will also prevent you from doing A/H/W/K
commands on newly met empires, too in 2.47 and later versions.
Workaround: Always save the blindrc file after printing reports.
This will not affect the ability to regenerate future turn reports.

6) The blindrc file is not read or written to efficiently, nor is the data
stored in it done so. sorted list can go. We should probably use mmap
to blind in whole data file at once... Speed code is a temporary hack
along these lines. It does address the read performance (which is
important for forecasts).

7) Running out of disk space when writing a report or data file is
not correctly handled (I believe).

8) A determined player can find systems that have been renamed, and
make a good guess about which ones they really are. ninputplanet needs
to be made smarter about this problem. "Abuse" of this sort via S/I
commands has been resolved. N commands are not fixable without giving
each player a private namespace for systems.

9) Tokens (group numbers, ship components, names of planets/fleets/shiptypes) 
are truciated to MAXTEXT characters silently.

10) Some parts of the code assume that 0 == 0.0, which isn't true all
the time.

11) The code leaks memory. Purify is being used to trace some of these
down, however. I think I've got this down to load/save game related
areas, which are probably not actually leaks...

12) Players setting a password and changing their empire's name at the
same time are not correctly handled. FIXED 2.46

13) Players changing their empire name, when FCASTNAMES is defined,
and SMARTC is defined, will not get forecasts. candnphase() has this
code disabled, becuase otherwise it will add their new name once for
each set of orders they submit to the forecaster.....

14) Renaming of empires leaves cruft in the races:players file. If a
lot of renames happen and this isn't cleaned up, you will eventually
exceed MAXPLAY and get this error:
Breakpoint 3, candnphase () at turn.c:946
946           assert (idx <= MAXPLAY);
(gdb) 
turn.c:946: failed assertion `idx <= MAXPLAY'

Program received signal SIGSEGV, Segmentation fault.

Solution: clean up races:players, or increase MAXPLAY


15) MAXPLAY is used by the SMARTC command, even though it is a part of
the SPEED code.

16) Changing MAXTEXT can have unpleasant side effects- many strings
are MAXSTRLEN (256). If MAXTEXT gets too big (and no, I don't know off
hand how big that is), string buffer overruns become possible.

17) Irix5, NetBSD, FreeBSD and SPEED=1 do not work together.
