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

[Brian Olson <locke@xxxxxxx>]

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

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

maybe the right name for the function is {}_set_aux_data(...) though slightly 
more wordy, I think it has all the right connotations.

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

This I agree with entirely, but I still think this should all be one block of 
data, not separated out by the server per-unit.

[insert clever signoff here]
Brian Olson http://bolson.org/