Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#2641) islands from the client's point of view
Home

[Freeciv-Dev] Re: (PR#2641) islands from the client's point of view

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: kaufman@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2641) islands from the client's point of view
From: "Raimar Falke via RT" <rt@xxxxxxxxxxxxxx>
Date: Sun, 2 Feb 2003 11:19:34 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sun, Feb 02, 2003 at 10:53:06AM -0800, Davide Pagnin via RT wrote:
> > > I do agree with Raimar also on the fact that changing continent
> > > numbering from unsigned to signed, isn't needed nor is a good idea.
> > > If we ever want to check if two "ocean" continent are the same
> > 
> > hmm.
> > 
> > > My 2 cents are to just do as better as we can, in the first attempt,
> > > with particular care to resolve the CMA conflicts situations.
> > > Afterwords we can address the "not optimality" of the
> > > renumbering/recycling problems, both on server and on client.
> > 
> > no. as I have found, not thinking about the extenuating circumstances would
> > have caused two major rewrites already.
> 
> You get me wrong, what I'm suggesting is to catch all the possible
> circumstances that will trigger continent_info packet.
> 
> But, I'm not convinced that optimize the renumbering/recycling part of
> this patch, in the first place, is so important.
> 
> Perhaps I'm not considering the whole problem, but I will grealy
> appreciate if you can explain me what is wrong with this ideal scheme:
> 
> Server
> has REAL continent numbering
> client KNOWN/UNKNOWN status of every tile

IMHO you will also need the client numbering.

> Client
> has OWN continent numbering 

> (at this step the same continent can get 2 or more numbers)

I don't understand this.

> Some events:
> a) Client do realize (by its own) that continent 2 and 5 are the same
> continent.
> It raises renumbering of continent 5 to continent 2 and eventually it
> raises renumbering of continent LAST to 5. (unless 5 was LAST and then
> this isn't needed). Then it decrements LAST.
> 
> b) Server do realize that clients needs to know that 2 tiles are on the

> same continent, it sends continent_info packet to the clients.

Since we want to decouple the client numbering at the server and the
numbering at the client the continent_info can be renamed to:
merge_continent packet. It looks like this:
{
   int x1, y1;
   int x2, y2;
}

Semantics: with this the client is informed that (x1,y1) and (x2, y2)
are on the same continent. Everything can be expressed IMHO with
this. But it is hard as in this example:

 - client knows two continents
 - server sends a merge for the two
 - client discovers a landbridge between them
 - this landbridge is now destroyed

Now it is possible that this landbridge was the reason why the server
sent the merge at the second step. It is however also possible that
there is another link between them. In this case the server has to
inform the client about this. This isn't hard per se but the
recognition of this case is hard.

> The clients receive the packet and it raises the same renumbering
> function outlined above.
> (We can discuss if we prefer the server to be strict on this, and then
> try to send only needed packets or lax and then send also packets that
> perhaps aren't needed, I can guess that this is a concern for Raimar
> from the network traffic point of view and then this argument should be
> discussed in a deeper way, but I'm not convinced that this is critical)

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Last year, out in California, at a PC users group, there was a demo of
  smart speech recognition software. Before the demonstrator could begin
  his demo, a voice called out from the audience: "Format c, return. Yes,
  return." Damned short demo, it was.




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