ChangeLog

---  HackNet changelog
---  -----------------
---  
---  Daily entries, with more recent days on top.  Multiple checkins
---  on a single day are generally separated by blank lines, with the 
---  most recent checkins at the bottom.
---

November 10, 2002:
  * ENT_Definition.cpp/.h:  Integrated NetHack's monster database
    into HackNet.  Not actually being used for anything yet, but
    it's there!  I've raised the code style issue of whether
    enumerated values should be of the form CLASS_Value or
    Class_Value.  I find Class_Value to be more easily readable,
    and so am likely to convert old code to the new format.
    (Object code was already written this way).
  * HN_Color.h:  Standard color #defines have been moved here, for
    use on both server and client side.

November 9, 2002:
  * General:  It's been a long time, but life has finally slowed down
    again, and development has resumed!
  * OBJ_Definition.cpp:  Updated to use the object list from
    NetHack 3.4.0.  Several objects have been removed from the list
    temporarily, as NH3.4.0 modified their object structure, and rather
    than update ours, I've just removed the objects affected.  This will
    be fixed up within the next few days, when I update our object
    classes to include the new data in 3.4.0's objects.
  * HN_Display.cpp:  Fixed a bizarre client-side bug which caused 
    the client not to realise when it needed to attack instead of
    move.  I can't imagine how this bug slipped in.
  * OBJ_Definition.cpp (later):  Sigh.  Senility comes early this
    year.  Actually, there were no changes in object structure in the
    update to NH3.4.0;  I had just forgotten some changes that I made
    to the NH3.3.1 object list while integrating it into HackNet.  I've
    fixed things up so those changes don't need to be made again --
    future object lists should be quite easily imported.
  * OBJ_Food.cpp/h:  Added to source control
  * ENT_Base.cpp:  Added ability to eat
  * HN_Player.cpp:  Added ability to receive eat commands
  * HN_DisplayTTY.cpp:  Added ability to send eat commands.  Also fixed
    things so that in eat and drink commands, appropriate messages are
    given to the player if they don't have anything to eat or drink.
  * Released version 0.0.6.  Updated version number to 0.0.7
  
April 6, 2002:
  * HN_DisplayTTY.cpp:  Added mutex to protect 'Refresh()' function
    from being called by the TTY's network and io threads simultaneously.
    I'll have to double-check, but I believe this is the only code and
    data that both threads access.  And I highly doubt that ncurses
    is (or could be) thread-safe, anyway.
    
February 28, 2002:
  * ENT_Base.cpp: More potion effects added.

February 24, 2002:
  * ENT_Base.cpp: Moved potion effects into entBase::DoEffect().
  * OBJ_Potion.cpp: Now calls entBase::DoEffect() to perform
    potion function.  This means that all effects from potions
    and scrolls are now located in one place, which means that
    it'll be just a simple data change to add (for example) a scroll
    of extra healing to the game, if someone should take it into
    their heads to do so.
  * HN_DisplayTTY.cpp: Fixed accidental sending of 'drop' packet
    immediately after each 'quaff' packet.  (Missing 'break'
    statement in a switch statement)

February 20, 2002:
  * HN_DisplayTTY.cpp:  Fixed to use default background colour instead
    of forcing black.
  * ENT_Base.cpp:  Now properly sends 'destroyed' text messages instead
    of 'hit' text messages when a player or monster is killed.

February 14, 2002:
  * Added hnRandom to common directory, to abstract out random number
    generation.
  * Added 'properties' for all potion types (will eventually need to
    do this for scrolls and some other object types), so we don't need
    to use a massive set of #defines to match object types to their
    position in the master object definition table.
  * More minor modifications to quaff support.
  * HN_Status.cpp:  Now stores all statistics in an array, instead
    of as separate member variables.  Need to do something similar
    for hit points and spell points.
  * ENT_Base.h: Removed hit point member variables -- that's what
    the hnStatus was for.
  * ENT_GridBug.cpp:  Sets initial health on hnStatus, instead of
    in unused hit point member variables.
  * Beginning support for exercising statistics.
  * Fixed numerous bugs with killing players.

February 12, 2002:
  * Added objRing and objAmulet classes.
  * Makefile.am: Reorganized for easy maintenance.
  * objRing and objAmulets can now be put on/removed.
  * Added objPotion.
  * Added initial quaff support.

February 10, 2002:
  * OBJ_Armour.cpp/.h: Added to CVS.  Implemented SetWorn()
  * OBJ_Manager.cpp: Create correct class based upon object type.
  * OBJ_Base.cpp: No longer allow non-armour to be worn.
  * OBJ_Types.h: Added Wearable, Wieldable, and Legal flags to object flags
  * Modified ttyclient to display only objects wearable and wieldable bits
    in inventory list for 'wield', 'wear', and 'take off' commands.
  * Modified server to disallow dropping worn items.  Sends text message
    to client if client sends an illegal request (such as trying to drop
    a worn item.. the client should be able to detect this, and not trouble
    the server with such obvious mistakes!)  TODO: modify the client to
    be able to detect this, and not trouble the server with such obvious
    mistakes!

February 9, 2002:
  * HN_Player.cpp: Switched to delta-based inventory updates.
  * NET_Server.cpp: Added missing 'break' statement to delta-based
    inventory update packet handling.
  * Added basic wear/remove functionality.

February 7, 2002:
  * Switched objects to use flags to store wielded/worn status, instead
    of having clients store a 'wielded' item id number.
  * HN_Client.cpp: Added function to return inventory-style item text.
  * Moving toward capability of sending individual inventory item
    updates, instead of having to resend the whole inventory every time
    something changes.

February 4, 2002:
  * Proper line-of-sight code, at last!  Using shadowcasting code,
    adapted from Greg McIntyre's SDL FOV demo, who in turn took
    the algorithm from Gordon Lipford.  Thanks to everyone involved!
  * More fixes to properly generate objects of appropriate types.
  * HN_ClientTTY.cpp: Made wands appear in object lists.
  * OBJ_Registry.cpp: Made rings get the right names.

January 7, 2002:
  * Imported all remaining NetHack items into HackNet.  (There seems
    to be a bug involving item creation probabilities)
  * Modified TTYClient to display correct names for items which aren't
    fully named (scrolls, etc)

January 6, 2002:
  * My birthday -- celebrated by doing more coding. (I really need to
    sort out my priorities!)
  * OBJ_Definitions.cpp: Added NetHack bows, missiles, and armour.
  * OBJ_Convert.h: Additions to support the above.
  * Added ability to unwield objects by wielding '-'.  (UI incomplete)
  * TTYClient: Now displays correct symbols for objects.
  * OBJ_Type.h: objDescription struct's "type" field is now actually
    used for the 'objType'.. that is, Weapon, Armour, etc.  To find
    out exactly what the object is, the 'itemID' must be examined.
    (So what used to be called 'type' is now 'itemID')  This required
    some big changes in other files, but was the easiest fix for this
    old problem.

January 4, 2002:
  * Returned to development after long break for RL purposes (moving,
    busy work, etc).
  * OBJ_Convert.h: Added header to convert NetHack-style object
    declarations to HackNet's format.
  * OBJ_Definitions.h/.cpp: Added NetHack's full weapon list to
    HackNet.  Obviously, thrown weapons don't work properly yet.

August 3, 2001:
  * HN_Player.cpp: Fixed old bug which caused inventory to be re-sent
    with every move, instead of only when it changes.

July 29, 2001:
  * Added first pass at NetHack-style entity definitions.  I'm still
    not certain that this is how I actually want to do this, but it's
    better than the previous method.. even if it's now ripped almost
    verbatim from the NetHack codebase!
  
July 23, 2001:
  * Removed debug output accidentally left in HN_Game.cpp

July 22, 2001:
  * Changed object system again -- it was obvious that there was going
    to be massive class glut using the old object hierarchy.  Instead,
    we'll now have a much smaller hierarchy of object classes, with
    'prototype' data used to instantiate particulars.
  * Static declaration of objects in OBJ_Types.h has been removed, and
    the header file is now used for declaring common types of objects.
    As long as this file remains the same, a particular client should
    be able to connect to any server, even if servers add or remove
    objects.
  * Object definitions (in a VERY crude form) are in OBJ_Definitions.cpp
    at the moment.  Will set up some macros to make them easier to
    create.
  * Modified the 'a/an' rule slightly in OBJ_Registry.cpp.
  * Added a couple more weapons to OBJ_Definitions.cpp.
  
July 16, 2001:
  * Released version 0.0.5; incremented version number to 0.0.6

July 15, 2001:
  * Fixed alignment issues in netMetaPacket.  Thanks to dbg, ig2, and
    LIM from #c++ on the OpenProjects irc network for helping me to
    track down this problem!

July 14, 2001:
  * Server-side initial implementation of 'wielding' objects.
  * Added 'wielding' objects to common networking libs.
  * Wired up 'wielding' networking on server side.
  * Wired up 'wielding' networking on client side.
  * Client-side UI to wielding objects.
  * Wielded weapons now do more damage in attacks.
  * Extra confirmation messages to client to tell him when objects
    are taken/dropped/wielded, identical to NetHack messages.

July 13, 2001:
  * Converted Take command to the newly modified system, so entBase
    should now only use objBase, not objDescription.  (This also
    means that monster AI won't have to know about objDescriptions)
  * 'Take' menu implemented, when there is more than one object
    available to be taken, and objects are now listed if you walk
    over a small pile, rather than just generating a "there are many
    objects here" message.  (I find this annoying, but it mimicks 
    NetHack's behaviour.. I may change this in the future)
    
July 12, 2001:
  * Finally fixed inventory slot non-sorting issues.  TODO: Convert
    other object-manipulation commands (Take) to the newly modified
    system.  (This should only take a modification to the hnPlayer
    queued command struct and to the 'Take' command on the entBase)

July 8, 2001:
  * Added basic inventory UI to TTY client.
  * Added GetObjectDescriptionText to OBJ_Types.
  * Added client 'drop' functionality (virtually no client UI yet)
  * Proper client 'drop' UI added.

July 7, 2001:
  * Added inventory to ENT_Base.cpp/.h, and Take now moves objects
    into the inventory, instead of deleting them.
  * Fixed minor memory leak when deleting entities.
  * Oops.  Added OBJ_Dagger.cpp/.h to CVS.  Looks like nobody but me
    is tracking CVS development.  :)
  * Inventory is now transmitted to client.  (Client's "inventory"
    command only lists the topmost object in the client's inventory,
    though.. just because I'm being a slack little coder tonight)
    
July 6, 2001:
  * Finally added 'OBJ_Types.cpp' to CVS repository.  Oops!  :)

July 2, 2001:
  * 'Pick up' code migrated from hnGame to hnPlayer and entBase, so
    that any entity can pick objects up, and players can queue up
    object pickup commands, the same as movement commands.
  * Implemented method of grabbing an object's "name" from its
    enumerated constant, without including the whole object
    class hierarchy in the client.  It's not clean and elegant,
    but it works.  TODO:  Rethink this setup, see if there's a
    nicer way to achieve this.
  * Cleaned up some map update handling code & fixed a relatively
    new crash when refreshing level contents (occurred when going
    up and down levels)
  * Added a 'dagger' weapon type, just to test the method of
    grabbing an object's name, as mentioned above.  The more I
    think about this, the more I think that objects and entities
    will need to be broken off into their own libraries..

July 1, 2001:
  * Client can now 'pick up' objects with ',' -- no inventory yet,
    so 'picked up' items merely vanish from the level.  TODO:
    implement an inventory.

June 27, 2001:
  * Client now generates 'You see a...' messages by itself.  TODO:
    client still needs a way to get an object's "name" string from
    the enumerated constant, without including the whole OBJ_Base
    hierarchy.

June 26, 2001:
  * Finished initial basic implementation of objects.  The server now
    adds visible objects to the player's copy of the map data, transmits
    them to the client, and the client displays them.  The server even
    sends 'You see a long sword here' messages (hardcoded).  TODO:
    Client should generate those 'You see a...' messages by itself,
    rather than have the server transmit them.  TODO:  Client needs a
    way to get an object 'name' string from the enumerated constant,
    without including the whole OBJ_Base hierarchy.

June 20, 2001:
  * Finally made a decision about how to have server and client talk
    to each other about objects (only about six weeks late!)  Thanks
    to an e-mail correspondant whose name I've lost..  (mail me back,
    dammit, so I can give proper credit!)  :)   Initial modifications
    to common code to prepare for object support.
  * hnPlayer now sends seen objects to client as part of netMapUpdateBBox
    packets.  Of course, the client doesn't do anything with that data
    yet, and the hnPlayer doesn't actually see any objects yet.. but
    once he does, and the client does, it should all work.  :)

June 16, 2001:
  * Switched server to default to no groups -- groups were just too
    annoying!  (Actually, groups of one).  To turn on groups again,
    use the command line argument --with-groups

June 10, 2001:
  * Found more problems in object model system which would have bitten us
    a few months down the road.  Rethinking the object system now.
  * Adjusted calls so that all players within view receive messages when
    each player attacks things, instead of only seeing their own attacks.
    This needs to be fixed up a bit to be more grammatical, and to properly
    substitute 'you' for player names when players attack each other.

June 2, 2001:
  * Large infrastructure change -- hnPlayers now store their local copies
    of map data in the same format as the clients (that is, as mapClient
    instances).  This will make map updates much easier to manage!  Again,
    this is all moving towards implementing objects...

May 30, 2001:
  * ENT_*:  Modified entities to use static strings for entity names,
    instead of storing the strings on each instance of the classes.
    (This means the string "grid bug" is now only stored once in memory,
    instead of once for each grid bug in the world).
  * Moved MAP_Client.cpp/.h into 'common' from 'client'.  They're needed
    in the server code, for maintaining a proper copy of what each client
    can see of the map.  (This will let me remove some kludges from within 
    the MAP_Base)

May 27, 2001:
  * Lots of adjustments to ttyclient to switch towards a NetHack style
    message display system.  (Only partly implemented so far)
  * NetHack-style message display fully implemented (I think!)

May 26, 2001:
  * MAP_Hack.cpp:  Adjusted function names.
  * OBJ_Base.cpp:  Objects should now theoretically stack properly.
    (theoretically, since they aren't being generated yet)

May 20, 2001:
  * More name adjustments, so new names show up in talk messages and
    elsewhere.

May 19, 2001:
  * Basic damage-dealing.  Just one point per hit at the moment, but damage
    is actually done and the stat changes are sent to and visible to the
    clients.  Not yet checking for death, though.
  * NET_Server.cpp:  Turned off network debugging output again.  One of 
    these days I'll stop forgetting and checking it in with that #define 
    turned on.  :)
  * HN_Game.cpp (and elsewhere): Server now notices when players die, and
    disconnects them.  Monsters still can't die.
  * ENT_*.cpp/.h:  Entities now store a pointer to a hnPlayer, if they
    are being controlled by a player.
  * Modification to how names are stored.  Modification to attack messages.
    Monsters can now die.  Player deaths implemented differently.

May 18, 2001:
  * Turns split into two phases:  First actions, then movements.  This means
    you always get to attack before the other guy gets the run away/teleport/etc.
    (Still no combat system, though)
  * Removed nasty global offsetVector array and rolled that functionality
    into the hnPoint class.  More minor modifications in preparation for
    the upcoming combat system.
  * Client now transmits 'attack' command.  Server does basic 'to hit' check
    and sends back a 'hit' or 'missed' message to the client.  No damage
    dealt yet.

May 17, 2001:
  * Bug #424181:  Missing #include in HN_Game.cpp
  * Player stats now randomly generated.
  * Player stats now transmitted to client whenever they change.
  * Player stats now display on client, similar to NetHack's display.

May 16, 2001:
  * HN_Main_Server.cpp:  Server now accepts --nogroups as well as --no-groups.
  * HN_Server.cpp, HN_Player.cpp, HN_Group.cpp:  Optimised network packets
    again so group data is only sent when it actually changes.  Server now
    aborts sending empty packets, instead of actually sending them.
  * ENT_GridBug.cpp, ENT_Human.cpp:  Entities now set their names during
    construction.  This in preparation for a combat system.
  * HN_Status.cpp/.h:  Added common source/header files for a class to
    manage player/monster statistics and status ailments.
  * Renamed some networking functions, added ability to send unsigned
    8,16,32-bit values within packets.
  * HN_Status:  Added more functionality to hnStatus.  Closer to being
    able to implement combat!

May 13, 2001:
  * NET_Packet.h/.cpp: More new packet types and rearrangements of old ones.
  * NET_Server.cpp/NET_Packet.cpp: Added better detection of bad packets.

May 12, 2001:
  * Coding on a new computer now.  Back to work!
  * NET_Packet.h/.cpp:  Added a few new packet types for upcoming combat.
  * HN_Main_Client.cpp:  By request, made the client default to connect to
    localhost if you don't tell it otherwise.
  * NET_Server.cpp:  Server now deals more cleanly with clients that don't
    quit in an orderly manner.  (ie: it notices)
  * Client can now send 'wait' commands to server. (. or space)

May 8, 2001:
  * HN_Group.cpp: Fixed bug so monsters get assigned to groups correctly.
  * ENT_Base.cpp: Fixed bug, allowing travel in northwest direction again.
  * Finished general code cleanup.  Now ready to continue active development.

May 7, 2001:
  * Updated documentation.
  * Released version 0.0.4.
  * Updated CVS version number to 0.0.5
  * Fixed Makefile.am's so that 'make dist' works.
  * Removed Makefile.in from root level of CVS tree --
    it's generated automatically by ./autogen.sh script.
  * Began code cleanup -- mostly finished commenting server source.

May 6, 2001:
  Added up-stairs to top level of dungeon.  Going up those top-level
  up-stairs is equivalent to quitting the game, at the moment.

  Should now support curses-based systems.  (Rather than ncurses).
  Closer to Solaris support..

  More configure script adjustments.  Removed HN_Version.cpp/.h,
  since it wasn't being used and was redundant anyway.

  Removed #include "ENT_Base.h" from NET_Client.cpp.  Not sure why
  it was there in the first place.

  Massive source reorganisation.  Instead of one src directory,
  we now have split our source code into common/ server/ client/
  and ttyclient/ directories.  To add new clients, just add
  them to the root directory, provide a  'Main' similar to that
  in the ttyclient, and link in the libclient.a from the
  client/ directory (plus whatever libs are required from the
  common/ directory)

  NET_Server.cpp: Commented out DEBUG_NETWORKING #define.

May 5, 2001:
  Spent the morning working at compiling hacknet on the various
  machines in the SourceForge compile farm.  I think I've worked
  through the issues preventing compilation on the *BSD platform,
  and on Linux running on the Alpha.  Still no success at compilation
  under Solaris, or on the Compaq Tru64.  I'll keep plugging away
  at it, though!

  Split up lots of vision calculating/updating functions in mapBase
  and in hnPlayer.  Added stuff to hnGroupManager to trigger vision
  updates every time a player moves.  If something moves within a
  hnPlayer's field of view (even if that thing is outside the 
  hnPlayer's group, or if groups are turned off on the server), 
  the hnPlayer will now send updates to its client to keep the client 
  up to date.

  Fixed client to allow numpad movement as well as vi keys, for
  those who prefer numpad stuff.  Currently it just looks for the
  number characters -- honestly, it really ought to be looking for
  the appropriate keys, so that htiting the numbers at the top of
  the keyboard can be used for repeat-counts, as is done in NetHack,
  but..  Baby steps, baby steps.  ;)

  Monsters are now put into groups, along with players.  Whenever
  a group moves, all monsters within (currently) 15 squares of
  the group also get a move.  Currently, the grid bugs just move
  randomly, but they could do anything simply by overriding their
  'Think()' function.  Looks like I might have to do some more
  network optimising.  A roomful of moving grid bugs can cause
  nearly the whole room to be updated every frame..  Mind you, it's
  a bit silly of me to worry about sending *gasp* 200-300 bytes for
  a turn, isn't it?  ;)

May 4, 2001:
  Late update today.. that's because I've had to implement today's new
  feature twice.  I wanted to make creatures vanish from the map
  display when they go out of view, like in NetHack.  At first I did
  it on the client's side, but eventually worked out that the client
  has no good way of figuring out what's visible and what's not
  visible at the moment, so I re-implemented it on the server side.
  This means that update packets are a little larger, but it also
  keeps the server authoritative, so it's not necessarily a bad thing.
  Also, added some #includes to make parts of the codebase compile
  cleanly under Cygwin on Windows platforms.  I've also modified
  configure.in in the hopes of detecting whether or not socklen_t
  is available (it's not available under Cygwin.  Things which
  traditionally take socklen_t (which is generally typedef-ed
  into an unsigned 32 bit int) instead use a SIGNED int under
  Cygwin..  I can't imagine how Cygwin has made their networking
  utilities compile cleanly....   Anyhow, I THINK the changes I made
  to configure.in should detect this situation, and will properly
  #define socklen_t into 'int' in that case (if such a thing can be
  in any way considered 'proper').  If this causes anyone trouble,
  please, please let me know!  In particular, if you can modify the
  configure.in script to make it work on your system, I'll add
  your changes to the official distribution!

  Added docs/instructions.txt to cover basic playing of HackNet.

  Added --no-groups option to the server, to disable synching turns.
  This leads to massive visibility issues.. a player's vision isn't
  updated until he moves, which means that you won't see someone
  walking near you if he walks faster than you.. I'd have to put that
  hack code back into hnGame to make this work again..  I'm not going
  to do that, and am going to hope that a better solution occurs to me
  soon.

May 3, 2001:
  Added initial revision of sorting players into groups.  Groups
  only exist on a single level.. anyone within 10 squares of another
  player is pulled into their group.  Currently there's no effect from
  sharing a group with someone else, but the next step will be synching
  moves between everyone in a single group, so nobody in a group moves
  until they all move.

  Well, I did it.  Now nobody in a group moves until they've all
  submitted a turn.  Currently there's no feedback to a client that
  his move has been received..  if you enter two or more moves before
  everyone else in your group submits a move, your later moves overwrite
  your earlier ones (So at the point when the server decides that
  everyone will now move, whatever your most recently submitted move
  was is what you'll do).  Note that talking/shouting doesn't take
  up turns, and so occurs instantly.  Making this change allowed a
  bunch of code to be removed from ClientMove() in hnGame, which is
  always a good thing!

  You'd think I'd get enough programming at work!  Apparently not.  :)
  In this update, the server now sends data to the client, detailing
  how many members are in the player's group, how many of those have
  submitted turns so far, and whether or not the player has submitted
  a turn yet.  This can be displayed in whatever manner the client
  display wishes  (The TTY client shows it on the bottom row of the
  screen).  This line is only shown when more than one player is in
  the client's group.

  Increased the group range from 9 squares to 15 squares.  (We were
  having issues with people being able to see each other but not being
  synched, so the non-moving person didn't see updates of the moving
  person.  Either need to increase group range to the max vision
  radius, or need to put code back in to synch vision between people
  who aren't in the same group).  Also, removed annoying 'You haven't
  submitted a turn' message from the client when nobody in the group
  has yet submitted a turn.

May 2, 2001:
  Changed netServer and netClient in response to feedback that MSG_*
  enumerations weren't compiling successfully under FreeBSD.  As I'd
  been planning to fix these issues anyway (they'd have led to
  simple network attacks which could make the server freeze up),
  I just did the changes now.  Theoretically, it should now compile
  on FreeBSD and other platforms which were having trouble before.
  (I'll do some testing on this tomorrow, and will be waiting for
  reports from others).

  Added HN_Group.cpp/.h.  Beginning to put in the framework for
  synchronizing turns between multiple players.  We're looking at
  using a system similar to "SurrealTime", coined by the dearly
  departed InterHack project.  Players near each other (within
  ~10 squares) will take turns in synch.  Rather than have idle
  players revert to AI control (which I dislike), idle players
  will 'fall out' of time, and turn into statues until they
  return.  Or perhaps they'll just be disconnected.  I'll cross
  that bridge when I reach it.

May 1, 2001:
  Moved movement validation code from hnGame into entBase, where it
  belongs.  Talking should be moved into the entPlayer.  I'm now
  contemplating moving the entPlayer out of the entBase hierarchy.. the
  player isn't exactly a stable creature -- he can be polymorphed into
  any other creature type, which suggests that he should posess a class
  derived from the entBase, but not be one himself.  I'll make an entHuman
  class or an entKnight class for him, and move the player-specific code
  into perhaps hnPlayer, I think.  I'll think this over for a little while,
  and perhaps these changes will be made tomorrow.

  Who's a happy little overachiever?  I've made the changes I outlined
  above.  There is no longer an 'entPlayer', but rather a 'hnPlayer',
  which owns an entBase.  It's an easy change to let the player be any
  existing type of monster, rather than an entHuman.  (Try switching the
  hnPlayer constructor to make the player be an entGridBug instead of an
  entHuman.  You'll appear as a grid bug, and be correctly constrained 
  to moving along a grid!)

April 30, 2001:
  Minor bugfixes to clean up some sloppy coding that was revealed when I
  finally remembered to build with -Wall.  Oops!

  Adjusted client to put text lines at topmost free line of buffer, instead
  of always writing to the bottom line and scrolling upwards.

  Added ENT_GridBug.cpp/.h class, to start implementing monsters and
  monster behaviour with.  (Well honestly, what else did you EXPECT to be 
  the first monster implemented?)  :)  TODO:  Implement a factory method
  to create monsters without the map having to create them explicitly.

  Bugfix so server hopefully won't crash if it fails to place a new player
  onto level 1 after 500 attempts, but will instead disconnect the new
  player (This shouldn't ever happen, of course).  Another bugfix so
  the server won't place a new player on top of an existing entity
  (including either a player or a monster).  Honestly, it ought to place
  the player as near the up-stairs as possible, but since there's currently
  no up-stairs on the top level, this isn't done yet.

  Network optimisations, so only previously visible part of the level is
  transmitted when you change levels, instead of sending the WHOLE level.

  More, massive network optimisations.  Client now remembers all levels it
  visits during the session, so re-visiting a level no longer requires
  downloading all remembered visibility information for the level, but
  the client can request a refresh of all remembered visibility
  information if it needs to.  If a client has seen all of a level, this
  refresh will take a total of about 7k of data.. but with the current
  client, this will only ever happen if a client saves and quits, then
  resumes and revisits a level which it had fully explored on a previous
  connection.  (And since we don't currently support save/restoring games,
  this will _never_ happen, at the moment)

April 29, 2001:
  Minor bugfix.  Sort of.  Was intentionally emulating what I believe is 
  a bug in the NetHack level generation code, involving the creation of
  corridors.  However, the results in HackNet were to cause many more
  corridors to be generated.  I've modified our intentionally emulated bug
  to perform the function that it looks like it _ought_ to be doing,
  and now the HackNet results more closely mirror NetHack's.  Perhaps
  NetHack was fixing the misbehaviour of the bug elsewhere in the code,
  or perhaps I was misunderstanding the purpose of the code in the first
  place (easy to do, with NetHack's codebase!)  Also, I've put in some
  early scaffolding for the near-future implementation of line-of-sight.

  Implemented rogue-style line-of-sight.  This is really a very poor
  implementation, and the rogue-style line-of-sight algorithm is poor,
  too, in this day and age.  Currently, you can see one square away
  in hallways, and the full room when standing inside a room.  Proper
  Line Of Sight code is a very, very big item on the TODO list, now.

  Added some checking into the line-of-sight stuff so that it only marks
  something as 'visible' for the purpose of sending to the client if
  that something has changed.. this means that what once was a 540 byte
  room being transferred every time you moved within the room is now a
  ~20 or ~30 byte packet each time you move, if nothing else within the
  room moves.  Much faster and easier on bad net connects!  Level changing
  still requires sending the whole level.  Expect to see this re-engineered
  before the release of version 0.0.3.

April 28, 2001:
  Client now sends name to server after connecting, and the server 
  displays the name in its packet trace messages (in addition to the 
  client ID number, as before).

  The netMetaPacket class hierarchy can now send 'String' types, in
  addition to 'Char', 'Short', and 'Long's.  Note that Char/Short/Long
  are explicitly coded to send 8, 16, and 32 bytes of data, respectively.
  For convenience, 'String' takes a char buffer, rather than an array of
  sint8s.  Also, String() takes a sint16 reference, stating the length
  of the array (This should really be a uint16, now that I stop and
  think about it), so that it doesn't read in/out too much data.

  The client code has been modified to redraw the full screen every
  frame (theoretically, curses should be taking care of not actually
  redrawing parts that haven't changed..  if this isn't the case, I'll
  need to make the code a little smarter).  This is to allow the printing
  of prompts over the map.  And speaking of prompts over the map...

  The client UI for talking has now been put into place.  Hit " to
  begin to speak, and hit enter to finish speaking.  Ain't it great?
  (Backspace isn't yet implemented, because I'm a lazy bastard).  :)

  Backspace now works in the client UI.  Client now sends the talk
  messages to the server, and the server displays them in its output.
  Next to be implemented:  Sending 'talk' strings to all clients.

  Speaking and shouting fully implemented.  To yell, put an exclamation
  point on the end of your 'talk' message.  Anyone within a seven square
  range of you will hear you speak, and everyone in the game will hear
  a shout.  Obviously, both ranges need tweaking, but this seems fair
  for a starting point.  Client currently shows the last three messages
  sent from the server.  (NetHack only shows two, but I expect that
  we'll be seeing somewhat more conversation than NetHack)  :)  Also
  moved the dungeon display down by four lines to make room for the
  messages and prompts to not overlap the dungeon.  Everything should
  still fit on a 24 line display (though only barely).  I'll probably
  have to lower the number of messages displayed and otherwise adjust
  to UI to be able to fit statistics at the bottom of the screen.

  I've been a busy little coder today, apparently!  Here's the next
  set of prezzies for you..  First, stairs are now generated, and you
  can now walk up and down them!  Second, the server now remembers
  the client's visual map of each level, and uses that for the data
  that's sent to each client (this means that we're much closer to
  being able to save/restore a client's state).  Third, the server
  now fully updates the client's vision every time they walk up or
  down a dungeon level -- this is done because the client only stores
  a single 'map' locally, and so when you go up or down a level, the
  contents of the new level are sent from the server to overwrite
  the old level..  the bad news is that on currently-sized levels,
  that amounts to more than 7k of data!  This is a lot more than
  I really want to be transferring for a single move, so I suspect I'll
  need to rewrite this system to make the clients a bit smarter..
  perhaps make the clients remember all maps they see within each
  play session, and just have the server send all vision data to the
  clients whenever resuming a saved play session.. that way, we
  don't have to transfer 7k each time you change levels, just transfer
  up to 50 dungeon levels times 7k each during the initial connection
  process..  (But that's 350k, which can take a lot of time to
  transfer on slow modem connections, even if it's only done once!)

  Moved Visibility code into the mapBase class..  currently you call
  UpdateVisibility for a map to update its own visibility information
  based upon the map you pass in as a parameter, but I might reverse
  that so that particular classes of maps can override visibility
  calculating functions..  (This would be useful for the different
  visibility algorithm that will need to be used in the Rogue level,
  for example!)  This also means that the entPlayer won't need to
  change when correct visibility is moved into the code -- it'll
  automatically send the right visibility update data to the client.

---
April 27, 2001:
  Adjusted client argument parsing.  Client still defaults to 'localhost'
  if no other host is provided.  Added player 'name' argument reading,
  using identical '-u Name' syntax to that used by NetHack (so either
  '-u Name' or '-uName' will work)..  if no name is specified on the
  command line, then HackNet will fill in the name from the USER
  environment variable.  If there's no USER environment variable, then
  the LOGNAME variable is used.  If that doesn't exist either, then
  the name 'Unknown' is used.  (NetHack asks explicitly for a name
  in this case -- implementing that is a 'TODO' for HackNet).  The
  name isn't yet transferred to the server, but expect to see that
  tomorrow.

---
April 26, 2001:
  Adjusted client to use the (relatively) new netMetaPacket code that
  was originally written for the server.  Better code reusability, and
  easier to add new packet types.  (Particularly when sending strings
  over the net!)  WARNING:  The switch to the MetaPacket results in the
  requirement of accepting 16 bits worth of packet 'size' data, which
  means that in the current implementation, a malicious client could
  freeze up the server by connecting and sending a single byte of data --
  the server will block until it receives a second byte of data!  This
  is a high-priority fix for me.  I deserve to be slapped around for
  even thinking about knowingly checking the code with this sort of
  security flaw present..  but I'm doing it anyway.  Expect a fix for
  this issue within the next day or two.  :)

---
April 25, 2001:
  How sad is this -- I even put in a change on ANZAC day.  I ought to get
  my priorities straight!  ;)

  I actually did a major restruturing of the code to properly generate
  NetHack-style levels through identical code to that used in NetHack...
  and then realised that the NetHack code is functionally equivalent to
  what I already had (with one or two minor factors that I'd missed
  before)..  the NetHack version of the code is more efficient in CPU
  time and memory, but my version is more intuitive to the casual
  examiner (or so I like to believe), so I threw out all those changes
  and went back to the original code.  I've added in one or two factors
  that I'd missed before, though, such as limits on the maximum area of
  rooms.  (Currently hardcoded to 50 -- the same as in NetHack)

---
April 24, 2001:
  Long day at work -- not much time to work on HackNet.  Added ability
  for the client to connect to an internet server, and tested it on my
  local LAN.  No tests yet over the real Internet.  Note that we're using
  TCP, and so delivery is guaranteed.. but this also means that we have
  extra header data added to each packet.  Since most of our packets are
  quite small, it might be silly to use TCP -- we've almost always got
  larger packet headers than information in the packet!  Perhaps a switch
  to UDP is in the cards...  On the other hand, automatic guaranteed 
  delivery is a luxury I'm not eager to throw out.

  Oops.  My mistake -- another checkin so that the client still connects
  to localhost if called without parameters, instead of trying to
  connect to ./hacknet (or however you invoke the client).  Until the
  game is more playable, 99% of the time, connecting to localhost is
  going to be what you actually want to do, for testing purposes.  Once
  the game is more playable, I'll remove this default behaviour, and
  force an explicit hostname.  (Perhaps a ~/.hacknetrc file which lists,
  among other options, a default server?)

---
April 23, 2001:
  Minor adjustment to temporary movement code still in HN_Game.cpp to fix
  a potential bug.  Before, if a non-moving player saw a monster move 
  (currently unimplemented -- hence, potential bug), that monster would
  have shown up as a human player.  Fixed now.  Not that anybody will
  notice the change until monster movement is added.  And that won't
  happen until monsters are added.  So much to do!

  Removed HN_Consts.h, which was storing a level width/height.  This was
  just an ugly hack, to synchronise the size of the client's map with
  the server's map.  Now the server sends the client a 'map reset' packet
  when the client joins, which tells the client what size map it's going
  to use.  The server should also send this packet to the client every time
  the client moves to a new level (even if that level had been seen before).
  This tells the client to purge its memory of what level it's currently on.
  The server should ALWAYS follow the mapReset information with a full map
  refresh if the client has moved to a level he's visited before, and then
  with a set of visibility information, regardless of whether the player
  has visited that map before.

  Fixed minor bugs in MAP_Hack.cpp.  Rooms are no longer generated touching
  bottom border of the screen so frequently (silly case of using width when
  I ought to have been using height).  Other minor issues fixed, too.

---
April 22, 2001:
  Big changes today.  Here's the scoop:
  
  Added MAP_Client.cpp/.h.  This is a minimalist-implementation of mapBase
  functionality, without dependencies on the entBase and objBase classes
  (which the client isn't going to need).  Instead, it stores known map data
  and an entity type and an object type for each square.  (It needs to be able
  to store an object array for each square.. but we'll work on that later)

  Here's the biggie, though..  I've moved about half of the movement code
  into the entBase and entPlayer classes.  Once turns are properly synched
  between nearby players, I'll be able to remove the rest of the movement
  code, because it'll no longer be required.  (The movement code still in
  hnGame is there to synchronise the movements of moving players with the
  vision of non-moving players, if that makes any sense).

  Moved enumerations from OBJ/ENT_Base.h into OBJ/ENT_Types.h  This is so
  that the client code can get the types without including the object and
  entity class declarations (which it doesn't need).

  Fixed Makefile.am to remove some unneeded source files from the client.  My
  mistake.  :)   (They'd just be removed in the linking process, but now
  'make hacknet' doesn't have to compile quite so many source files)

  Removed 'playerData' structure from hnGame class.  It just stores pointers
  to entPlayer classes now -- the entPlayers keep track of their own extra
  data.  Hooray for object-oriented code!

---
April 21, 2001:
  Lots of renamed files, to make a more consistant file naming scheme.  Objects now
  have an OBJ prefix, Entities (players, monsters, etc) now have an ENT prefix, and
  Maps now have a MAP prefix.  Core classes still use HN, and network classes still
  use NET.

  Adjusted the hnGame and netServer classes.  The netServer has a pointer to the
  hnGame, which has a pointer to the lower-level guts of the simulation.  Both
  the netServer and the hnGame are singletons (possibly the hnGame shouldn't be
  a singleton -- to be considered for future updates).  This is in preparation
  for migrating the player update logic from the hnGame object into the entPlayer
  object.

  Added hnDungeon class (singleton) to own all the levels in the dungeon.  Again,
  trying to move as much out of the hnGame as possible, in preparation for moving
  the movement code into the entPlayer.
---
April 1, 2001:
  Continued discussions about timing issues.
  Adjusted object class hierarchy -- 'hnEntity' is now at the top of the hierarchy,
  with 'hnObject' and 'hnCreature' derived from it.  Players and monsters will be
  derived from hnCreature, while inanimate objects will be derived from hnObject.
---
March 11, 2001:
  Development kicks into gear and first code entered into SourceForge CVS repository
---
Dec 8, 2000:
  First code entered into CVS repository
---