Re: Consumption-per-fire?

[Eric McDonald <mcdonald@phy.cmich.edu>]

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