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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Oct 16, 2001 at 08:52:42PM +0100, Gregory Berkolaiko wrote:
> > > +/* 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".

I see. This is still ugly.

> > > +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.

From data/default/buildings.ruleset:

[building_lighthouse]
name            = _("Lighthouse")
...
effect          =
    { "type", "range", "amount", "aff_unit"
        "Unit_Move", "Player", 1, "Sea"
        "No_Sink_Deep", "Player"
        "Unit_Veteran", "Player", 0, "Sea"
    }

So it may be happen in the future that there is a wonder which will
extend the move rate of sea units without the No_Sink_Deep property.

> > 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.

Ross?

> > > +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.

No this wasn't the question. The question is what is "1" SINGLE_MOVE
is called. A single move? And how is a third of a SINGLE_MOVE called? 
A move point? And what is move rate?

> > > +/* 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.

You know that such adjustments are ugly?! You may want to extract all
the constants.

> > 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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  What's nice about GUI is that you see what you manipulate.
  What's bad about GUI is that you can only manipulate what you see.