This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug in acp-independent action code


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

I see. But there is no reason why non-acp-independent units should require
material-to-build to be set, either. This is the relevant code in
check_build-action:

        if (totsup < um_to_build(builder->type, m)) {
           return A_ANY_NO_MATERIAL;
        }
        if (totsup <  build_step_consumption(builder->type, newunit->type,
m, newunit->cp)) {
           return A_ANY_NO_MATERIAL;
        }

build_step-consumption checks um_consumption_per_build. So you should not
need to set um_material_to_build. If this is indeed required, this is a bug
somewhere.

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

Not really, since the game will wait for the unit to complete its 1000
failed attempts before proceeding to the nct turn, But uf many units do
this, it ill slow done the game.

Hans



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]