Re: Error handling

[Hans Ronne <hronne at telia dot com>]

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

So then the tech development is the culprit, since side_can_build always
will return zero for something that has not been developed yet.

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

The problem here is rather the plan. Right now, a unit that can colonize
(build units that can build other units, not necessarily of the first type)
will always be assigned PLAN_COLONIZING. The theory here is that colonizing
is a very important activity that is essential for winning the game. Thus,
units who can colonize should not waste time on building other stuff. What
you are asking for, is the possibility to do exactly that. This would
require a hack to the mplayer where say 10% of the colonizers were assigned
another plan, such as PLAN_DEFENSIVE, to build defensive units. There is a
catch here, though: mobile units will build stuff if assigned
PLAN_DEFENSIVE (or any other plan) only if they have zero defensive worth
etc (see mplayer_decide_plan). Which is not the case for you. In short, the
concept of mobile builders is not well supported in the code.

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

So in this case the problem is that your bases are acp-independent (it is
this that matters rather than if they are advanced) and therefore use the
old code in plan_explorer_support . I am willing to bet that your spy plane
is well down the unit list.

>> >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)!

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

Well, this makes sense (to the AI at least). It does high damage and
therefore has high offensive worth.

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

So perhaps you should do some more debugging to finds out what these
engineers are doing instead.

Hans