TODO list (long.)

[Mark Wedel <>]

 This is a somewhat edited copy of the TODO list, with many comments by
me on it.  Some are just thoughts on whether the features are actually
needed, other ones are the fact that I'm not really sure if some things are
still a problem.

- A flag so that when an object burns it becomes other_arch (random chance?)
    This is an interesting idea, and would not be really hard to do.
    Probably the best way to do this would be to use a treasurelist - this
    would allow the random chance, and the possible creation of several
    items.  However, might it also be a good idea to extend this idea for
    items that are destroyed other ways?  And should this be an object or
    archetype flag.

- Add a ring of warning/ spell of warning, which compares your level
  with the level of the most high-level monster on the current map.
    Would not be hard to do.  I am not sure of the usefulness of such
    a feature - the level can mean much less than the abilities and items
    that the creature has.  It would probably be best to add another field
    to the map structure that the map creator sets - this would be the
    level a character should be to take at that level.  Difficulty is
    a rough approximation, but since you can get the difficult with the
    'maps command, either that needs to be removed from the maps command,
    or not be used.  It isn't always an accurate measure in any case.

- Rewrite all variables, using own typedefs of type:
  int8, int16, int32    : Variables that should be exactly this size.
  int8u, int16u, int32u : Variables that can be larger to increase speed.
  Add stuff about this in config.h or other place.
  (The needed #ifdefs will need some debugging...)
    Probably will take a very long time to do.  It is being used in
    most of the structures now, but with a bit different naming convention
    ([us]int{8,16,32}).  My assumption is that the typedefs are set up so
    that the actual variable is at least that many bytes.  Is there actually
    any cases where a variable is assumed to be exactly a set number of bytes,
    and will break if it is more bytes?

- Expand the features of parse_message():
  Support for state-variables in messages.
    Better parse_message is needed.  I remember that some people wanted to
    go to a very complex/external function.  If anything, it would probably
    be nice to greatly expand the features of npc control, so that they can
    also give and take items.

- Fix bug that makes game crash on HP-computer (hplos) if it can't fix the
  font.
    Anyone know if it still does this?  Does anyone even care?

- When two players using pixmaps enters the game at the same time, the
  first player will be freezed while the pixmaps are loaded for the second.
  The other players won't notice anything though, so don't know if this is
  worth fixing.  (Shouldn't be noticable without debug option)
    Is this still happening?  Does anyone have more details on what does
    happen?  If the first player hasn't actually joined the game, I don't
    see this as a major problem.  Will probably disappear with the new
    client server stuff in any case.

- Fix throw, and make giants throw boulders (medium size)
    Being able to throw anything would be really neat.  Would actually give
    a use to poison.  How to deal with effects when a monster is hit by
    some things would be difficult.  Also, throwing boulders might be a
    problem, since this could trap players in, or make some maps easier,
    as the boulders are moved to a place that they normally could not get to.
    Also, how much damage certain thrown objects do would need to be worked
    out, and perhaps an entirely new entry in objects would be needed (a
    thrown dagger should do about normal damage, but a thrown sword probably
    should not.  Likewise, a thrown dagger should go farther than a thrown
    sword..)  This would open up a whole new set of weapons to be added.

- The game can crash when a part of a monster is killed by a fire-wall.
  (There is a temporary fix for this though, so the chance of crash is small)
    Anyone more familiar with this?  I don't every remember seeing a crash
    with this problem.  Has this perhaps been fixed in other ways?

- Debug all use of the friendly flag.
    As above - anyone have more details on what needs to be debugged?  IT seems
    to work fairly good right now.

- Maybe improve the way speed is used on spells (ie, getting disturbed, etc).
    The new CASTING_TIME options pretty much does this, no?

- Is it worth it to make the blocks_view routines more perfect?
  They way they are now they are very fast, and works 99.9% of the time.
  (100% if all maps were designed correctly)
    Is this a problem?  It seems fine to me.  AT one time, there were different
    LOS options.

- When dropping items onto objects that blocks view, make them "fall beneath".
    Is there actually any one to do this?  I can't think of anything that
    actually blocks line of sight that someone can stand on/drop on object
    on.

- 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.
    This is already true for some spells, correct (things like fireball,
    lightning bolt, etc..)  Spellbooks already have a use, but I could see
    something like rings of spell storing.  Most every spell has an archetype/
    object associated with it.  I am not sure what would be needed to do
    this.

- Make a better time-scheme.  For instance using an integer as a counter,
  and compare this to the variable next_move in each object.  Thus a
  float doesn't have to be increased in *each* object *each* round.
  Of course, to get a resolution larger than 1/x, another variable, time_debt,
  must be made.
    Are the floating point additions typically that costly right now?  Most
    machines do have good floating point processing speed.  The other problem
    I see with this is that if you calculate when an object would next get
    to move, and the objects speed changes, then the results might not be
    really good.

- If an object is killed (removed/freed) while its firebreath (or other
  objects owned by it) are still moving, the game used to generate warnings.
  I'll try to make a system that uses refcounts in objects when freeing them.
  When an object is killed, it's speed is set to 0, and free_object() will
  decrease the refcount.  The refcount is increased for each pointer pointing
  at the object, ie each time set_owner() is called.
  When the refcount reaches 0, the object will be freed for good.
    This seems to be working now.  Has anyone seen any problems with this
    lately?

- Use map->difficulty for more things than bonuses in treasure.c
    One question would be is what else to use it for?  Right now, it is only
    used in treasure generation.

- Use X-resources more extensively (colors, etc)
    This will eventually be a client issue.