From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25384 invoked by alias); 15 Jun 2004 20:51:03 -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 25375 invoked from network); 15 Jun 2004 20:51:02 -0000 Received: from unknown (HELO smtp814.mail.sc5.yahoo.com) (66.163.170.84) by sourceware.org with SMTP; 15 Jun 2004 20:51:02 -0000 Received: from unknown (HELO ?192.168.1.100?) (sampln@sbcglobal.net@67.123.172.102 with plain) by smtp814.mail.sc5.yahoo.com with SMTP; 15 Jun 2004 20:51:01 -0000 Subject: Re: Bug in acp-independent action code From: Lincoln Peters To: Hans Ronne Cc: Xconq list In-Reply-To: References: Content-Type: text/plain Message-Id: <1087332680.10779.4120.camel@odysseus> Mime-Version: 1.0 Date: Tue, 15 Jun 2004 20:51:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00555.txt.bz2 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 Do not underestimate the power of the Force.