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 development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Move cost map interface
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Wed, 10 Apr 2002 18:29:45 +0100 (BST)

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 might be wrong.  If so, give an example of fix.

G.
 



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