This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CRT Combat Model (really long)


On Sun, 2002-03-17 at 01:35, Hans Ronne wrote:
> >There is no possible case in which hit-chance = 0.  All units have a 50%
> >chance of hitting other units, except all units only have a 5% chance of
> >hitting an item.
> 
> How about acp-to-attack? It must be something with your game module since
> the intercept code works fine in other games.

It looks like:
(table acp-to-attack
  (u* u* 2)
  (places u* 0)
)

Maybe I should allow all units to go down to -1 ACP?

> 
> >Does the AI have to wait until the next turn before it can re-plan and
> >attack the blocking unit?  It might be that the game can run so fast
> >that the blocked unit is easily destroyed before it can re-plan.
> 
> No. It used to be that way, but I wrote a special low level ai code,
> ai_react_to_action, that handles all kind of tactical emergencies. It is
> executed whenever something happens near your unit. Not sure if it would be
> triggered if the other unit is completely inert (does not move, does not
> attack) though ...

No units are completely inert except for a few of the items, but they
exert no ZOC and can be captured (found) with a simple overrun action.

> 
> Anyway, the fact that the ai-controlled unit goes into reserve mode
> suggests that it is trying to do something repeatedly but fails. That is
> why I think you have a game configuration problem. What you can do is to
> add the following line:
> 
> (set units-may-go-into-reserve false)

When I tried that, the AI could easily get stuck and the turn would
continue until the end of time.

> 
> This should fix the problem. But it would of course be better to figure out
> how your game differs from other games on this point.

I'll work on that.

> 
> What I meant was that you should run xconq under GDB, as Jim just
> explained. I need to know where it crashes in order to fix the bug.

And now I can't reproduce the error, with or without GDB!


One more thing: Despite the fact that I set the minimum firing range for
everything to 2, I still see AI-controlled units that can fire firing at
adjacent units.  It seems to me that this firing/attack problem is *not*
part of this game module.

Look at Tokyo 1962 ("tokyo.g").  When the AI takes on the role of
Godzilla, it has the same problem that it will fire at an adjacent
target when it could have fired from two cells away, making it more
difficult for the enemy to strike back.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]