Re: Consumption-per-fire?

[Hans Ronne <hronne at comhem dot se>]

>> Because it doesn't seem that way.  This is
>> really quite confusing, what's the purpose of the
>> hit-by table??
>
>The purpose is what the documentation says it is. However, I agree that
>the name is somewhat misleading, and I once inferred a different use for
>it, before making it realize its intended purpose (according to Hans),
>and adding some notes to the documentation. I still find it interesting
>that it allows negative values down to TABLO rather than -1 (and I think
>it was this way prior to me touching it last year).

For those who don't remember the discussion about this last year, here is
an excerpt:

Eric:

>The WWII Advanced game is making incorrect use of the hit-by
>table.

Hans:

So does tailhook and galaxy2. I think this is a case where Stan was about
to add a new feature but did not carry through with it in the kernel. It
would be easy enough to complete the job by multiplying in the hit-by value
in the relevant places (both check and execute code):

um_consumption_per_fire(unit->type, m) * um_hit_by(unit2->type, m)

This would make ammo consumption dependent not only on the firing unit, but
also on the target, allowing for the possibility that hard targets require
more ammo to be hit. The hit-chance table can of course accomplish a
similar restriction, but the interesting difference is that in the latter
case, the acps become limiting rather than the ammo.

As a side note, these games are special in that they treat airplanes as
ammo and airfields as firing units. Which is probably why Stan was
experimenting with the hit-by table (you can't counterattack and shoot down
a piece of ammo). It illustrates the flexibility of game design in xconq.
An opposite example is the original galaxy game, where each torpedo is a
small unit rather than a piece of ammo.

Hans