Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007)
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>, rf13@xxxxxxxxxxxxxxxxxxxxxx, freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007)
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Sat, 20 Oct 2001 12:14:38 -0400

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



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