From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27903 invoked by alias); 5 Jun 2004 08:11: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 27880 invoked from network); 5 Jun 2004 08:11:29 -0000 Received: from unknown (HELO av6-1-sn2.hy.skanova.net) (81.228.8.106) by sourceware.org with SMTP; 5 Jun 2004 08:11:29 -0000 Received: by av6-1-sn2.hy.skanova.net (Postfix, from userid 502) id 771EA37E45; Sat, 5 Jun 2004 10:11:28 +0200 (CEST) Received: from smtp2-2-sn2.hy.skanova.net (smtp2-2-sn2.hy.skanova.net [81.228.8.178]) by av6-1-sn2.hy.skanova.net (Postfix) with ESMTP id 6268C37E42; Sat, 5 Jun 2004 10:11:28 +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 1F22D37E45; Sat, 5 Jun 2004 10:11:27 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: <1086409175.1485.54.camel@localhost.localdomain> References: <20040605033742.12312.qmail@web13123.mail.yahoo.com> <20040605033742.12312.qmail@web13123.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 05 Jun 2004 08:11:00 -0000 To: Eric McDonald From: Hans Ronne Subject: Re: Consumption-per-fire? Cc: xconq7@sources.redhat.com X-SW-Source: 2004/txt/msg00472.txt.bz2 >> 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. Defaulting to 1 is OK provided that game designers are aware of the consequences. You would then have to explicitly disable hit-by for any units that you don't want to be hit by a particular ammo. I'm not sure if this is more logical (or less work) than enabling hit-by for units that can be hit. >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. This would certainly work, and somewhat extent the possibilities of game design. However, I doubt these extra range tables would be of much use. The reason why I put a range restriction of 1 on capture-by-fire (and I believe I did that at some point) is that I thought that capture-at-a-distance was inherently silly. To me, capture implies some kind of direct physical control, which you cannot exert from a remote position. This also made the capture-by-fire work the same way as capture-by-attack, which already is limited to adjacent units by the attack code itself. >(b) Ammunition should also be able to be selectively consumed by >attacks. It already is. That is what the consumption-per-attack table is for. >(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. I would concur with this. >> 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. This bug I could not reproduce. If the monster runs out of "test" and I try to fire (or fire into) I get the "not enough ammo" error message. It doesn't waste any ACPs. >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. I'm not sure about this. Many units that can fire are specialized at that and not very good at melee combat. Forcing them to attack when out of ammo would therefore be a bad idea. Moreover, it's hard enough to get the AI to use units that can fire properly (that is to fire at a distance and avoid rushing into combat), as already discussed on this list. Hans P.S. As a final note, some of the problems with consumption-per-fire are due to the fact that you can use the fire-into action to fire at invisible units. To avoid leaking info about unseen units back to the attacker, check_fire_into_action therefore calls enough_ammo_to_fire_one_round which does some kind of general check for ability to fire. However, I'm not sure that this code, which bypasses the use of the hit-by table, works as expected in all cases.