Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2000:
[Freeciv-Dev] Re: client goto & patrol v2
Home

[Freeciv-Dev] Re: client goto & patrol v2

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gaute B Strokkenes <gs234@xxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: client goto & patrol v2
From: Thue <thue@xxxxxxx>
Date: Tue, 26 Sep 2000 00:16:21 +0200
Reply-to: thue@xxxxxxx

On Sun, 24 Sep 2000 02:33:07 Gaute B Strokkenes wrote:
> Gaute B Strokkenes <gs234@xxxxxxxxx> writes:
> 
> > Thue <thue@xxxxxxx> writes:
> > 
> > What limitations?  Or, put another way, how severe are these
> > limitations?
> > 
> > > Should I just ignore that problem and consider the network ideal?
> > 
> > I suppose it's unlikely to become a practical problem right now, but
> > you'll have to deal with it sooner or later, if this multiple
> > connection thingie catches on...
> > 
> > > Is it ideal in this respect?
> > 
> > Frog knows.  Maybe you could tag the packets with connection number.
> > 
> > > Any ideas as to how to get around the problem?
> > 
> > Well, any (that is, most ;-) tiles have got exactly eight neighbours.
> > Thus, assuming that all goto routes are from adjacent tile to adjacent
> > tile, you could pack each step into only 3 bits, which is a lot
> > shorter than two shorts (32 bits?)
> 
> Looking at the latest version of your patch that I could find in the
> archieves, this is actually sent as an array of struct map_position,
> which means that you're sending 8 bytes per step.  Yikes.  I'd suggest
> something like:
> [...]

Actually it was reduced to 2 bytes per step down in the network layer.
I can get below the max packet size (4000 bytes) for any normal lenght goto, so
I think I will do that and hold back on the optimizations for a first patch.

-Thue



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