Re: Overrun actions (was: Consumption-per-fire?)

[Hans Ronne <hronne@comhem.se>]

>> Ideally, the unit should try the attack mode that has the highest
>> probability of success first, and then use the other mode as backup,
>> if necessary.
>
>What if some materials are more precious than others?  Or one attack
>does more damage than the other?  It seems better to let the
>player choose, rather than guess which one they might want.

One would need an easy way to pick attack mode while clicking on a unit in
that case. Perhaps left-clicking and right-cliclking, to the extent they
are both available, could do the job?

>> The other way to fix this bug is to eliminate the possibility of doing
>> overruns by fire.
>
>This makes more sense to me.
>
>Since there will be cases in which either attack or fire is possible,
>it seems like the user interface is clearer if the player (or AI) has
>to explicitly say which one (the "a" and "f" keys being the most
>explicit way, with overrun meaning attack-and-move-if-possible, rather
>than attack-or-maybe-fire-and-move-if-possible).

Right. But things are simpler for units that only can fire. And I think
this is true for most firing units. The bug manifested itself in Elijah's
game precisely because the godzillas are able to both attack and fire.

>> I think this was also how the overrun code originally worked, as
>> revealed by check_overrun_action. The firing code in do_overrun_action
>> was probably added at a later point.
>
>Well, for what it is worth, it was added by:
>
>Tue Jun  1 18:41:59 1999  Hans Ronne  <ronne@bmc.uu.se>
>
>	* combat.c (do_overrun_action): Make ovverun after fire possible.
>	(check_overrun_action): Make overrun after fire & into empty cell
> 	possible.

Heh. Well, I thought the code looked familiar :-). I do remember a problem
with units that can fire being unable to advance into empty cells. This may
have been an attempt to fix that.

Hans