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: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Move cost map interface
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 10 Apr 2002 19:45:44 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Wed, Apr 10, 2002 at 06:29:45PM +0100, Gregory Berkolaiko wrote:
> On Wed, 10 Apr 2002, Raimar Falke wrote:
> 
> > On Wed, Apr 10, 2002 at 05:29:36PM +0100, Gregory Berkolaiko wrote:
> > > On Wed, 10 Apr 2002, Raimar Falke wrote:
> > > > 
> > > > Please explain to me what you mean with city_map and igter_move. Is
> > > > city_map a warmap which is created out of a city?
> > > 
> > > yes.  it doesn't have a unittype or move_rate, something very vague to 
> > > give idea of the distance from the city to surroundings.
> > > 
> > > igter_move is self-explaining init?  move_cost across any land is 
> > > MOVE_COST_ROAD.
> > > 
> > > all this is to say that there are more types of BMC than 
> > > enum unit_move_type
> > 
> > But all this can be specified using enum unit_move_type and enum
> > unit_flag_id like F_IGTER.
> 
> I think one specially designed enum is better than two enums.
> you can do nice clean switch.
> 
> > > > > > > don't see much difference.  all unit_move_turns does is 
> > > > > > > determining the 
> > > > > > > move_rate and then the abovementioned division.
> > 
> > MARK
> > 
> > > > > > That is the problem. These solution is too easy and only an
> > > > > > estimation. I want the exact upper limit. I would also be happy if 
> > > > > > the
> > > > > > user also gets the bottom limit.
> > > > > 
> > > > > limits not a problem.  just put
> > > > > moves_expended = (move_cost > moves_left ? moves_left + move_cost
> > > > >                                          : move_cost)
> > > > > for the upper and
> > > > > moves_expended = (move_cost > moves_left ? moves_left
> > > > >                                          : move_cost)
> > > > > for the lower.
> > > > 
> > > > This isn't about moves but about turns. I want information like "the
> > > > settler with id 4 will arrive at (4,5) in at most 5 turns and there
> > > > will have 1/3 moves left (so it can start build the road at this
> > > > turn)". Even better would be "and the settler can achieve the same
> > > > distance in 3 turns if it has luck".
> > > 
> > > well divide total_moves_expended by the move_rate and you get your limit.
> > 
> > See MARK. We already had this solution.
> 
> no.  the difference is in _what_ you divide.
> lets go through it again, very rigourously.
> 
> ======================================================
> move_cost = MIN(basic_move_cost, unit_move_rate)
> 
> //for the average time (#turns)
>       moves_expended = move_cost
> 
> //for the maximum time
>       moves_expended = (move_cost > moves_left ? moves_left + move_cost
>                                                : move_cost)
> 
> //for the minimum time
>       moves_expended = (move_cost > moves_left ? moves_left
>                                                : move_cost)
> 
> //To get the number of turn:
> 
> missing_moves = unit_move_rate - moves_left_initially
> 
> num_of_turns = 
>   (total_moves_expended + missing_moves + moves_left_finally) / 
>     unit_move_rate;
> ==================================================================
> 
> Take your example:
> 158  For example: Unit has a move rate of 3, path cost is 5, unit has 2
> 159  move points left.
> 160 
> 161  path1 costs: first tile = 3, second tile = 2
> 162 
> 163  turn 0: points = 2, unit has to wait
> 164  turn 1: points = 3, unit can move, points = 0, has to wait
> 165  turn 2: points = 3, unit can move, points = 1
> 
> This is "maximal time".
> missing_moves = 3-2 = 1
> moves_left_finally = 1
> moves_expended[1] = 2+3 = 5
> moves_expended[2] = 2
> total_moves_expended = 5+2 = 7
> maximal_time = (7+1+1) / 3 = 3
> 
> Also:
> average_time is  ((3+2)+1+1) / 3 
> 
> minimal_time is  ((2+2)+1+1) / 3
> 
> Note that minimal_time and maximal_time should involve exact division.

I just assume that this is correct. The question is should the user of
the path finding/goto/warmap do all the calculation by itself or
should the path finding/goto/warmap provide the final number/three
numbers (min/avg/max)? IMHO the path finding/goto/warmap code should
calculate all this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Life is too short for reboots."


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