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)


>> This is strange, and not the way things work in other games. Normally, the
>> offensive_reaction code would push an attack task for the blocking unit.
>> Even if that does not happen, the attempt to move into the blocked hex
>> should cause an overrun action. Something must be wrong with your game
>> module. Perhaps it is impossible for this particular unit to attack the
>> blocking unit (hit-chance = 0), so it doesn't know how to proceed?
>
>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.

>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 ...

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)

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.

>Unfortunately, Xconq just says "Fatal error encountered: Signal 11" and
>aborts right there.  If it weren't for that trap, the system would
>perform a stack dump that I could send to you.

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.

Hans

Hans Ronne

hronne@pp.sbbs.se



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