[Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007)

[Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>]

 --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote: 
[..]
> > NB: with the right choice of the cost functions the warmap_ methods
> > produce identical warmap to generate_warmap routine.  
> 
> > However the new methods are slower when making a full warmap
> > (i.e. no termination condition).
> 
> Why? Is this the call overhead?

I guess so.
However dynamic + new should still be much faster than full + old:
you have to consider much fewer locations.

[..]

> > the guessed direction.  As a consequence dir_ok is made redundant
> (sorry).
> 
> Ohh we had soo much fun with dir_ok ;)

Oh, I am sure we will find some use for it elsewhere :)

> > +/* SINGLE_MOVE cost function */
> > +int single_move(int x, int y, int dir, int x1, int y1)
> > +{
> > +  return SINGLE_MOVE;
> > +}
> 
> There should be "const(ant)" in the name of this method.

as you wish
but it is not used anywhere (yet)

> > +/* NB: SEA_MOVE cost functions sometimes return negative movecost
> > + * it is to be interpreted as "can go to, but can't pass through" */
> 
> Why is this needed at all. I don't see a problem if a ship "goes
> through" a city. This will be eliminated with the extra costs.

ship can go through a city.  this case is different: this is for ships to
be able to target shore (attack units on shore, disembark passengers). 
it will give answer to the question "if there is an enemy on this shore
location, how long will it take me to go there and blast him".

> > +int healthy_trireme_seamove_strict(int x, int y, int dir, int x1,
> int y1)
> > +int sick_trireme_seamove_strict(int x, int y, int dir, int x1, int
> y1)
> 
> These are weird names. 

yes.
the idea was the following: if trireme has 3 moves (as normal), it can
safely do the route: coastal tile -> ocean at dist 2 from coast -> ocean
at dist 2 from coast -> coastal tile.  However if the trireme has fewer
than 3 moves (e.g. it was hurt in combat) it should stay next to shore at
all times or else it runs a great danger of being lost.

> Is there still no idea what warmaps for cities are for?

well, for cities.
it is used somewhere in the code, but I haven't had time to look at it.
Ross might have better idea.

> > +int cor_land_move(COSTFN *basic_cost, int x, int y, int dir, int x1,
> int y1)
> 
> cor? core?

corrected (see below)

> > +    /* Don't go into the unknown. 5*SINGLE_MOVE is an arbitrary
> deterrent. */
> > +    return (warmap.restriction == GOTO_MOVE_STRAIGHTEST) ?
> > +      SINGLE_MOVE : 5*SINGLE_MOVE;
> 
> This 5 can be extracted. Something like:
> #define UNKNOWN_MOVE_COST     5

I am not sure it is constructive.  this penalty is used only once in the
code and is different for sea and land move.

> This reminds me that there is still no distinction between "move cost"
> and "turn based move cost". In the above example SINGLE_MOVE and
> 5*SINGLE_MOVE are "move costs" and the 5 is the "turn based move
> cost". What are the offical names for these entities?

Ugh?
there is question "how many moves it takes me to get from A to B" but it
is not answerable since moving is a random process (e.g. warrior with 2/3
move left stepping off a road into a forest -- might make it this turn
and might not).
the current warmap.cost gives you some idea about the answer and is
sometimes influenced by desirability of a given route.

> 
> > +/* SEA MOVE correction */
> > +int cor_sea_move(COSTFN *basic_cost, int x, int y, int dir, int x1,
> int y1)
> 
> cor == correction? Crrection for what? You may think about writing a
> longer description of this warmap/movecost/dynamic movecost

ok

> code. *reading a bit further* Ahh if the basic move cost (depending on
> the unittype and terrain) is equal the code decides upon the secondary
> cost (which takes the environment into account). Correct?

not quite.  there is basic move cost (depending on the unittype and
terrain) and then there are various penalties (corrections) added to it
based on the desirability of the route (e.g. it passes through some
unknown territory => risky => add 4*SINGLE_MOVE to the cost).  sometimes
corrections are equal to MAXCOST which essentially forbids to use this
route.

> Overall: nice ideas. The current code is hard to understand and extend
> so almost anything can improve it. You may think about splitting your
> patch because it may be hard to get such a big patch into CVS.

I will think about the best way of doing it.

Best,
G.

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie