From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27697 invoked by alias); 5 Jun 2004 04:22:30 -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 27682 invoked from network); 5 Jun 2004 04:22:27 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 5 Jun 2004 04:22:27 -0000 Received: from [67.172.156.222] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (sccrmhc13) with SMTP id <20040605042226016000ms74e>; Sat, 5 Jun 2004 04:22:26 +0000 Subject: Re: Consumption-per-fire? From: Eric McDonald To: Elijah Meeks Cc: Hans Ronne , xconq7@sources.redhat.com In-Reply-To: <20040605033742.12312.qmail@web13123.mail.yahoo.com> References: <20040605033742.12312.qmail@web13123.mail.yahoo.com> Content-Type: text/plain Message-Id: <1086409175.1485.54.camel@localhost.localdomain> Mime-Version: 1.0 Date: Sat, 05 Jun 2004 04:22:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00470.txt.bz2 On Fri, 2004-06-04 at 21:37, Elijah Meeks wrote: > > The purpose is what the documentation says it is. > > However, I agree that > > the name is somewhat misleading, > > Somewhat? There's no mention of a second necessary > table in consumption-per-fire Well, probably it should mention that it needs to be used with the 'hit-by' table. > and even though hit-by > is right next to it on the list, when the > documentation for consumption-per-fire says "Specifies > how much a material m will be used as ammunition when > a unit u1 is firing." it sounds pretty > straightforward. I guess if I was a newbie designer and wanted to add firing, I would be reading the whole damn manual section and not just one entry. > I'd think if a designer was defining > this table, you'd think the hit-by would default to > true (Or 1 or whatever). Why would anyone go through > the trouble of defining a consumption-per-fire table > and then not want it to apply? I have thought that 1 would probably be a better default as well. However, I did not touch that table when applying the 'hit-by' multiplier logic; so, whatever was put in as the default, by whoever added that table, is what is still there. I think some of this comes down to the meaning of firing. It seems to differ from an attack in that: (1) It does not imply any movement on the part of the firing unit (i.e., no overruns, etc...). (2) Capture-by-fire can only occur if the firing unit is adjacent to the defender. (3) Ammunition can be selectively consumed based on the nature of the defender. Personally, I think that: (a) There should be no built-in range restriction on capture-by-fire. Instead, both attack and fire should have enabling tables 'capture-by-attack' and 'capture-by-fire', plus range restriction tables on these types of capture. (b) Ammunition should also be able to be selectively consumed by attacks. (c) The only real distinction between firing and attacking should be that firing does not imply movement of the firing unit, whereas an attack should (though it would not be noticeable in the case where an overrun or capture failed). Furthermore, if a 'capture-by-attack' table existed, I would expect it to default to true, whereas I would expect a 'capture-by-fire' table to default to false. > All that means a unit that has both an attack and a > fire will not default to its attack after running out > of ammo. Instead, it wastes ACP. Well, I doubt that it should be wasting ACP on a bogus fire action; this would likely be a bug. As far as failing over to an attack if a unit can no longer fire, this sounds like a worthy feature request that could be fairly easily dealt with in the attack/fire task logic. Eric