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 Sat, 2002-03-16 at 03:58, Hans Ronne wrote:
> Could I use occupant-affects-defense (sort of like
> >occupant-affects-attack in "3rd-age.g") to boost the effectiveness of a
> >unit as a defender?
> 
> Yes, but these tables only work with combat model 1 right now. As I said in
> another thread, I will fix combat model 0 so that it can use attack/defend
> tables etc., but only when the network bugs have been fixed.

I re-configured the places so that they provide 50% protection to all
occupants, and now they are much easier to defend.  And now I have
returned the ai-peace-garrison and ai-war-garrison properties to their
default values (don't know what they are, though, but they're not 0).

> 
> >11. When the AI has a unit that want to attack an enemy unit (e.g. an
> >orc hole) but another enemy unit is blocking its path, it should
> >consider attacking that unit, then proceeding to attack the first
> >target.  Right now, AI-controlled units that encounter such situations
> >simply go into reserve and are rather easy for me to kill.
> 
> 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.

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.

> 
> >This would be fine for Lightning stones, but not dragons and beholders.
> >They are supposed to be able to attack directly as well as fire (the
> >advantage to direct attack being that less ACP is required).  A similar
> >(although more complex) setup is used in "galazy2.g", as a starship can
> >attack at close range or can fire photon torpedoes at a distance (the
> >difference is in damage done and material consumed).  Of course, the AI
> >is terrible at that game, too.
> 
> Well, as I said, if you do want a unit to be able to both attack directly
> and fire, then it will attack directly most of the time. If acp-to-fire is
> a problem, why don't you just lower it for the dragons?

That would work, but I still think that firing should take more ACP.

I tried re-configuring the game so that nothing can fire if its target
is less than 2 cells away.  I haven't tested it enough to see if it
works correctly, but I'll let you know how it turns out.

> 
> >What I meant was that I don't have a clue where one would start when it
> >comes to programming the AI to take advantage of units that can edit
> >terrain, at least beyond editing connection types.
> 
> Yes. The basic problem is that the ai was written for the old Empire-style
> xconq. That is why so many features from the civ-type games are still
> unsupported. We would really need to write a new ai from scratch to handle
> all this stuff.

Hmm.  Can't help you there.

> 
> >Jim Kingdon mentioned that the AI doesn't do a whole lot of planning
> >before choosing a spot to build stuff.
> 
> If it is going to build an advanced unit (a civ-type city) it picks the
> spot very carefully to maximize production. But for other units, it doesn't
> care.

I guess that explains why in Empire-style games (including
"standard.g"), the placement of bases is not often chosen with a lot of
strategic forethought.  Sometimes, I find that the AI puts a base within
its own land, thereby making only useful for the small amount of fuel
and ammo it produces.  On the other hand, if I land on the side of a
continent opposite the enemy's homeland, I might build a base there so
that I could easily get units with high fuel requirements (i.e.
aircraft) near their targets.

Even when the placement of something doesn't significantly impact its
production, it does impact its strategic value.  Some day, when the
network code is working fine, this may be a worthwhile thing to look at.
(Is this what Jim was talking about?)

> 
> >I tried changing the acp-to-attack for places to zero, so that they can
> >defend themselves but not attack.  I ended up getting some kind of "bad
> >utype" error in every game, which quickly causing Xconq to segfault
> >(Fatal error 11 on UNIX).  For the moment, places can still fight, but
> >I'm working on fixing it so that places can't attack but they can defend
> >and Xconq won't segfault.
> 
> The easy way out is of course to set up your places like in other games (no
> attck, no defense on its own). However, xconq should not segfault only
> because you are trying to do things differently. This is by definition a
> bug. If you send me a stack dump, I will see what I can do.

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.


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