Re: Error handling

[Hans Ronne <hronne at telia dot com>]

>On Sun, 2003-01-05 at 14:12, Hans Ronne wrote:
>> I don't think wizard.g ever worked that well. As for your problem, the
>> first thing I would do is run xconq in debug mode for the mplayer (command
>> line flag -DM). At the beginning of the output file, you will find the unit
>> worth calculations. Look for "colonizing worth" and check if it is non-zero
>> for your engineers. I suspect the need to develop tech etc. may set it to
>> zero in which case the AI doesn't know what to do with them.
>
>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.

Generally, I would advice against using tech development, at least in
advanced games. It's not fully supported everywhere in that code.

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

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

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

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.

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.

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

Hans