[Freeciv-Dev] Re: Changing interface for generate_warmap (PR#1108)

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Dec 13, 2001 at 06:10:33PM +0000, Gregory Berkolaiko wrote:
>  --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote: 
> > On Thu, Dec 13, 2001 at 05:40:55PM +0000, Gregory Berkolaiko wrote:
> > > > From the first email:
> > > > 
> > > > > Functions like find_the_shortest_paths use local warmap by
> > default
> > > > > (which renders it unrecyclable).
> > > > 
> > > > I don't see this.
> > > 
> > > What exactly is your question?
> > 
> > I did a 
> >   $ grep get_warmap_sea local_warmap131201.diff |grep -v NULL
> > and got no real hits.
> 
> Oops, I see, sorry.  My mistake.
> I meant it uses "default" warmap by default.
> 
> > > > +void generate_warmap(struct move_cost_map *wm, int x, int y,
> > > > +                    struct unit *punit);
> > > > +int get_warmap_land(struct move_cost_map *wm, int x, int y);
> > > > +int get_warmap_sea(struct move_cost_map *wm, int x, int y);
> > > > 
> > > > What do you think about:
> > > > 
> > > >   struct move_cost_map *generate_warmap(int x, int y, struct unit
> > > >                                         *punit, int
> > use_global_warmap);
> > > > 
> > > > This way the access calls doesn't need to be changed if you use a
> > > > local warmap.
> > > 
> > > True.  But I thought changing access calls is a good thing.  At least
> > for
> > > testing: I suspect in few instances a wrong warmap is used.
> > > 
> > > You asked for incapsulation, didn't you?
> > 
> > You introduce access calls with this patch. You want to change all
> > accesses in a later patch another time?
> 
> What do you mean by "all accesses"?
> I changed all accesses there were, apart from those from within
> gotohand.c in warmap-generating functions like really_generate_warmap,
> find_the_shortest_path and air_something...
> 
> Maybe I missed some, but they are in gotohand.c
> 
> > 
> > So the question is: will this patch gets included if there are is no
> > global warmap anymore? (good but _maybe_ unrealistic for the next
> > time) Or will it get included if there is still a mix? (than I don't
> > want another big useless patch)
> 
> Maybe I am just tired, but I have problems understanding you.  Sorry.
> Maybe you can explain your questions in easier terms?

Your patch has code like
+  generate_warmap(NULL, x, y, NULL);
+  boatdist = get_warmap_sea(NULL, x, y);

if this code uses a non-global warmap (which is the goal) it has to be
changed to:
+  generate_warmap(&wm, x, y, NULL);
+  boatdist = get_warmap_sea(&wm, x, y);

If you change your patch so that the code looks like
+  pwm = generate_warmap(x, y, NULL, 1);
+  boatdist = get_warmap_sea(pwm, x, y);

that you only have to change the "1" to use a non-global warmap. The
access function calls (get_warmap_sea and get_warmap_land) will remain
unchanged.

> No "default" warmap is a jump too big for now.  There is a lot of
> confusion in the code now, with functions generating warmap being
> few calls away from the functions using it etc.

I suspected this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 checking for the vaidity of the Maxwell laws on this machine... ok
 checking if e=mc^2... ok
 checking if we can safely swap on /dev/fd0... yes
    -- kvirc 2.0.0's configure