Re: Bug in acp-independent action code

[Hans Ronne <hronne at comhem dot se>]

>I remember the discussion.  However, the last time I checked, I still
>needed to set material-to-build (and other material-to-... tables)
>because otherwise a unit could continue doing whatever it was doing,
>even if it ran out of the required material(s).

In that case something else must be wrong with your module. None of the
other games with acp-independent units use material-to-build.

>> 1. The easiest fix is to get rid of material-to-build, at least until it is
>> supported for acp-independent units.
>
>I suppose I could re-configure the module so that only
>non-acp-independent units (conjurers and necromancers) are affected by
>material-to-build.  They need the material-to-build code because
>otherwise they could continue to build after they exhaust their supply.

check_build_action checks that the supply needed by build_step_consumption
is available, so if the unit-consumption-per-build tables are set
correctly, material-to-build should not be needed. If it is, we may have a
bug in the build code.

>> 3. The third fix would be to get rid of the safety valve in task execution
>> and allow units to retry forever with the failed task. Granted, tasks may
>> be temporarily impossible, in which case going into reserve and retrying
>> next turn make sense. However, as you can see in the above code, the unit
>> goes into reserve only after it killed the task. I think it might make
>> sense to instead save the task (whether a build task or a move task) and
>> try again next turn when the conditions have changed.
>
>In that case the cure may be worse than the disease.  Imagine the
>frustration in the standard game if a battleship or carrier (or a
>similarly expensive unit in another game) ran out of fuel because
>something blocked its path to the supply point, and the player never
>caught it because the plan was never canceled.

There is another safety valve in execute_plan that cancels the plan it
after 1000 failed attempts. And then there is code in the mplayer that will
put the unit in reserve if things don't work out. The question is how many
of these safety valves we need and where they should be. I would prefer one
only, so that errors are handled in a predictable way.

Hans