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

["Davide Pagnin via RT" <rt@xxxxxxxxxxxxxx>]

On Sun, 2003-02-02 at 18:54, Mike Kaufman via RT wrote:
> On Sun, Feb 02, 2003 at 08:52:17AM -0800, Davide Pagnin via RT wrote:
> > 
> > Are you going to make those changes to the patch?
> 
> The problem here is that after finishing the patch, I started testing it.
> The problem with testing it is that I found that the problem is _far_ more
> complex than I had originally believed. I'm still thinking about the proper
> solution, and rethinking the entire concept now that you bring up your
> points...

Can you provide the work in progress?
Maybe we can add some useful suggestions...

>  
> > Critical situation 2:
> > Player A is the owner of city X, player B is the owner of city Y.
> > They both reside in the same huge pangaea continent, but they are not
> > aware of where they are.
> > Player A, do a sea Exploration and reach the other side of the continent
> > (but he ignores that it is the same continent).
> > At that point he discover city Y, owned by player B, and he create a
> > trade route between the city X and city Y.
> > At this point, nor A and neither B, knows that city X and city Y are on
> > the same continent.
> > BUT, for CMA compliance, it is nevertheless needed that both A and B are
> > informed that city X and city Y are on the same continent!
> > Then you need to change your trade route establishment check, instead of
> > looking if plrtile are known, you have to check if servertile are on the
> > same island, and then inform the involved players.
> 
> this is _not_ true. If neither player realizes that they are on the same
> continent, then the two cities won't be on the same continent. You do bring
> up an good point though. _When_ one player discovers that both are on the
> same continent, the other player will have to be notified. This is starting
> to be complicated (maybe too complicated).

Sorry, but you're wrong.
When the trade-route is established, the server DO REALIZE that the 2
cities are on the same island, then it will fed the CMA with the
appropriate traderoute value, BUT if the CMA does think that the two
cities are not on the same island, this will end up in the already known
CMA traderoute mismatch error.
You can ask Raimar if I'm right or wrong...

If you're talking from a Player Point of View perspective, I can even
agree with you, but we have nevertheless agreed that when needed it was
the server to rule out the problem, not the client.
Please, I hope to not start again a SPOV/PPOV client/server, etc. etc. 
flame war...


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

Client
has OWN continent numbering 
(at this step the same continent can get 2 or more numbers)

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

What events should raise server packets? I try a list:
1) Establishment of a trade route
2) Conquer of a city which has trade routes (one packet x trade route)
3) Building of an improvement that as island-wide effect
4) Transforming of a tile (land-->ocean, ocean-->land) in the event that
this changes REAL continent numbering.

Who should receive the packet?
Any client involved in the possible "change of view". That is:
1) Both sides of the trade route established
2) Both sides of the trade routes of a captured city
3) All the sides affected by the improvement effect (at the moment, only
one)
4) All sides for which that tiles was KNOWN.

I'm not those two lists are complete but we can start from here...

Yes, I do realize that this is not complete server controlled PPOV, but
I think that we don't need complete control, we need only that server
can break up conflicting cases!

        Ciao, Davide