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

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Christian Knoke <ChrisK@xxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Add new START_TURN packet
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 16 Oct 2001 14:02:43 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Tue, Oct 16, 2001 at 01:29:28PM +0200, Christian Knoke wrote:
> Am Dienstag, 16. Oktober 2001 12:35 schrieb Raimar Falke:
> 
> > > 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:
> > 
> 
> [Communication scenarios between server and client snipped]
> 
> >
> > 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.
> 
> Yes, I think you have to go there. The agents must get somewhat
> tolerant of whether their commands are fullfilled by the real
> world (=server).

Yes but I want also catch any errors which are programming
mistakes. Like the missing tile_trade field. But yes in the long term
the agents must be more robust and this isn't a problem.

> > 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).
> 
> .. and saves some extra communication between CMA and server.
> 
> >
> > Extra bandwidth used for the start turn packet: 3 bytes.
> 
> Hhm. When the new turn starts, the "turn done" button gets active
> again, and the timer is set and starts. Are you sure you need
> this packet?

The client will receive the following packets in this order:
PACKET_BEFORE_NEW_YEAR, PACKET_NEW_YEAR and PACKET_START_TURN. The
semantics of PACKET_BEFORE_NEW_YEAR will not change PACKET_NEW_YEAR
with this patch. Only agents will react on a PACKET_START_TURN.

Or have I misunderstood you?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "There are three ways to get something done. Do it yourself, hire someone
  to do it for you or forbid your kids to do it."


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