[Freeciv-Dev] Re: [RFC] Attaching information to objects

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Jan 13, 2001 at 02:57:12PM +0100, Falk Hueffner wrote:
> Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> writes:
> 
> > The type of the value could be int, string, fixed array of
> > ints. Fixed array of ints would allow better performance for large
> > data however I don't thing it is worth the extra effort. So I
> > propose int for the value type. This is a problem if some code wants
> > to attach strings to objects. I don't expect any strings.
> 
> I'd choose array of chars (which may contain '\0' bytes). An int is
> just too few. For example, the player might command a settler to go to
> a certain place and build a city called "Foo". So the client needs to
> store the coordinates and the city name. Another example: A client
> might implement the possibility to plan tile improvements. It would
> then have to store a list of (coord, improvement)-pairs. (Actually I
> think this would be a very nice feature, for those people who dislike
> micro management but also think the AI autosettlers are too bad.)
> 
> What examples did you have in mind?

Same set: the auto-explore, auto-settle and other existing code as a
starting point. In the next batch any data some client side ai/player
script wants to save.

> 
> Implementation should be easy since there is already a hash table
> implementation in freeciv.

As I said: if the keys are dense and to total amount known a static
array is sufficing.

> 
> > The result are methods like:
> > 
> >    void {city,unit,player}_set_storage(int key, int value);
> >    int {city,unit,player}_get_storage(int key, int default_value);
> 
> Hm, this is a bit difficult, since "roundtrip" packets have to be
> implemented, which currently do not exist. The client has to postpone

Only in the lazy approach.

> The interface could be:
> 
> void {city,unit,player}_set_attrib(const char *key, const char *data, int 
> len);
> const char *{city,unit,player}_get_attrib(const char *key,  int *len);

If you allow any string you have to quote them in the savegame. This
isn't a hard problem.

> It would return zero length if no attribute is attached.
> 
> Actually, get_attrib might be unneccessary; the client should simply
> always cache attributes, and only retrieve them on startup or
> reconnect.  That would simplify things a lot.

Yes but I have a better feeling if this is a function instead of an
access to a data structure. Think about extensibility (we may have
roundtrip packets sometime).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Many of my assistants were fans of Tolkien, who wrote 'Lord of the Rings'
  and a number of other children's stories for adults.  The first character
  alphabet that was programmed for my plotter was Elvish rather than Latin."
    -- from SAIs "life as a computer for a quarter of a century"