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

[Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>]

Hi Raahul and Ross,

It's so nice to see you arguing on my behalf ;)
Unfortunately (and fortunately for my pay-job) I am away from my computer
right now, hence long silence.

To put it short, I agree with Ross who says that if you use straight
bidding, your game is dull and difficult but if you use conventions it's
exciting and easy provided you have openly declared your conventions
beforehand.  (I'm talking about -SINGLE_MOVE in bridge terms).

However I found a bug in my _dynamical_ warmap generation which might
force me to abandon this particular convention.  The problem is that a
shore tile would never be returned although it's move_cost still
computed.

I will continue working on the patch as soon as I get back, which is
after the joyful holiday of 7th of November.  Ross, thanks for your
thourough comments; my compound answer is 50% "yes I know this but was
too lazy to implement it" 40% "ah, didn't think about that" and 10% "I
don't quite understand you here".

Gotta jet now,
late for the train as usual.

G. 

 --- "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx> wrote: 
> At 10:17 PM 01/10/19 -0700, Raahul Kumar wrote:
> >
> >--- "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx> wrote:
> >> Actually I think Gregory had it right and if one followed your
> comments 
> >> it is liable to confuse the situation far more in the future.
> >
> >You many not be aware of this, but I have improved the readibility of
> the
> code
> >dealing with movement costs quite a bit. Prior to my patch introducing
> >RAILROAD_MOVE_COST, SINGLE_MOVE_COST etc the code was very hard to
> understand.
> >You have hardly explained why the it will confuse the situation in the
> future.
> 
> Those were good changes as they identified the type of the move cost
> in ways that numbers don't differentiate.
> 
> >> Think of it this way:
> >> 
> >> 1) There is a move_cost associated with a move, in this case
> SINGLE_MOVE.
> >> 
> >> 2) You need to compute the cost to move there (i.e. to attack) but
> you
> >>    are not allowed to move there, or through there to another tile.
> >> 
> >> The convention in the warmap generation is that move_costs are
> always
> >> positive, and if you get a negative one it means something special, 
> >> i.e. case 2 above. There are only a very few special case
> interactions
> >> like this in warmap generation. Learn them, don't come up with ways
> to
> >> hide them.
> >
> >Quite wrong. Can I introduce you to SEA_MOVE_COST? I don't see how
> your
> >comments don't apply equally well to SEA_MOVE_COST. 
> 
> SEA_MOVE_COST is not passed directly to the warmap, but first detected
> by an is_sailing check and its sign flipped in the cost handling code.
> 
> The reason for it being negative is to allow you to almost store both
> land and sea moves in the same tile cost arrays. The almost breaks when
> you have cities, or introduce river movement for sailing vessels, i.e.
> tiles where you can have both land and seaa units.
> 
> But the negative part of SEA_MOVE_COST is not part of the warmap 
> convention, and so having it as a special move type is perfectly ok.
> 
> >It's impossible to believe
> >someone fails to understand my quite simple point, so I'll repeat it
> in the
> >hope it will sink in. By returning a - SINGLE_MOVE_COST the reader of
> the
> code
> >will believe there is a relationship between SINGLE_MOVE_COST and a
> negative
> >version. That is bad! It does not matter if you return a -5, a -6 or
> whatever.
> >That point is not
> >made clear anywhere.
> 
> The fact that you can't actually move there makes the cost value
> irrelevant
> since this cost is never built into subsequent moves out of this tile,
> and
> the code currently tends to ignore it.
> 
> But if you wanted to implement hovercraft that had both land and sea
> move capabilities, the value might actually be important.
> 
> Or if you used it to guaraantee you had at least a full turn's worth of
> movement points left to carry out a normal attack, the value 
> SINGLE_MOVE_COST is quite appropriate.
> 
> >Greg also had this identical problem quoting from an earlier email
> about
> >tile_move_cost_ai
> 
> The fact that others continually have this problem, might actually mean
> 
> something other than they are all collectively stupid or possesing
> inferior
> understanding to your own :-).
> 
> There are a number of ways to look at the warmap and cost stuff.
> Gregory's
> way is useful in that it highlights certain natural interfaces that
> yours
> tends to obscure in this particular instance.
> 
> Cheers,
> RossW
> =====
> 
> [...]
> >> At 12:28 AM 01/10/17 -0700, Raahul Kumar wrote:
> >> >
> >> >--- Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx> wrote:
> >> >>  --- Raahul Kumar <raahul_da_man@xxxxxxxxx> wrote: 
> >> >> > return -SINGLE_MOVE
> >> >> > 
> >> >> > No, no,no. Bad Berkolaiko, Bad! Do not return a negative single
> move
> >> >> > cost, this
> >> >> > is part of the reason I used to believe there was a relation
> between
> >> >> > single
> >> >> > move cost and the sea move cost.
> >> >> > 
> >> >> > return SEA_MOVE_COST would be better.
> >> >> 
> >> >> well, this is similar to the use of SEA_MOVE_COST but in actual
> fact it
> >> >> is completely opposite.  returning negative movecost is to signal
> that
> >> >> routes must not pass through the tile and, at the same time,
> provide the
> >> >> movecost
> >> >> for _ending_ the route here.
> >> >>
> >> >
> >> >The above should be a comment, and it is still a bad thing to
> return
> >> >-SINGLE_MOVE. Call it something like
> >> >
> >> >EVIL_TWIN_OF_SEA_MOVE_COST
> >> >
> >> >Of course, if you can think of a funnier variable name ...
> >> 
> >> 
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Make a great connection at Yahoo! Personals.
> >http://personals.yahoo.com
> >
> >
>  

____________________________________________________________
Nokia Game is on again. 
Go to http://uk.yahoo.com/nokiagame/ and join the new
all media adventure before November 3rd.