[crossfire] proposal: quest tracking

[Mark Wedel]

tchize wrote:
>
     
      Nice project, overall
     
     >
     
     
     >
     
      Just a short(#) note on the way to track quests.
     
     >
     
      IMHO the actual way to track things on player (using forces and other 
     
     >
     
      invisible objects in inventory) has it's use only when you need to check them 
     
     >
     
      against detectors (check-inv).
     
     >
     
      This way of handling things has a major problem, i think, in terms of code 
     
     >
     
      readability. The main reason it was saved in the inventory is becasue the 
     
     >
     
      player is saved as an object and everything in crossfire is object. However, 
     
     >
     
      there are already specific fields for the player which are saved outside of 
     
     >
     
      the object saving code. 
     
     
  there are a few saved outside of objects.  But it is fewer and fewer.

  There are lots of advantages to saving all data as objects and not add new 
fields to the player object:

1) Can add as many objects as necessary - not limited to potential data sizes in 
the player structure.

2) Having objects let all the object manipulation code work, eg, scripts don't 
need new hooks to get to this new information, dm commands that work on objects 
still work, etc.

3) Object is much more extensible - using key/value pairs gets into the case of 
someone asking 'I also want to store xyz in this key'.  The object already has 
lots of fields that can be used to store data.

  The only disadvantage is that objects are stored in a list, so as said, 
performance isn't great.

  However, this almost is never a problem - the number of times the player 
inventory is typically examined/search is relatively low.  And unless you have 
hundreds of such markers, performance shouldn't make a significant difference 
(and if you do have hundreds of such objects, storing them in a key/value list 
isn't going to be any faster).

  I have suggested, but never got around to doing, is making 2 inventory lists 
for all objects - one covering visible objects, one covering invisible objects. 
  This helps some of the performance issues (all those markers won't slow down 
access for all the normal everyday objects), but can still work with all the 
above (the inv_invis list/last object of it could be linked to the normal 
inventory list, or perhaps vice versa) - this effectively sorts the inventory 
into invisible and non invisible, which certainly helps things out some.