[crossfire] object key-value lists.

[Mark Wedel]

  This is perhaps vaguely related to the 'A few random ideas' thread, but 
something that I don't think is that hard, but I haven't had time to work on yet.

  The basic idea is define a structure like:

  struct key_value {
	char	*key;
	char	*value;
	struct key_value	*next;
};

  And add that to the object structure.

  Whenever the object loader gets a line it doesn't understand, it stores it in 
the key_value list (key being the first word of the line, value being the rest). 
  The object saver would then save out this key_value list.  things like 
copy_object would need some updating, etc.

  This then allows arbitrary addition of new fields to the object definition 
without any changes to the loader/saver, and without any increase in object 
space.  This would reduce the overloading of various fields for sets of 
infrequently used objects.

Storing as key/value pairing makes it so that it is only parsed once during 
loading - this makes accessing data much faster than if it was just a free block 
of text that needed parsing each time something might need to get a key.

there would be a pair of helper functions like:

char *get_ob_value(object *op, char *key)
   which returns the value parameter for the right key, or null if nothing 
found, and

int set_ob_value(object *op, char *key, char *value, int add_key)
  Which sets the value for the given key.  if add_key is true, it will add the 
key if not defined, otherwise, it only updates existing keys.  Returns 
true/false based on success.

  The question then probably comes up 'when to use those key/values, and when to 
add new fields', of which this is my thought:

1) If the access to the key/value is not in an often used loop such that it is 
time sensitive.  For example, if the only time the key/value would need to be 
used is by player activating the object, that doesn't happen all that often, so 
good option.  If however the key/value would be examined for map updates (say 
glow_radius) probably not a good option.

2) If the number of objects/archetypes using it is relatively small (this being 
an imprecise term, but right now, there are about 30 vlaues that are used by 
less than 10 archetypes)

3) If this isn't closely related to a field already set as a field (eg, it would 
make sense to have something like op->foo and then have something like 
get_ob_value(op, maxfoo)