Re: CRT Combat Model (really long)

[Hans Ronne <hronne at pp dot sbbs dot se>]

>What if I could put the independent places at most three cells away from
>the place where the human starts?

Might work. Anyway, I just found that the function used in this case,
random_walk, is causing some of the synch errors. For reasons that I really
don't understand, it computes differently on a unix host and client. So I'm
going to rewrite it to work like the colonizer random walk, which perhaps
also will solve the "get stuck" problem if we are lucky.

NOTE: if anybody who is reading this understands why random_walk (in
plan.c) does not give the same result on a unix host and a unix client, I
would be very interested to hear.

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.

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

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

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

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

>> Because you allow them to fight! This is not how places work in most games.
>> Check out advances.g or 3rd-age.g.
>
>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.

Hans

Hans Ronne

hronne@pp.sbbs.se