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 17:46:28 +0100

Brian Olson <locke@xxxxxxx> writes:

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

This would suffice if it weren't for disconnects. You'd probably want
to have the server know all of your extra data at each point of time
in case your client crashes. This sounds like a lot more network
traffic, but since you need only transfer the *changes*, it might even
be less.

I've another suggestion: it might suffice to submit just a single
32-bit int to the server as a key.

A client would usually have just a few "jobs", like worklist, or
gotos, or the mentioned tile improvement plan. So it could mangle the
job ID in 1 byte and the unit ID/tile coord/etc. into the lower 24
bits. The server would then only need a single hash table for each
player, where it would stuff the key directly into the void* of the
hash_bucket. The client would cache it in the same format. Very easy
to implement. The client would have some convenience functions like

enum client_data { CD_PUBLIC_WORKER, CD_TILE_IMPROVEMENT };

/* cache attribute and send it to the server */
void set_attrib(enum client_data type, int id, int len, const char *data);

/* save memory */
void remove_attrib(enum client_data type, int id);

/* retrieve attribute from cache */
const char *get_attrib(enum client_data type, int id, int *len, const char 
*data);

Then one would need a new packet, which simply contains key and data.

        Falk




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