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.  Some of the things are put here just so my mailbox
doesn't overflow.

------------------------------------------------------------------------------
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.

If a shop is placed in a random map (special map), the objects below the
shop wall stick around - normally not much a problem, unless it is placed
in a glory hole (treasure level), in which case coins are now beneath the wall.

Slaying is sloppy in that it uses strstr.  This, an item that has 'slaying
giant' (like holyword of mostrai) will kill ants.  strstr matching was most
likely added to support comma seperated slaying lists (slaying demon,undead).
However, the code should really insist on exact matching, and if necessary
break apart the comma seperated list.  Probably best to make something like a
'does_slay()' function which can be used all over the place (consistent
behaviour is a good thing).  If performance for this becomes an issue, making
a slaying a set of pointers could be done (char **slaying), and it gets filled
in at load time, and at save time, gets filled in the opposite direction.
However, from a simple basis, a check in does_slay() can be done to see if
slaying does contain a comma, and if not, just do simple strcmp, and only if
it does does extra work need to be done. MSW 2003-03-28


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

- Change code so that if a player kills another player, he gets no
  exp.  Perhaps also log number of times a player has killed another player
  so problematic player killers can be more easily tracked.  This should
  be pretty simple, but is mostly here because I want to re-write the
  kill_player for the new skill code, and that should clean things up
  up a bit to make this code easier to put in.

- Allow possibility of one players magic not harming another player (should
  probably be a flag/settings value) - given that most spells are large
  area of effect spells, this may make cooperative adventuring easier.
  However, this could be a little odd - if my friend it immune to my fireball,
  shouldn't I be immune to my fireball also?  But if that is allowed, you 
  now have the case people could cast fireballs on themselves and hit a 
  whole bunch of surrounding monsters.  Perhaps allow this no damage 
  attribute based on different spells, eg, it could be argued that for bolt
  spells you'd aim it so that it doesn't hit your friend, but that same
  claim can't be made for fireballs.  Or maybe add something like the 
  ability of spells to not take effect to some range, eg, 'cast lightning
  bolt range 6' or the like, in which case it goes 6 spaces before the
  lightning actually starts.

- Refine blocking of spaces - instead of 'blocks all or nothing', ability
  to block walking but not flying, block swimming (for future expansion
  of oceans).  Also, add different LOS blocking for differing conditions -
  if flying, jungles shouldn't block line of sight, but they still should
  if your walking.  Also, add seperate blocking (pass) for monsters and
  players, eg, block_monster and block_player.  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.
  Note that these bits should also be extended for movement of more than
  just the player, eg, spells, diseases, etc.  Thus, you could have something
  like a 'no spell propogation' space - players could still cast spells on
  themselves, but range spells don't go anywhare.

- Ability for stores to set different prices for goods (eg, remote store
  charges more for the services it provides).

- dm command 'Follow' which lets him see what a player is doing, where he
  is going, etc.

- 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'.

- 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.
- 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.

- Add 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
  Further notes from mailing list: 
  Item has current quality rating -  different items have different max
  ratings - magic would increase its rating.  ITem operates normally
  when it has 50%+ of its quality.  At less than 50%, item loses
  functionality in a limited fashion (eg, multiply quality percentage
  by two to determine effective abilities in terms of percentage.)
  Item max qualities should be in the same range for most all items, so
  that powerful items given to low level characters get dinged up just
  as fast as their normal items.
  Diminished effects would be handled in fix player.
  Cost to repair based on how damage item is (100 = half cost,
  0 = full cost).  Items can be repaired on pro-rated basis.  Repair
  anvils would need to get added.
  Items are damaged based on how much damage player takes - more
  damaging attacks have higher chance to do item damage.  Amount of
  damage done to items might depend somewhat on damage done to player.
  Acid attacks would be changed to use this same code - they just
  always damage items at a much higher rate.  Different ideas is that
  chance of item damage is fixed, but amount done is based on damage
  sustained.  Other idea is that chance of damage is based on
  real damage (percent, square root, other adjustments, perhaps
  ignoring low values), but damage is somewhat constant.
  Should probably be tunables in settings to determine amount of damage
  done to item, and how often item is damaged.

- 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?)
- 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).

- 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.

- 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).
- 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.)

- Better sound support - instead of having hardcoded events for sounds (eg,
  button push, door open, etc), sounds should be tied to objects, with some
  number of sound events (eg, object active, object destroyed, object moved,
  objected attacked, repeat forever, random, etc).  Information about how far
  they can be heard (in spaces) should also be contained.  When a sound is
  played, then do a simple check to see nearby players, and if one is within
  potential range, then check for intervening objects (walls).  Walls would
  have some dampening effect, counting for more spaces (something behind a
  wall may sound 5 spaces further away.)
  Exactly how to store the sound information would need to be investigated -
  the cheapest in terms of memory would be something like how animations are
  done - have a global array of the sound information.  However, sound
  information would be tied pretty closely to object types (eg, if the sound
  info said its used for both apply and destroy, then if some other object
  used that same info, it'd also get that apply and destroy behaviour).  This
  is probably good enough - one could make individual sound information
  sequences for the individual parts if those were needed.

- Make the elevation of terrain adjust line of sight.  If on the tallest
  mountain, you would be able to see over neighboring mountains and not 
  get your view blocked.

- Change attacktype handling.  Currently, attacktypes are just bitmasks,
  so if a weapon does 'dam 30' it does 30 dam for all attacktypes it has
  set.
  The idea is to make an array of dam values for the attacktype, so
  you could have a weapon like 'phys 12, fire 6'.  This then gets adjusted by 
  appropriate resistances the creature has.
  For attacktypes that are effects (slow, paralyze, etc) dam should be the
  potency of the effect (number of ticks player is effected).
  If an item has multiple dam values set, then it would do damage from all
  the attacktypes (eg, a phys 10 fire 3 is something like a flameblade
  which does mostly physical and a little fire).

- Improve material code:
  1) Make material file more readable.  Mostly, make it one entry per
     line (no comma seperated lists), with values 0 by default, so only
     values that are different need to be entered.  Maybe make materials
     archtypes, and then use treasurelist type setup below?
  2) Remove random material selection from the material file and put it
     elsewhere - basically, more fined grained material control (silver daggers,
     but not silver axes for example).  Perhaps the idea of material
     type treasurelists?
  3) Remove material bitmask.  Instead, have a pointer to the actual materialtype
     struct, and determine basis on that (eg, this could burn up, etc).  If
     necessary, add some appropiates field to the material struct that
     denote those abilities.
  4) Suffix to be used for alternative image names and animation sequence
     for objects (eg, dagger.111.gold for example)
  5) Some way to denote that even though 'materialname' is set, that the loader
     should still do appropriate adjustements for the material.  Thus, if a
     person sets the material in the editor, the server will adjust the values
     appropriately.
  6) Allow for multiple materials in same object.  Trickier to do this.
  7) More hints for materials.  Eg, is it a notable material that should be
     included in the object name, or mundane?  Likewise, is it a type of material 
     that can be reconstituted (metals) or not (wood, stone, etc)

Improve exit/teleporter code.  With tiled maps, it is now desirable to move
   monsters between those maps, so exits should be able to move monsters.  Add
   bitmask/flag to exit to denote what it moves - players, monsters, or
   objects.

Add exp rewarder type object.  It's basic properties:
    1) amount of exp to reward the player (stats.exp)
    2) Skill to award the exp to (skill field)
    3) Flag to denote we should teach the player this skill if they don't
	have it (can_use_skill flag?)  In this way, rewarders could grant
	skills to the player.
    4) Different ways to be activated (walk on/fly on, as well as it being
	activated from something that 'pushes' it (aka, magic mouth, button,
	etc)).  In the case of another object activating it, the player
	would still need to be on the space the object is on.
    5) Use the 'slaying' field to denote that if the player has a force in
	his inventory by the same name, he doesn't get the reward, and if
	they don't have such a force, we add one to the player (so you can't
	get the same reward repeatedly).  Use something like 'value' or
        other field to denote how many ticks the force lasts for.  If value
   	is zero, then force never expires
    6) Use nrof to denote how many times the reward works.  Eg, if nrof
        is 1, then once a player uses it, no one else can get that reward
   	until the map resets.

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.

