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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Jan 13, 2001 at 07:58:20AM -0700, Brian Olson wrote:
> On Saturday, January 13, 2001, at 06:57 AM, Falk Hueffner wrote:
> 
> > 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. 
> 
> And it's very useful for client-side AI. But, why should this be
> part of the underlying client (and server!) and not just implemented
> by me as a hash from unit_id to my data?
> 
> Perhaps if you wish the data saved, the server could have a new
> packet to send that requests a packet of data that will be saved for
> the client into the savegame file. Then, state not associated with
> any unit/city/player could be saved too.

The users of this let-the-client-save-some-state thing are interrested
in attaching them to a certain object (unit, city). However you
mentioned something I missed: saving data in general. The client side
ai/scripts may want to just save some state. One and the presumably
easiest solution would be to let them attach this data to their own
player.

If you only provide one large memory block for every client the
clients have split them manual.

> > > 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. 
> 
> I'd rather int, since it's faster. And, where's the collision in 4
> billion possibilities? If you want symbols, write yourself an
> enum. Even if this data is in the server, the only one who ever
> examines the key or data is the script/AI on the client.
> 
> I agree there should be more storage than a single int per
> unit/city/player. If it must be a fixed size, how about 32 bytes, 8
> ints (as I suddenly note packet.h isn't at all 64bit clean). If the
> data must be transmitted to the server, there should be a limit,
> 64-256 bytes per unit/city/player? If the server asked for a block
> of unlabeled save data, perhaps 16kB per client? (client side should
> of course then link to libgzip...)

I didn't make myself clear: (city as an example) every player can
set/get city attributes to every city in the game. So if there are 5
players, 25 cities total and 30 city attributes and _every data "slot"
is used_ this would enlarge the savegame by 5*25*30*sizeof(int)=15kb
(the data will be saved as ascii so the number is incorrect). So it
may required to constrain the amount. The condition '_every data
"slot" is used_' is important here since code which doesn't make use
of it wouldn't make traffic/enlarge the savegame.

> > The interface could be: 
> 
> now, my flavor
> void {city,unit,player}_set_attrib( int key, int data[8] ); 
> void {city,unit,player}_get_attrib( int key,  int data[8] ); 
> or variably, very much like Falk's
> void {city,unit,player}_set_attrib( int key, const char *data, int len); 
> const char* {city,unit,player}_get_attrib( int key,  int *len); 

Lets think about it:
 - if one code part (name it agent or something else) needs to attach
   a small amount of data to an object it will allocate some keys and
   will save one variable in one attribute (single int)
 - if the agent wants to attach a lot of data it will probably make a
   struct which will be used be the agent. The agent wants to save the
   struct as a whole. Now the interface with <data, length> is handy.
   Also if the data isn't organized in a struct but in an array just
   cast chat * to the type you want.

The first one can be expressed by the second in less than 10 lines of
code. So I'm in favor of an interface like 
   int get_attrib( int key, int max_length, char *data);
      return value is set/unset
   void set_attrib( int key, int length, char *data);

The length of the data has to be limited (256, 512 or 1024 bytes).

The implementation will now have to manage these memory regions. This
isn't nice in C but IMO the easy interface is worth it.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 A life? Cool! Where can I download one?