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.