[Freeciv-Dev] Last Email On this subject

[Raahul Kumar <raahul_da_man@xxxxxxxxx>]

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

I agree with above 2 comments so far.

Ross, I feel we are seperated by the English language. Both of us seem to feel 
we have made our point. Let me select some criteria and analyse our mutual
arguments. If you prove by these criteria that I am wrong I will recant.
Alternatively, if someone else reads Greg's code and feels that it is
clear,I'll
also admit that I'm wrong(It will definately be a snowy day in hell).

Readibility - It seems to me this is the crux of our problem. I feel that
with the current code, there is no actual link between SINGLE_MOVE_COST,
and the negative move cost returned by the current code. I want the code
to make this explicit. You obviously seem to agree 

Quoting Ross

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

So what are we arguing about? You have just agreed with my main point. Greg,
it's up to you. This is actually not worth the amount of time the two of us
have spent on it. There are far more important things we could be doing.

Quoting Ross
>But if you wanted to implement hovercraft that had both land and sea
>move capabilities, the value might actually be important.

Unless you or someone else is planning to implement such a unit, that is
irrelevant. My changes made to the move cost regime had a simple motive Ross. I
took a look at the AI code and noticed it's biggest flaws(ranked in order of
importance)

1) Magic numbers(especially the number 3!!!!!) used to divide igter/3,used for
move cost, used for sea moving units etc without one explanation. Closely
related, the cryptic one letter variable names. Words cannot express the
homicidal rage I felt. That is why the my tone has not been friendly. Sorry
about
that. It seems to me that you want to introduce this chaos all over again, one
- SINGLE_MOVE_COST at a time.

2) Impossible to make simple changes. The code is currently sphaggetti code.
Make one change and it affects things everywhere. No one to date (including
Thue) has ever given me a satisfactory explanation on the value of threshold,
why we multiply it by 6 etc. Your way keeps this problem alive. 

3) The comments are actually wrong. Not misleading, not quite detailed enough,
but sometimes outright wrong. This does not apply solely to the AI code.

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

Huh?I never claimed that. In fact, I thought the quote supported my argument.
Yet
again, the  two of us don't seem to parse a sentence the same way. Having the
value of -3, people naturally assume there is a connection between
SINGLE_MOVE_COST and the negative variant. Greg did, I did, even Raimar did.
You are the only one it seems who finds the current way "natural".

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

My intent is quite the opposite. I am certain Greg's way obscures things. Read
my email from top to bottom.

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


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com