Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] [Patch] Add new START_TURN packet
Home

[Freeciv-Dev] [Patch] Add new START_TURN packet

[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] [Patch] Add new START_TURN packet
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 16 Oct 2001 12:35:35 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

I want to introduce a new packet. I will try to explain why such a
packet is needed for the CMA.

The CMA currently respond to every incoming city_info packet. An
incoming city_info packet acts as an indicator that the city has
changed and the CMA has to ensure that the current status of the city
meets the user set goal. If the city needs adjustement the CMA will
sent updates to the server and will check the updates city stuatus.

This break badly if in a short time the city changes more than one
time. In the example savegame Christian has sent me the following
happens:
 server                           CMA
  - servers get a turn 
    done from the client 
  - server updates production 
    of the city and sents it 
    back
                                  - CMA receives city_info
                                  - CMA re-calculates the city and 
                                    sent updates to the server
 - ai_start_turn is called
 - barbarians conquer the city
 - server sents new city_info 
   where the city no longer 
   belongs to the player
 - server receives updates 
   from the CMA and discards 
   them because the player no 
   longer own the city
                                  - CMA compares it calculated city
                                  status with the current and BOOMs

Same with start turn:
  - servers get a turn
    done from the client
  - server sents before new 
    year packet
                                  - all agents get frozen
  - server updates production
    of the city and sents it
    back
                                  - this change of the city is pushed
                                  into a queue because all agents are
                                  frozen
 - ai_start_turn is called
 - barbarians conquer the city
 - server sents new city_info
   where the city no longer
   belongs to the player
                                  - this change of the city is pushed
                                  into a queue because all agents are
                                  frozen
 - server sends start_turn
                                  - all agents thaw and the queue is
                                  processed
                                  - CMA receives city_info
                                  - CMA notices that the city no
                                  longer belongs to the player and
                                  detaches itself from the city

I can't use the new_turn packet because the AI will move after the
new_turn packet.

The general problem continue to exist:

server         player1          player1's CMA      player2

               - change tax 
                 rates
 - global 
   city refresh
                               - update to the 
                                 server (1)
                                                   - move command which 
                                                     conquers the city (2)
 - (3)

It now depends if (1) or (2) arrive before the other. The solution is
that the CMA doesn't go BOOM if there is a difference between the
calculated and the real state of the city. The start_turn packet even
so very usefull. The time between before_new_year and start_turn can't
be used by any agent or player. And all city_infos which will be
generated between before_new_year and start_turn can be merged into
one (removes duplicated calculations).

Extra bandwidth used for the start turn packet: 3 bytes.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 Windows: Where do you want to go today?
 Linux: Where do you want to go tomorrow?
 BSD: Are you guys coming or what?

Attachment: start_turn1.diff
Description: Text document


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