Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Notes and serial numbers
Home

[Freeciv-Dev] Notes and serial numbers

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Dirk Stoecker <stoecker@xxxxxxxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Notes and serial numbers
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 2 Sep 2001 17:24:48 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

The next step which I consider essential to client side ai/scripting
are serial numbers. 

Problem: the server currently doesn't respond to each packet it gets
from the client. There is no packet sent back for example if a unit
tried to do some stupid (into the ocean and no ship) move. Any client
side automated code however has to know if the request succeeded or
not. One way is to add an "error" packet to every error path. Another
way is to sent a generic "execution finished" packet after every set
(can be empty) of packet which were sent during the normal execution
of the command. This would allow the client to wait for this
"execution finished" packet and than check the new position of the
unit and sees if it had been changed or not. To have more than one
packet on the fly between client and server serial numbers are needed
to match "execution finished" packets with the corresponding
commands. 

This idea was implemented in the note patch. The note patch however
also tried to tackle another problem: currently the server formats
(sprintf) strings which will go to the clients. All client will get
strings in the language of the server. This is bad. A solution is to
transfer the untranslated string and let the client to the final
formatting (after replacing the format string with the corresponding
format string of the client language).

The note patch also tried to solve another problem: categories. These
were indented as a replacement of the flat event namespace. I also
thought that a categorized error response would make it easier to code
client side ai. I think now that this isn't necessary. If a command
will have not the calculated effect it is either fatal (client side ai
sends a change science goal command and nothing happends) or non fatal
(introduction of a new move restriction). In either case a categorized
error code wouldn't bring a benefit.

The note patch I'm referring to solve the first and second problem
nicely. However to get to full benefit of the second a lot of code
(about 380 calls to some notify_ method) has to be converted. Nobody
has done this. I tried to invent some categories but failed.

Proposal: remove categories and split the remaining two problems. For
client side ai only the solution to the first problem is
necessary. This will consists of two serial numbers (each 2 bytes
wide) to each packet and an empty packet (type (1 byte)+size (2
bytes)+2*sno(2 bytes)=7 bytes) after the server finishes processing a
client packet. If nobody objects on the general idea I will extract
the serial number stuff from the big note patch and post it here.

If someone (Dirk maybe) feels like he wants to tackle the i18n problem
feel free to contact me.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "- Amiga Y2K fixes (a bit late, wouldn't you say?)"
    -- Linus Torvalds about linux 2.4.0 at 4 Jan 2001


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