Re: Bug in acp-independent action code

[Lincoln Peters <sampln at sbcglobal dot net>]

On Tue, 2004-06-15 at 00:14, Hans Ronne wrote:
> >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.

I didn't explain that very well.  I meant that I needed to set
material-to-build so that non-acp-independent units would function
properly.  I can try setting it up so that material-to-build *only*
affects non-acp-independent units.

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

Most likely, yes.

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

Of course, if a unit doesn't re-plan before it's re-tried and failed
1,000 times, the game will most likely be over before the unit can do
anything useful.

---
Lincoln Peters
<sampln@sbcglobal.net>

Do not underestimate the power of the Force.