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: Mon, 3 Feb 2003 16:47:12 -0800
Reply-to: rt.freeciv.org@xxxxxxxxxxxxxx

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.

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

-mike



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