Re: Error handling

[Lincoln Peters <peters2000 at mindspring dot com>]

On Mon, 2003-01-06 at 04:22, Hans Ronne wrote:
> >One thing I am finding the debug output constantly repeating is:
> >
> >s2 e 5 (33,8) (mplayer) seeking victim within 4; found nothing
> >s2 e 5 (33,8) cannot colonize, got passive plan instead
> 
> OK, so the problem is exactly what I thought it would be. If you check the
> sources, you will see that this debug message comes from assign_to_colonize
> in ai.c. Obviously, your engineers fail to find a single unit type that
> they can build, and therefore cannot set a main goal (unit to build). If
> you set a breakpoint at the start of the function and step through the code
> you will find out why. The most likely reason is that the side_can_build
> macro returns zero since the tech for the bases has not been developed yet.
> If your bases are not advanced units, that would also prevent the
> colonizers from building them.

Yes, they are advanced, but they aren't acp-independent.  I didn't make
them acp-independent because I knew that it wouldn't work well with the
tech and toolup code.

Looking at the code, I can see that the engineers theoretically will
never decide to build towers or walls, because towers and walls can
never build engineers.  Of course, the use of walls requires a far
greater defensive thought process than the AI has right now.  The tower,
on the other hand, is a very simple and very effective way to defend an
area (especially the home front), and I think that with a little work,
the AI could be made to understand it better.  Perhaps unit1 should not
just consider if unit2 can build more of unit1, but also if unit2 can
build anything else.

Perhaps the first thing that needs to be revised is the could_create
function.  Which file is it in?


> >This doesn't make much sense; what does colonizing have to do with
> >searching for a victim?  Wouldn't that be more appropriate for offensive
> >or defensive units?  Furthermore, the engineer is a terrible combat
> >unit; the only combat jobs that it's skilled at are clearing wreckage
> >and demolishing fortifications.
> 
> Well, all units check for nearby enemies to attack before executing their
> plan, provided that they have any offensive value at all. This is part of
> the action-reaction code that I added two years ago, which makes the AI
> respond much faster to threats. I agree that we could have some kind of
> reality check to see if it makes sense for one unit to attack another one.
> Obvioulsy, you don't want to throw your weakest units against a battleship.
> The problem is that we have two combat models, so there is no easy formula
> that would work in all cases.

Engineers are completely worthless in all combat situations except siege
warfare (i.e. when a side needs to break through a wall) and cleaning up
after a battle (i.e. removing wrecks).  They can defend themselves from
attackers, but not very well.

If an engineer sees an enemy unit, more than likely it should run away
rather than attack.  Throwing an engineer against a cacofiend, for
example, is just plain crazy.

> 
> >I also see that the base has an "Exploratory" plan (not a "Colonizing"
> >plan) when it decides to build engineers.  Interestingly enough, the
> >engineer has a colonizing worth of 90 (all other are worth 0), and an
> >exploring worth of 24.  However, the most valuable exploratory unit is
> >the spy-plane, which has an exploring worth of 144.  And yet I have
> >*never* seen the AI build a spy plane!
> 
> Is it possible that your bases are non-advanced units (see above)? In that
> case, you are out of luck. The new unit worth forumlas are only supported
> in the advanced unit building code (auto_pick_new_build_task in run.c). For
> non-advanced units, the AI uses a much simpler formula that you can find in
> plan_explorer_support (plan.c). It just checks all unit types that can
> explore and has a 50% chance of building the first one, then a 50% chance
> of building the next one etc. So if your spy plane is at the end of the
> unit type list, it will never get that far. And it will not use the
> exploring_worth function at all.

Actually, the base can build any of three things: a base, a tower, and a
wall.  The base is the primary producer of everything.  The tower is
neither advanced nor acp-independent, but it can fire at enemy units and
build explosives (rockets and such).  The wall is nothing more than an
impassible barrier with 1,000 HP (a tank has 50 HP), and so doesn't act
in any way.

> 
> >I also see that, for some reason, the base decided to "build engineer as
> >a base for itself".  What does that mean?  Is it treating engineers like
> >supply wagons?  It also seems to think that engineers are excellent
> >offensive units (offensive worth 3075), more even than a helicopter
> >(offensive worth 1845) or a battleship (offensive worth 1968)!
> 
> Doesn't make sense to me. I never used this code in any of my games, but I
> though the point was to have mobile units building resupply bases in enemy
> territory. Sometimes, you can see the infantry doing that in the standard
> game. Possibly, this code identifies bases as a unit type that can build
> the builder. In that case, it would return true, since engineers can build
> bases. Not what you would like to happen, though.

I don't have any setup for bases like those in the standard game.  The
closest thing to such units that I have is a platform that can carry 12
ground units of any type (mostly artillery, but anything up to tank-size
or ogre-size) into battle.

What is confusing the AI may be that the engineers are built to quickly
clear wrecks and demolish fortifications, and so can do 6d6 damage to
any wreck and any wall.  Most military units can only do 1d6 damage. 
The engineer, however, can *only* attack wrecks and walls.

> 
> As for the offensive worth values, that also seems strange. Is it possibe
> that the engineer can hit many more unit types than the battleship or
> helicopter? That factors into the offensive worth. You can always sit down
> and do the math since you know how the worths are calculated. Or
> alternatively, set a breakpoint and step through the code for each unit
> type.

No, I am certain that the engineer can only attack four units: the wall,
the small wreck, the medium wreck, and the large wreck.  It can defend
itself against other types of units, but can never attack them.

> 
> Looking at offensive_worth, I also see a possible bug. u_range(u) is
> factored into the final worth, which I doubt it should be. This is unlikely
> to be a problem in this case, though, since it defaults to 1.

You mean firing range?  I do have my game set up so that different
firing units can fire at different ranges.  Most units can fire at up to
a range of 4, but artillery can fire at up to a range of 6, and a tower
can fire at up to a range of 8.  That does mean, for example, that
artillery is more effective at a distance, and consequently is quite
valuable.  Of course, firing range is meaningless for units that don't
fire (such as a battledroid).

Engineers, naturally, don't fire at all.

> 
> >It also makes no sense to me that an engineer would sit around passively
> >when its supply runs low.  Should such a condition force the engineer to
> >re-plan?
> 
> The repair, rearm and resupply code is problematic. It is kind of a hack
> that bypasses plan execution. Sometimes units get trapped in there for
> mysterious reasons. I have fixed several bugs affecting this code, but I
> bet there are more to be found. But to answer your question directly: no,
> the unit should not replan since this code bypasses plan execution. What it
> should do is to move to a base where it can resupply. If it fails to do so,
> then there is a bug somewhere.

It seems to me that every mobile unit *except* the engineer is able to
move to the nearest base or tower and resupply when it needs to.


-- 
Lincoln Peters <peters2000@mindspring.com>