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: "Davide Pagnin via RT" <rt@xxxxxxxxxxxxxx>
Date: Sun, 2 Feb 2003 14:45:22 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sun, 2003-02-02 at 20:19, Raimar Falke via RT wrote:
> 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.

IMHO you're wrong.
The thing that is really important is to catch all the occasion in which
the client needs to get the continent_info packet.

Can you provide a counterexample in which that knowledge is needed by
the server?

> 
> > Client
> > has OWN continent numbering 
> 
> > (at this step the same continent can get 2 or more numbers)
> 
> I don't understand this.

The client CAN be unaware that 2 known areas, but separated at the
moment from its point of view, are the same continent.
This will be reflect on the client by the same continent being numbered
in 2 different way (eventually the client will discover that they are
the same continent and then it will raise a renumbering)

> 
> > 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:

My idea of this is somewhat different, I do support this kind of
semantics:

1)
continent_info
{
   int x1, y1;
   int x2, y2;
   bool same_continent;
}

This let you specify also that 2 point are no more on the same
continent. This can be useful.

2)
Otherwise we can use 2 packets, your merge_continent and its contrary,
unmerge_continent, with the obvious meaning of both.

If I have to choose, I prefer the first solution.

> 
>  - 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.

This example is interesting but I'm not sure to have it completely
understand, let's try...

FIRST POSSIBILITY
The two land areas ARE the same continent AND are joined by a UNIQUE
landbridge unknown to the client, the client think that the two land
areas are distinct.

This situation will NEVER end, unless something trigger the
continent_info packet from the server.

If the client discover the landbridge, it can recognize by itself that
the 2 land area are the same continent, then the continent_info is NOT
NEEDED.

Now we have one area for the client.

If the landbridge is terraformed to ocean (by whichever player) all the
players that know about that landbridge, should be informed that the 2
sides of that area are no more a continent, then the server sends an
appropriate continent_info(x1,y1,x2,y2,false).

The client do the appropriate renumbering, splitting the two areas.


SECOND POSSIBILITY
The two areas are the same continent and are joined by two distinct
landbriges, say one at north and one at south. The client for the moment
don't know of any of them, and then thinks that they are separate.

The client discover the south landbridge, recognizes that the two areas
are joined and do the renumbering by itself.

One player do terraform to ocean the south landbridge.

What happens now, is somewhat tricky....

The server check the terraform and that this terraform isn't going to
separate the two areas, in which case no packet continent_info are
needed

The client don't receive any continent_info(x1,y1,x2,y2,false) and then
can happily let the two areas joined.

NOTE: This would end up in the client knowing MORE than what it really
have knows, but this doesn't seem to me enough to work out a more
complex solution and is what we get in other cases.

I hope that one of the two possibility outlined are suited for your
example, otherwise, please, Raimar, eplain.

Raimar, moreover, can you agree or disagree with me, on the critical
situation 2, I've pointed out in my previous mail?

        Ciao, Davide




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