Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2001:
[Freeciv-Dev] Re: [RFC] Attaching information to objects
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Attaching information to objects
From: Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: 13 Jan 2001 14:57:12 +0100

Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> writes:

> For various reasons a way to attach additional information to cities,
> units and players is needed.

I agree with this. This is a prerequisite for client scripting.

> The data has to be on the server since it should be included in the
> savegame. Since the information should be extendible I would propose
> a hash. The type of the key could be int or string. I would propose
> int.

I'd rather choose string, since this avoids colliding identifiers.

> 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?

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

> 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
packets until it gets the reply packet.

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);

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.

        Falk




[Prev in Thread] Current Thread [Next in Thread]