[Freeciv-Dev] Re: example patch: [xy]_map_iterate

[Jason Dorje Short <vze2zq63@xxxxxxxxxxx>]

Jason Dorje Short wrote:
> 
> Raimar Falke wrote:
> >
> > On Thu, Oct 04, 2001 at 05:57:09AM -0400, Jason Dorje Short wrote:
> > > There's a lot of code that can't use whole_map_iterate because the
> > > iteration has to happen in a certain order.
> >
> > What code? I don't have a good feeling with code that has such
> > dependencies. Printing the map?
> 
> Printing the map (to some random text file, I presume) is part of it.
> Also saving the game and sending tiles across the network.  These depend
> strictly upon the ordering, so are easy to fix using [xy]_map_iterate.
> 
> Other examples don't iterate over the whole map...for instance some
> iterate over just the poles while others skip border positions.  These
> can be done with whole_map_iterate by skipping invalid positions; the
> problem here is that the current definition of "valid" is
> topology-dependent (it assumes the current wrapping system).  These will
> take a little time to figure out.
> 
> All in all, there are 30-50 such cases.  Try grepping for
> "for.*x.*map.xsize".  Most of them are in the savegame code, which I'm
> not particularly familiar with.

Oh, yeah: one other thought.  Most of this code is tricky because it
must be compatible with other versions.  The server<->client
communications are OK (actually I don't think the order the tiles are
sent in matters, it's just broken up so they're not all sent at once),
but for the savegame stuff the order they're saved in must be the same
as the order they're loaded in.  If whole_map_iterate were used this
would not be guaranteed.  However, it would be reasonable for
x_map_iterate and friends to guarantee an always-increasing iteration
(as is used now), so using them should work.

Another issue is that you must know the topology information when you're
reading this data.  Thus, the topology info must be saved/loaded before
this, presumably at the same time as map.xsize/map.ysize are now.

jason