From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23012 invoked by alias); 15 Jun 2004 07:18:09 -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 22720 invoked from network); 15 Jun 2004 07:17:45 -0000 Received: from unknown (HELO av8-1-sn2.hy.skanova.net) (81.228.8.110) by sourceware.org with SMTP; 15 Jun 2004 07:17:45 -0000 Received: by av8-1-sn2.hy.skanova.net (Postfix, from userid 502) id C86FB37E49; Tue, 15 Jun 2004 09:17:38 +0200 (CEST) Received: from smtp2-2-sn2.hy.skanova.net (smtp2-2-sn2.hy.skanova.net [81.228.8.178]) by av8-1-sn2.hy.skanova.net (Postfix) with ESMTP id BBFC437E42; Tue, 15 Jun 2004 09:17:38 +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 9C4AA37E42; Tue, 15 Jun 2004 09:17:41 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: <1087275319.18372.3130.camel@odysseus> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Jun 2004 07:18:00 -0000 To: Lincoln Peters From: Hans Ronne Subject: Re: Bug in acp-independent action code Cc: X-SW-Source: 2004/txt/msg00552.txt.bz2 >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