Complete.Org: Mailing Lists: Archives: freeciv-dev: August 1999:
[Freeciv-Dev] Patch: Server end for client data saving
Home

[Freeciv-Dev] Patch: Server end for client data saving

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Patch: Server end for client data saving
From: Marko Lindqvist <caz@xxxxxxxxxxxxxxxx>
Date: Sat, 21 Aug 1999 15:15:04 +0300 (EET DST)

 With this patch server stores some data for client, saves it with
savegames and sends back to client when loads savegame. There is no client
to ask this. I have just created this patch to be used with my client side
AI.

 Notice that that this pactch does not update common/Makefile.in or
server/Makefile.in. There's something wrong with my automake and I have to
edit Makefile.in's by hand so everything works for me. It's better to
create Makefile.in's yourself.

 I have not updated this patch to the very latest CVS, since for testing I
need also working client side and I'm afraid that there's lots of work
before cazaic runs with it. Originally patch is written against 18.Aug.99
CVS version.

 One memory unit is array of 12 chars. Server always handles it as array
of chars, not a null-terminated string. I'm referring to this unit as row.
 

 Basic idea:

 1. When new game starts server sends PACKET_CLIENT_SAVE_HEADER to the
client. Header string is set to "empty" to inform client that there is no
savespace for it yet. Size is set to maximum size server will give memory
for the client.
 If game is loaded or client just reconnects, server again sends
PACKET_CLIENT_SAVE_HEADER, but this time fills it with real header string
and size of used memory. Also it sends all rows, that are not totally
filled with zeroes, to the client as PACKET_CLIENT_SAVE. Last one is sent
even if it's filled with zeroes so client knows it's got them all.

 2. Client can ask for memory by sending PACKET_CLIENT_SAVE_HEADER filled
with desired header and amount of rows. To that server responses by
sending PACKET_CLIENT_SAVE_HEADER with real new values.
 Client can also ask for more or less memory it already has by sending new
PACKET_CLIENT_SAVE_HEADER. Additional memory is always filled with zeroes
and memory that is left (from the beginning) is untouched.

 3. Client can overwrite one row by sending PACKET_CLIENT_SAVE with
replacement row and number of the row from the beginning. Command is set
to SASP_SET.

 4. It's completely client's responsibility to know what data is where.
Server have no idea what it means. Maybe some kind of searching command
should be implementet though.

 Why row is just 12 chars instead for example 10? I was considering
situations where there is lot's of same kind of small (2-10 bytes)
structures to save. 12 can be divided by 2,3,4 and 6, while 10 is
dividable only by 2 and 5. So with rowlength of 12 there is much better
change to make those structures fit in rows nicely.

 There is currently only one command, SASP_SET, by which client can
overwrite existing row. New commans should include commands for
bigger changes in the save memory. It could be painfull to make more space
for certain kind of data by moving rest of the data row by row backward.

 Header string is there for marking which way data is organized. It's upto
client to decide whether format is something it understands or not.


 Caz

Attachment: clientsave.diff.gz
Description: Binary data


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