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

[Brian Olson <locke@xxxxxxx>]

    int {tile,player,city,unit}_get_attrib(int id, int key, int max_length, 
char *data);
    void {tile,player,city,unit}_set_attrib(int id, int key, int max_length, 
char *data);

On Saturday, January 13, 2001, at 12:05 PM, Raimar Falke wrote:

> Maybe I also misunderstood you. Suppose we have an bodyguard agent and 
> a auto-settler agent.  So both agents will allocate a key for the 
> object type "unit". This could be done in an enum. So there will be 
> SK_U_AUTO_SETTLER and SK_U_BODYGUARD. On an "classic" settler no key 
> is set. On a bodyguarded auto-settle settler both keys will be 
> set. And it may be possible that the value length grows at runtime 
> (settler received another job).

I think this scenario entails something like the following:
unit_set_attrib( settlerID, taskKey, sizeof(autoSettlerCommand), 
anAutoSettlerCommand );
/* where there are many struct *Command that begin with struct aCommand { enum 
commandType{...}; ...}; */
/* this autoSettlerCommand contains parameters about road/irrigation/etc 
priorities */
unit_set_attrib( guardID, taskKey, sizeof(bodyguardCommand), aBodyguardCommand 
);
/* the bodyguardCommand refers by id to settlerID */

OR, does it maybe mean:
unit_set_attrib( settlerID, roadKey, N, N*2 road coords to build );
unit_set_attrib( settlerID, irrigateKey, N, N*2 tiles to irregate );
etc
unit_set_attrib( guardID, guardKey, sizeof(settlerID), &settlerID );

All this of course dependant on being interpreted elsewhere by the script/AI in 
question

> So there is no easy way to map between 
> values and offset into the monolithic block except reserve the maximum 
> value length in the block. Think about an efficent communication with 
> the server. Regardless what I said above I looks like I now dislike 
> the block idea. 

I don't think that consequence is entailed. The block I speak of is not the 
active data structure within the client, but a serialized version of the same 
that is ready for transmission and storage. I just want to keep complexity out 
of the server and in the client (and keep packet count low). And by keeping the 
complexity of knowing how to serialize this extra data in the client, if some 
day hashes are out and trees are in, the server need not know or change.

The data only needs to be moved to the server at game save times. If the client 
crashes, is enlisting the server the right way to compensate? Why can't the 
client save it's extra data in a temporary file it may reload? If the 
connection is lost and reestablished, the client of course needs to get current 
game state, but does it _need_ to be told what it's last auxiliary data was? 
Might a local file be the answer here too? I think really only at game-restore 
time does the server need to tell the client what it's aux data is.

Of course, that's just my opinion, I could be wrong.
[insert clever signoff here]
Brian Olson http://bolson.org/