[Freeciv-Dev] Re: CMA passes back control without reason (PR#1505)

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Jun 03, 2002 at 04:13:37PM +0200, Christian Knoke wrote:
> On Mon, Jun 03, 2002 at 02:59:29PM +0200, Raimar Falke wrote:
> > 
> > Or we can think about client side saving of attributes. But this would
> > be hard since the server and all clients have to have consistent
> > state. Something like this:
> > 
> >  user request save at the server
> >  server requests save from all clients
> >  all clients reply
> >  server freeze (no network communication)
> >  server saves
> >  server calcs hash over savegame
> >  server thaw
> >  server sends save-finished with the hash
> >  clients save their current attribute under the given hash
> > 
> > The server has to obviously send the hash of the savegame at the
> > start.
> 
> I think it's not so hard. Is it really neccessary that client attributes
> coincides with the savegame *exactly*? I don't think so.

The attributes are some kind of memory of the client side AI. It would
be bad if the client side AI can't rely on its own memory. Everything
which introduces uncertainty makes it harder to write a client side
AI. This is also the reason why I dislike the idea to randomly change
certain data that the server sends.

> The agent data, as of now, are user input. What happens if they don't
> fit, e.g. a city doesn't exist any more? They can't be applied. The
> client could be somewhat fault-tolerant about this. The worst case
> is the user has to redo some agent settings. This doesn't harm,
> as long as I can control the saving of the client attributes.

Ack for human user given agent input. But human usage of the agents is
only one of the goals.

> That is why I'd think savename + year is unique enough.
> 
> If we get CS-Integration (after the release) this could be nicely
> automated (Server save and client save).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 checking for the vaidity of the Maxwell laws on this machine... ok
 checking if e=mc^2... ok
 checking if we can safely swap on /dev/fd0... yes
    -- kvirc 2.0.0's configure