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: Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>, "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007)
From: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Date: Fri, 26 Oct 2001 21:37:21 -0700 (PDT)

--- Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx> wrote:
> 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.
> 

What are you going with instead of the current -3 convention? 

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


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


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