[freeciv-ai] Re: FreeCiv brief analysis

["Guillermo Lopez Alejos" <100030179@xxxxxxxxxxxxxxx>]

Hi,

I've been busy these day so I couldn't write before.

> 
> Maybe this become clear if I show you the alternatives:
> 
> If the common client controls the interface 
> 
>   the common client would looks like this:
>     forever:
>       wait for packet
>       process packet (this updates the internal state)
>       notify external program
>        (if the external program returns here or unlock the common
>        client would continue and wait for the next packet)
> 
>   the external program may look like this:
>     notify_from_common_client_core():
>       lock common client
>       query client
>       calculate
>       issue commands
>       unlock common client
> 

nikodimka said that this is the correct schema.

I understand the reasons for locking the client (I have followed this
thread) but I wonder if we can hide the locking of the client to the
external program.

We can define a turn-based-locking:
    1. puppeteer locks the client
    2. The external program issues its commands (some of them would
require to ask the server and change client's state; in this case the
client may be unlocked and locked again by puppeteer automatically)
    3. Finally puppeteer unlocks the client at the end of the turn of
the external program.

Note that the external program has to remain locked when waiting for
client response... hum... how can we release the external program from
doing this explicit? RPCs?

--
Guillermo López Alejos - N.I.A. 100030179
Universidad Carlos III de Madrid
Ingeniería Técnica en Informática de Gestión