Re: Table: hit-by

[Hans Ronne <hronne at telia dot com>]

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

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.

There are quite a few unimplemented or partially implemented features like
this is the kernel. One other example is the fact that all firing functions
take an mtype argument which is currently unused. My strategy has been to
complete things that are easily completed, remove stuff that cause
problems, and otherwise leave such code in place to be completed at a
future date .

Hans