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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sun, Feb 02, 2003 at 02:45:22PM -0800, Davide Pagnin via RT wrote:
> 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?

The player has two cities in different islands with a strip of unknown
between them. In this case these two islands are two different
islands. Now in one of the cities an effect with island range is
build. I this case is will only affect one of the cities. The server
has to know this -> client (knowledge) numbering at 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)

Hmmm.

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

Me too. The question is to we need the unmerge. More on this below.

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

Lets assume something does.

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

Yes.

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

Most of the above is also true if there is a second 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).

With a second landbridge this isn't true anymore.

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

I see two things:
 - we need the unmerge
 - this is complex. I slowly favoring a solution which is simpler but
 has more bandwidth usage. If such a solution is possible.

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

        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?