Complete.Org: Mailing Lists: Archives: freeciv-ai: September 2003:
[freeciv-ai] Re: [Freeciv-Dev] (PR#6131) bunch of changes to AI wall, co
Home

[freeciv-ai] Re: [Freeciv-Dev] (PR#6131) bunch of changes to AI wall, co

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [freeciv-ai] Re: [Freeciv-Dev] (PR#6131) bunch of changes to AI wall, coastal & SAM code
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Fri, 12 Sep 2003 05:51:53 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Fri, 12 Sep 2003, Gregory Berkolaiko wrote:
> > I looked hard at a savegame pille sent me this evening, trying to figure
> > out why the AI wasn't building SAMs to counter pille's massive air fleets,
> > which he used to successfully beat 15 teamed hardAIs (!!). Turned out
> > there was more than one reason. A lot more.
>
> Apart from funit bug (committed) and maybe worstenemy patch, the patches
> try to rectify a system which isn't functional. I think it's a waste of
> time.

The time writing them has already been 'wasted'. Also, will more
significant changes be done in time for release?

> We should concentrate on structural changes instead. Take building
> of the city walls for example. This is decided / reevaluated in three
> different places! It's impossible to trace what decisions are taken and
> why!

Yes.

> Same goes for adjustattackers patch IMO.It fixes the symptom without
> trying to investigate why the units do get stuck in the city.Here more
> debugging and investigation is needed.

True. pille's savegame is a very good starting point for such an exercise
(attached). His tiny empire should be totally crushed by the AIs'
overwhelming production and science level.

As to worstenemy patch, I think it should perhaps have a slight "hangover"
from the previous turn, so that the AI changes all its defensive
productions if the other player doesn't move his units for one turn.

> > no_overwrite_defense: In assess_danger(), we might overwrite the want for
> > wall, coastal and SAM by a _smaller_ value than given to them by the
> > threat code. Bad!

This is a bugfix, and should really be going in.

> > consider_defense: Another bug, I think. In the general buildings code, we
> > massage away any buildings requiring upkeep that have low want. This way
> > we massage wall, coastal and SAM down to zero want, and later cause
> > assess_danger() to skip considering these, since it checks if previous
> > code wanted them at least 1 point of want!

The above should be kept in mind when/if rewriting the defensive buildings
code.

  - Per




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