[Freeciv-Dev] Re: AI danger (Re: Re: A bunch of patches)

[Petr Baudis <pasky@xxxxxxxxxxx>]

Dear diary, on Tue, Jan 08, 2002 at 12:43:29PM CET, I got a letter,
where Raahul Kumar <raahul_da_man@xxxxxxxxx> told me, that...
> > > Anyway, forgetting about the overflow and fp issues, I decided to rewrite 
> > > the code locally to see what effect the m/dist rule has on the AI. 
> > > Everywhere the code used v * m / dist, it instead calls this function:
> > > 
> > > int adjust_danger_for_distance(struct unit *punit,
> > >                                int danger, int move, int distance)
> > > {
> > >   int moves = distance / move;
> > >   int attacks = move / distance;
> > >   if (moves)
> > >     return danger / moves;
> > >   if (attacks && !unit_flag(punit, F_ONE_ATTACK))
> > >     return danger * attacks;
> > >   return danger;
> > > }
> > >
> 
> Question on this function. Moves is move_rate?, you have not checked whether
> the unit can even attack(battleship is never a threat to an air unit), is this
> handled elsewhere?
move is probably move_rate (didn't look at the usage of the funct, though), 
moves
is how many moves we have to do, attacks is how many times we can attack.

> > > To handle overflow, I then added checks to limit any individual
> > > contribution and the total with each addition, and a check in the
> > > function above to make sure that danger * attacks doesn't overflow.
> > > 
> > > This still seems very wrong to me, but it's at least less wrong.
> > >
> 
> It's better. There must be a better scheme than this. Possibly something like
> this might work 
> 
> Danger * if unit ignores walls
> Danger * if unit is immune to zoc
> etc
See assess_danger family, especially assess_danger_unit() and assess_danger().

> > > I playtested this to see how it affects the AI. First, it never
> > > overflows, but that's not the main issue. It does make different
> > > decisions sometimes, but it's hard to tell whether these decisions are
> > > better, and they don't show up all that often.
> > 
> > > If anyone else would like to either explain the intention behind the
> > > m/dist, playtest this variant, or suggest other possibilities to
> > > playtest, I'd be very happy.
> > 
> > Ross has the best understanding at this.
> > 
> 
> I suspect this is a very badly bugged piece of code. Petr and Ross will
> probably agree.
It looks it works, that's important. It's probably buggy somewhat, but it
doesn't crash and works reasonably - when we'll decypher how it works, we will
be able to fix it in better way.

PS: My mind is in SNAFU state now, so I'm not sure if I wrote even anything
meanable now ;).

-- 

                                Petr "Pasky" Baudis

UN*X programmer, UN*X administrator, hobbies = IPv6, IRC, FreeCiv, (e)links
.
The advantage of GUI is that you can see everything you can change.
The disadvantage of GUI is that you can change only what you can see.
.
Public PGP key, geekcode and stuff: http://pasky.ji.cz/~pasky/