public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Hans Ronne <hronne@comhem.se>
To: Lincoln Peters <sampln@sbcglobal.net>
Cc: xconq7@sources.redhat.com
Subject: Re: Bug in acp-independent action code
Date: Wed, 16 Jun 2004 21:00:00 -0000	[thread overview]
Message-ID: <l03130305bcf659ae77fc@[212.181.162.155]> (raw)
In-Reply-To: <1087332680.10779.4120.camel@odysseus>

>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


  parent reply	other threads:[~2004-06-16 21:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-11  6:17 Lincoln Peters
2004-06-11  6:40 ` Hans Ronne
2004-06-12  6:45   ` Lincoln Peters
2004-06-12  9:01     ` Hans Ronne
2004-06-13 21:45     ` Hans Ronne
2004-06-14 23:34     ` Hans Ronne
2004-06-15  4:55       ` Lincoln Peters
2004-06-15  7:18         ` Hans Ronne
2004-06-15 20:51           ` Lincoln Peters
2004-06-16  4:08             ` New Wreck-Type Options Elijah Meeks
2004-06-16 13:49               ` Eric McDonald
2004-06-16 21:00             ` Hans Ronne [this message]
2004-06-15  5:19       ` Bug in acp-independent action code Eric McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='l03130305bcf659ae77fc@[212.181.162.155]' \
    --to=hronne@comhem.se \
    --cc=sampln@sbcglobal.net \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).