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

["Raimar Falke via RT" <rt@xxxxxxxxxxxxxx>]

On Mon, Feb 03, 2003 at 04:47:12PM -0800, Mike Kaufman via RT wrote:
> On Mon, Feb 03, 2003 at 01:08:44PM -0800, Raimar Falke via RT wrote:
> > On Mon, Feb 03, 2003 at 12:29:13PM -0800, Per I. Mathisen via RT wrote:
> > > 
> > > On Sun, 2 Feb 2003, Mike Kaufman via RT wrote:
> > > >   I'm leaning back to SPOV (I guess I'm truly on the fence)
> > > 
> > > So we're back to expanding the tile packet? I remember Raimar being
> > > against this because it increased network traffic, but let's solve that in
> > > delta patch later.
> > 
> > I'm for both. I think that the difference between all server
> > controlled solution is very small. Let me repeat my proposal:
> 
> you haven't worked with the code enough. The method of
> continent-number-delivery depends on the point-of-view we use. This is not
> to say that we _could_ use one method for both PtsOV, but we get more
> efficient and/or much more simple code if we don't.
>  
> > The server has the client views of the world (SPOV or PPOV). Every
> > time something non-simple changes (traderoute, merge two islands, ...) 
> > the server transfers this client view to the client. A simple change
> > here is that the client/player discovers a tile and this tile is
> > adjacent to an already known land tile.
> > 
> > The goal is the following packet:
> >  struct packet_island_info {
> >    int num_islands;
> >    struct {
> >      int num spots;
> >      struct map_position spots[MAX_SPOTS];
> >    } islands[MAX_ISLANDS];
> >  }
> > 
> > Semantic of this is: for each client visible island one or more seed
> > spot are send. All spots for a given island are on the same
> > island. Even if the client doesn't see yet the landbridge.
> 
> this is not workable. with 256x256 map which is the network limit right now
> MAX_ISLANDS would be something like 16384. 
> better to send multiple packets.

This is for the send and receive functions. The wire hits only the
number of used islands.

> > How is this packet constructed? This is rather easy:
> > 
> > for all islands:
> >   unmark all tiles of an island (as given by the client view)
> >   while there are unmarked tiles for this island:
> >     select a map pos which is known by the client at random at this island
> >     add this map pos to the packet
> >     mark all tiles which are reachable by this one via a _known_ land tile
> > 
> > The only change is how the "initial" client view is constructed and
> > maintained. The client code is generic. The network code impact is
> > minimal.
> 
> this could be a possible method, but how about this: for SPOV, every time a
> tile_info is sent, the continent number of that tile is sent too. All the
> client has to do is ptile->continent = packet->continent; we might have to
> do a bit of fancy footwork on the client's part to make sure num_continents
> are correct, but I don't foresee that as much of a big deal. for PPOV, send
> a continent_info packet each time a set of [contiguous] tiles is renumbered.
> 
> Since tiles are renumbered often in PPOV, you want to send a packet for
> sets of tiles, since tiles are renumbered rarely in SPOV, whole sets of
> tiles are almost never sent all at once (at least for continent-numbering
> purposes.

I think that the client shouldn't be aware of renumbering. The reasons
for renumbering are minimal (dense set of values for array
indexing). This reason should not broadcasted into the design of the
rest. The basic action of PPOV are merge and split. The renumbering is
just a second class effect of those.

I'm for implementing SPOV now and let us stay open the possibility to
implement PPOV. It will be a lot harder but if someone (Davide) wants
it hard he can implement it.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The very concept of PNP is a lovely dream that simply does not translate to
  reality. The confusion of manually doing stuff is nothing compared to the
  confusion of computers trying to do stuff and getting it wrong, which they
  gleefully do with great enthusiasm." 
    -- Jinx Tigr in the SDM