Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: RFC: Fixing movement code
Home

[Freeciv-Dev] Re: RFC: Fixing movement code

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: RFC: Fixing movement code
From: Petr Baudis <pasky@xxxxxxxxxxx>
Date: Fri, 23 Nov 2001 17:32:39 +0100

> > Basic bonus is 'price' of the victim (build_cost), how valuable it is. In
> > the city, we increase the bonus by 40, and modified by the health of our
> > unit (* punit->hp / unit_type(punit)->hp). I don't get why it is corrected
> > by the health of our unit only in the city, that looks very misterious.. I
> > would think it would be more correct to do this everytime, i think i will
> > try that and run some tests..
> 
> I agree. In fact, would it not be a smarter thing to use the function (I
> forget the name) that calculates the odds of winning a battle instead of all
> these complex hard to figure out calcs.
Yeah.. good idea.

> > In the coeficient, bonus is used in the numerator, multiplied by
> > agressivity, so it looks it is something as 'appetency' of the victim, how
> > nice it would be to destroy. Larger price, enemy will have worse loss. If
> > it is in the city, loss will be even worse. And as I think about it now...
> > it looks that we correct it with our health because there may be more units
> > in the city stacked, and we won't destroy them all, so in the next turn
> > they may attack us. So we shouldn't do this with injured units. Obviously,
> > to be more precise, we should check for that everytime, however that would
> > be too expensive.
> 
> You sure? I'm not convinced it would be too expensive.
Well, for each tile you then need to know from which side we would go there and
if there would be also another unit waiting for us near the tile in front of
enemy unit.

> > > > c is zero everytime, no other assigment, so we can safely remove it
> > > > imho.
> > > 
> > > Maybe, maybe not. c is used in other ai functions.
> > Removed c and the assigment and it compiles fine for me. It really looks
> > this function was originally just copy of an older one, who knows.. However
> > 'c' looks like purely historical thing.
> >
> c is used in numerous ai funcs. I just like to be absolutely sure of the ai
> code. Make one small change and it snowballs into an avalanche.
It's not used here, but it really doesn't matter :-). Let's keep it there then
to make those functions more common.

> Ok. Do you want to write the blurb for your changes? 
I didn't change anything, just changed variable names, indendation and order
of some things. ;-) So i have no idea what to write there...

After this patch will get into CVS, i will maybe try to do some more massive AI
cleanups, in order to be able to read it and to make some fixes/improvements
there maybe as well :-).

-- 

                                Petr "Pasky" Baudis

UN*X programmer, UN*X administrator, hobbies = IPv6, IRC
Real Users hate Real Programmers.
Public PGP key, geekcode and stuff: http://pasky.ji.cz/~pasky/


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