Re: Consumption-per-fire?

[Hans Ronne <hronne at comhem dot se>]

>>   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.