Various bits, in no particular order.  This is far from a complete list -
however it keeps growing as various problems are discovered that
don't have an easy fix.

------------------------------------------------------------------------------
Known Bugs:

These are things which don't work as expected, but are difficult enough to
fix that they get put here:

Make lighting not go through walls.  Maybe move it to the 'set_wall'
function - hard to do so that it is still somewhat efficient yet the same
light source does not illuminate the same space multiple times.

------------------------------------------------------------------------------
Future feature requests

- Further control on what players can do on maps/spaces.  For example,
  prohibit players from shouting, attacking others, issuing tell,
  etc.

- Change inscription - instead of looking at range field of the player,
  have the spell to be inscribed part of the inscription command, eg
  'inscribe scroll of identify'.

- refine the NO_PASS attribute of objects - it should be possible to make
  it so that you can't walk over some spaces, but you could fly over them.
  There are other cases - water could perhaps require something like a
  'water walking' skill.  What should probably be done is make this 
  a bitmask or the like with multiple possiblities.  If the object doesn't
  have another bitmask set, object can't pass through.  For compatiblity
  reasons, no_pass should set all the new no_pass_.. bits.

- If player tries to login with same name/password as a character currently
  active, drop the old connection and associate the player with the new 
  connection.  Useful if connection is dropped but server hasn't detected
  it yet.
- Generalize the code better - split between 'rules' and 'engine'.  The engine
  would be the aspect of loading/saving objects, dealing with maps, and
  basic object support (exits, levers, etc - things useful for any working
  system). The 'rules' would be the more general genre of the game -
  a science fiction game would have a different set of rules than the
  fantasy game.  And even the same genre may have a different ruleset
  (ie, adding new skills).  This is sort of like the current server/common
  split, but goes a bit more than that - the engine would be able to compile
  into an executable with the addition of some basic stub functions,
  but playing as such would really just amount to a ghost moving accross
  a world which time is pretty much stopped (as monsters would be in the
  rules side, and not engine).
- Changing the stat generation system - instead of roll based, give some
  number of points.  This makes it easier for players to choose what they
  want to play - otherwise, I think some clients will be written that will
  do this for the players in any case.
- Change draw_info so that server tells client what type of message it is
  instead of the color.  Client can then decide what color to draw it
  or other special handling.
- Better handling of saved characters on potentially better maps.  The save
  can either have been caused via disconnection or autosave.
- Change code so that objects 'spill over' to other spaces if too many
  get piled in one space.
- More/better maps.  Add more quest maps or maps to take advantage of
  newer features (ie, church maps for each god, maps for alchemy quests
  or with rare ingredients, etc)
- Add some identifier for unique objects so that if the player that has
  a unique objects quits the game, the object goes back into circulation.
- Add flag to make price of objects not affected by charisma or other
  abilities.  This should act like gems do right now (pay 1.03, receive
  0.97).  In this way, gems don't have to be hardcoded, and other items
  could be similarly set.  Nuggets should be added to this list - its possible
  to make small amounts of money alchemy silver and then selling the nuggets.
- Add/change door handling - make them more real life - they stick around,
  can be opened, closed, different keys for different doors, etc.  This
  sort of mimics the gate behaviour, except keys may need to open them, etc.
- Added armor quality, with armor being damaged as it is used.  Add repair
  shops to go with this.  Uncertain if people really like this idea or not
- Change players draining exp from others.  Currently, there are problems
  in that it not adjusted based on levels, so there are various abuses
  draining from low level characters.  Also, generally it is not possibled
  to drain exp from monsters.  Possible ideas:
  - Change draining from other players to be a ratio of levels (ie, a level
    10 character draining from level 5 only gets half the exp.
  - Ability to drain exp from monsters (might make drain weapons more
    useful).  Maybe have monster lose some portion of the exp he would
    award when drained, and try to adjust level/other stats downward as
    it looses exp?
- Fix map loading/saving so it can do it over several ticks for smoother
  performance (maybe thread it?)
- Clean up skills table so that the basic skill information is dynamically
  generated when the program runs, and not compiled in values.
- Add adjustments to objects that adjusts chance of skill success.
  Eg, objects the player use may adjust the characters effective level in
  using a skill.  Likewise, objects/monsters could have resistances to
  certain skills (eg, skill_resist values).
- Clean up party code with respect to experience/skills.  Currently,
  other party members can get exp in whatever they want and let another
  party member do the killing.

- With above, a general cleanup of skill experience for the player needs to
  be redone - there are too many ways where players can shuffle exp into
  the skill they want.  The problem is really the spells since the player
  can change exp category after the spell has been cast.  But I could also
  see problems with pet monsters and the like.  Probably some extra
  field for spell effects which mark which spell category they are from
  needs to be added.

- Delete oldest swapped map in case the TMPDIR disk fills up while
  swapping out a map.  To do this, detection of error on save would need
  to be done (presently, the fputs are done without return value checks.)
  
- Seperate weapon speed and real speed for players - one is used for attacking
  only, and the other for movement only.  Right now, a characters real speed
  could become the weapon speed when they attack something.
  Make speed more variable for some actions (limit how much can be picked up
  at once, certain skills should take longer than others.)
- Make monster pick up more intelligent - only pick up items if they may be of
  some use (perhaps base this on int - stupid monsters might pick up everything)
- Add different dragon scales, in which different types of armor could be made
  from.
- Add random terrain type square.  Idea being you might make something a 
  random tree, and when the map is loaded, it chooses a tree random.  This
  would allow some variation in maps each time with possibly keeping the bulk
  of it the same (Depending how extensively the random trees are used.
- Allow transportation objects (ie, horses, carts, dragon, griffins, boats,
  etc.)  Flying objects should probably ignore line of sight for most
  objects (you are above the forest or mountains, but then fog should still
  affect things).  To do this, a terrain type value probably needs to be added,
  and this acts a bitmask.  Thus, transports compare bitmasks to see if
  travel through that is allowed.
- Make an object type/subtype setup.  Thus, the object type might be a
  monsters, with a subtype as grimreaper.  Or type equipment, with subtypes
  of armor, weapon, boots, etc. This probably would clean up things a bit,
  and make more logical sense.  However, this is a major change and would
  require a bit of work.
  Probably instead of making a type/subtype, just make sure that no objects
  re-use fields in non intuitive fashion - instead, add enough fields
  to the object structure that object of a specific type uses it appropriately.
  This increases memory footprint, but that probably isn't much an issue now.
- Change identification handling.  Possible idea is to have different levels
  of identification, with low level only showing basic information, and high
  level showing full detail.  Skill identification should basically use this,
  with the skill level determining actual level.  Depending on level of
  identification, different information may be revealed (value, face, 
  name, etc).
- Allow monsters to be randomly generated on a map without generators (ie,
  orcs show up in forests or whatever.)  Uses this as an option to use instead
  of the existing random encounter code.
- Have monsters potentially attack others if they are damaged by a friend.
  It looks like the code should already allow this, but I think the problem is
  that monster reevaluate their objectives too often, and which time they
  switch back to attacking the player.
- Allow treasure lists to be specified as part of the objects message
- Perhaps print out a message shortly before a spell effect is about to end.
- Rewrite all variables, using own typedefs of type:
  [us]int8, [us]int16, [us]int32    : Variables that should be at least that
	size (is there actually anything that needs to be precisely some size?)
	These typedefs can be set depending on system type.
- If communication remains the same (keyword matches),
  highlite the keywords or in some way make them more noticable so players
  can know to use them.  This is no worse than many commercial games which
  give you just a few choices to choose from to continue a conversation.
- Statues turning into golems when activated (like doors).
- IDEA: Make spells be objects.  One object for each spell you know.  Same
  system for the monsters.  For now let the objects be invisible.
  Then later create a spellbook into which the spells can be "put".
  Thus knowing a spell consists of having the spell-object in some
  spellbook.  With this, more properties of the spell (level, cost, etc)
  from the current array to the spell object.  Alternatively, spellbooks
  have the spell objects that are then put in the players inventory when
  the spell is learnt.  scrolls, wands, potions would just be objects with
  some spell object as an inventory.
  As a further extension, make general spell casting code, which can look
  at the spell object and come up with effects.  For example, right now
  the cones could be pretty generalized - all that is really different
  is the attack form (could be determined by attack type), area of effect
  (some other value in the object), damage, spell cast, level, etc.  In
  other words, the spell objects could pretty much provide all the information
  needed for some of the more general functions (cast cone, fire_bolt, etc.)
- Figurine (when a figurine pet dies, it becomes a figurine, and can be reused)

- Ability to aim at targets not in the front row.  This should apply for
  most range attacks (thus, in a group of orcs, the ones not immediately
  around the player could still use missile weapons.)

- Ability to rename objects in your inventory.  Best to probably handle
  this in the client - client can track the item of tag 1234 has name
  whatever.  To do this, the tags would need to be persistent across
  server runs.  This shouldn't be that difficult - store the tag in the
  save file, and also have a temp file the server writes its lasted used
  tag to.  The only issue is potential of running out of tag values -
  its never been a problem because no server has ever been up long enough
  to exhaust 32 bits.  However, if the last used tag value is stored away,
  it now becomes the total run time of the server - even if no instance is
  ever up for more than a week, the server itself could be up for a year
  and end up running out of tags.
  Note that by tags being persistent, other advantages arise - you can
  really know if player 'Mark' on the scorechart is the same or a
  different Mark than in the past, simply by storing the players tag.
  The client can also use these known tag values for other tracking
  purposes, like favorite lists.  The only problem is that when objects
  merge, the correct update of the tag would need to be handled by the
  server and/or client.

Secondary features:

These are more features (low priority at that) to be added.  Some of these
may be related to items above, or they may be things that just would not
add a lot to the game (IMO).

- Flag so that there is a random chance that an object will or will not appear
  on a map (this is perhaps better handled by treasurelists.  Unfortunately,
  treasurelists can not be set in the maps).
- Ability to have pixmaps set in maps or otherwise be able to load images
  without having to rebuild the default images.

