[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]
--- 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
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), (continued)
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Raahul Kumar, 2001/10/16
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Gregory Berkolaiko, 2001/10/16
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Raahul Kumar, 2001/10/17
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Raimar Falke, 2001/10/17
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Ross W. Wetmore, 2001/10/19
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Raahul Kumar, 2001/10/20
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Ross W. Wetmore, 2001/10/20
- [Freeciv-Dev] Last Email On this subject, Raahul Kumar, 2001/10/20
- [Freeciv-Dev] Re: Last Email On this subject, Ross W. Wetmore, 2001/10/21
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Gregory Berkolaiko, 2001/10/26
- [Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007),
Raahul Kumar <=
[Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Gregory Berkolaiko, 2001/10/16
[Freeciv-Dev] Re: Safe paths for triremes etc. (PR#1007), Ross W. Wetmore, 2001/10/21
|
|