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]
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2641) islands from the client's point of view
From: "Mike Kaufman via RT" <rt@xxxxxxxxxxxxxx>
Date: Sun, 2 Feb 2003 18:23:38 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sun, Feb 02, 2003 at 10:53:06AM -0800, Davide Pagnin via RT wrote:
> 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...

No, because I just wiped out my previous work (and am busy career-wise at
the moment).

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

Davide, I do have some idea what I'm talking about. I've only implemented 3
or 4 different versions of this *&^@#! code. Right now I am always talking
about PPOV, and the SERVER thinks in PPOV, the client doesn't think at all
(or very little). Here's the top of the current function:

/**************************************************************************
 the traderoute gives additional information about continents.
 if either of the players knows that the other's city is on
 the same continent, then that information is shared.

 there are two main cases:
  1. homecity's caravan arrives and forms a route with destcity. owner of 
     home knows the 2 cities are on the same continent, owner of dest
     doesn't.
     owner of dest is given this info. If homecity's tile is unknown, it 
     becomes known.
  2. player has destcity transferred to him. For trade information, he
     needs
     continent information for the trade route that is connected to
     destcity
     In this case any homecity already knows destcity, from the route
     creation. If new destcity owner doesn't know homecity, it becomes
     known.
**************************************************************************/
void share_continent_information(struct city *homecity, struct city
                                 *destcity)
{
  struct player *hplr = city_owner(homecity);
  struct player *dplr = city_owner(destcity);
  int hx = homecity->x, hy = homecity->y;
  int dx = destcity->x, dy = destcity->y;
  
  if (!map_get_known(hx, hy, dplr)) {
    unfog_area(dplr, hx, hy, 0);
    fog_area(dplr, hx, hy, 0);
  } 
  
  if (map_get_continent(hx, hy, hplr) == map_get_continent(dx, dy, hplr) &&
      map_get_continent(hx, hy, dplr) != map_get_continent(dx, dy, dplr)) {
    struct packet_continent_info info;
    struct map_position pos;
    short ocon = map_get_continent(hx, hy, dplr);
    short ncon = map_get_continent(dx, dy, dplr);
    
    freelog(LOG_DEBUG,
            " renumbering (sharing) continent %d to %d at (%d %d) for %s",
            ocon, ncon, hx, hy, dplr->name);

    renumber_continent(hx, hy, dplr, ncon);

...

As you can clearly see,,,
 
> 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.

1) and 2) do not necessarily trigger a packet.
3) does not trigger a packet.
4) does not necessarily trigger a packet.

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

1) and 2) only one side will get a packet. The other side will already 
have the correct information.
3) will never have a packet sent.
4) true, and a packet is sent when that tile becomes known.
 
> I'm not those two lists are complete but we can start from here...

5) when a client connects to a running game
6) when a game starts for an already connected client.

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

Let me try to explain. The problem is not when or if the client is informed
of continent renumbering. That will happen when a player_tile is
renumbered in the server. The problem is that we no longer have contiguous
continents. I have only recently come to realize that this presents all
sorts of problems. example: recursive renumbering systems are not going to
catch everything. example: continent information is historical. This means
we've got to have continent info in the savefile. The latter is not that
big of a deal. To deal with the former requires an almost total rewrite of
the server code.

These issues are not insurmountable. The solution in all cases that I can
imagine will be much more messy and expensive than in CVS or island5.diff
code. Once again I question the wisdom of following this path to its
conclusion. Let me present a particular scenario which may enlighten you:

  Say you have two continents and you explore a bit and find out that they're
actually one continent. You then must iterate through all the cities on the
two formerly separate continents and check their trade routes. if one has
a trade route, you need to check if the city on the other end of the
route needs new information.
  Why? Let's be more specific: A has a city on continent 1 with a route to
B's city on continent 2. B now knows that the two continents are the same,
but A doesn't until that information is shared via the trade route. This is
all fine and good, but what happens when there's a player C who has a route
with A's city on what was continent 2? We've got to check this out too. And
uhoh, C has a city on what was continent 1, who now knows that it's
actually connected with continent 2, so we've got to check that city's
routes...

Notes:
1. note that this snafu is SERVER only. The client has nothing to do with
this.
2. make the scenario arbitrarily complicated. In order to be self-consistent, 
we've got to have code that checks out these cases with 100% accuracy.

-mike



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