Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: [RFC] Move cost map interface
Home

[Freeciv-Dev] Re: [RFC] Move cost map interface

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [RFC] Move cost map interface
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Fri, 26 Apr 2002 16:31:53 +0100 (BST)

On Thu, 25 Apr 2002, Raimar Falke wrote:

> On Thu, Apr 25, 2002 at 06:10:51PM +0100, Gregory Berkolaiko wrote:
> > On Wed, 24 Apr 2002, Raimar Falke wrote:
> > 
> > >  - added move_expended array
> > 
> > The information given by 
> >     moves_expended, initial_moves
> > and by 
> >     turn, move_left
> > is equivalent.  So I think it is excessive to have both of them.
> > If I were you, I would convert moves_left to an array though (however it 
> > only makes sense for MINIMAL and MAXIMAL modes).
> > Again, this is not an area of my immediate interest.

Any comments on the above?

> > I also have many problems reading this bit of code:
> > =============================================================
> > /*
> >  * Construct the whole path to the given position and write it into
> >  * the given path. The position has to be obtained from
> >  * pf_get_next_position.
> >  */
> > void pf_construct_path(pf_map_t map, const struct pf_position *position,
> >                        const pf_location_t location);
> > 
> > /*
> >  * The last position of the next best path is written in the given
> >  * struct pf_position. Only the fields int x, y and
> >  * remaining_move_points are set. Returns FALSE if no more positions
> >  * are available in this map. Behavior is undefined after pf_get_path
> >  * was called.
> >  */
> > bool pf_get_next_position(pf_map_t map, pf_location_t *location);
> > ===================================================================
> > 

[...]

> > 2. The comment of get_next_position is wrong too.  It's obsolete.
> 
> Yes "Only ...set" should be removed.

Also pf_position should be pf_location in the end of the first sentence.

> > 5. I can foresee a lot of confusion with position / location names.  Thus 
> > I reccommend to change pf_position to pf_node (as in node of the route).
> 
> We can define the terms position and location at the top. Problem
> solved IMHO.

Of course we should define and comment everything.  I take it for granted.  
Still position and location are very similar words (Merriam-Webster: 
synonyms of position: place, location, locus etc).  Being of poor mind 
power I won't be able to remember which is which.  And I don't want to go 
and consult the comments whenever I need to refer to one.

So if you don't mind, I'd really prefer to rename pf_postion to pf_node.

> > 6. I hope that you do not consider this interface as wrought in stone.
> 
> I have no problem changing the interface in small areas.

cool.

> I'm currently adapting the goto agent code to use the new
> interface. This should give us a playground for more experimentations.

great.

G.




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