From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12908 invoked by alias); 16 Jun 2004 21:00:22 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 12901 invoked from network); 16 Jun 2004 21:00:21 -0000 Received: from unknown (HELO av7-1-sn2.hy.skanova.net) (81.228.8.108) by sourceware.org with SMTP; 16 Jun 2004 21:00:21 -0000 Received: by av7-1-sn2.hy.skanova.net (Postfix, from userid 502) id E9D5237E50; Wed, 16 Jun 2004 23:00:20 +0200 (CEST) Received: from smtp2-2-sn2.hy.skanova.net (smtp2-2-sn2.hy.skanova.net [81.228.8.178]) by av7-1-sn2.hy.skanova.net (Postfix) with ESMTP id DBD3D37E42; Wed, 16 Jun 2004 23:00:20 +0200 (CEST) Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp2-2-sn2.hy.skanova.net (Postfix) with ESMTP id 2575837E49; Wed, 16 Jun 2004 23:00:20 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: <1087332680.10779.4120.camel@odysseus> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Jun 2004 21:00:00 -0000 To: Lincoln Peters From: Hans Ronne Subject: Re: Bug in acp-independent action code Cc: xconq7@sources.redhat.com X-SW-Source: 2004/txt/msg00558.txt.bz2 >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