Re: Major bug and what to do about it (long)

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

On Tue, 17 Aug 2004, Hans Ronne wrote:

> 1. Getting rid of unit pointers in the task code. I have looked into the
> possibility of feeding unit views instead of units to the attack and
> fire-at actions, as suggested by Stan, and I think it can be done. Most of
> the problems are related to interface callbacks that ask for real units,
> but I think they can be fixed with a reasonable amount of work.

Good.

> 2. Unit view clearance. This will not fix the unit view bug, since the AI
> will continue to schedule futile hit-unit tasks as long as the bogus view
> is around. Clearly, we must clear the view. I think the best way is to make
> the failed action return a new result A_UNIT_NOT_FOUND that triggers
> clearance of the bogus view at a certain rate. I will make this rate a
> utype property. One failed hit should be enogh to tell that a metropolis is
> not located where it is supposed to be, but the view of a guerilla unit may
> take longer to clear.

I would add that this should only be applicable in the case of 
firing. In the case of attacking, which seems to be a bit more 
personal and up-close, I think the unit view should disappear 
instantly if there is not a real unit to prop it up.

> 3. Interface simplification. As already discussed, there are several
> problems with the current situation. First, there are the various exploits
> that make it possible to obtain information about the real world by bogus
> actions. 

What does this have to do with interface simplification? Let's fix 
the exploits.

>Second, the task code is second-guessing the player, telling him
> what he may or may not do ("No visible unit to fire at in that cell").

What does this have to do with interface simplification? Let's fix 
the task code.

> Third, a failed fire-at action cannot hit other units in the target cell,
> even though you are shelling them with real ammo.

And this is a bad thing because?

> I think the best way to fix these problems is to make a selective action
> default to the corresponding non-selective action if the intended target
> cannot be found. This would fix all current and future exploits in one
> stroke, since an attack or fire command always would result in an action
> being executed, with acps and ammo being spent.

It also automatically switches action types on a player without 
his or her explicit consent.

> It would also make the human interface simpler. You would no longer need to
> switch to fire-into mode (ctrl-f) in order to shell an apparently emtpy
> cell. The normal fire-at command would do the job.

This can be taken care of merely by swapping the bindings for "f" 
and "CTRL-f" as I suggested earlier.

> The only reason to ever
> use an explicit fire-into command would be the unlikely situation where you
> want to shell a cell but avoid targeting any of those enemy units that you
> can actually see.

Or to fire into an apparently empty cell to see if you can manage 
to hit anything. (I think one of the areas of confusion arising in 
this discussion is that the current implementation of 'fire-into' 
applies the full hit-chance, if I remember the code correctly, to 
the first unit it finds in a cell; I think this, in itself, is 
broken, and that, unless spread damage is in effect, the chance of 
'fire-into' hitting something should be miniscule and weighted by 
the discovered target's 'size-in-terrain'.)

> seems to be empty. The attack may or may not hit any invisible subs in the
> cell. This would be completely analogous to real life sub hunting using
> depth charges. No more bogus attacks.

Good. This is reasonable.

I would suggest two actions: 'attempt-attack' and 'attempt-fire'. 
Each would take a UnitView*, x and y coords, and possibly a 
number-of-times-to-execute argument. If the the UnitView* is NULL, 
then it should mean attempt an overrun in the 'attempt-attack' 
case, and do a fire-into in the 'attempt-fire' case.

(1) If the kernel determines that the unit view passed to the 
attempted action no longer corresponds to an unit at the position, 
then:
(a) in the case of an attempted attack, it expends ammo and 
ACP and returns 'A_UNIT_NOT_FOUND', as suggested by Hans. The 
unit view should be removed immediately.
(b) in the case of a fire-at, it expends ammo, has the UI draw 
firing lines, and then returns 'A_UNIT_NOT_FOUND', if, after a 
dice roll or random number in a probability, it is 
determined that the firing unit has discovered that it is firing 
upon something that is not there.

(2) If the kernel determines that the unit view corresponds to an 
unit at the position, then:
(a) in the case of an attempted attack: run the attack code as 
normal.
(b) in the case of fire-at: run the fire code as normal.

(3) If the kernel is dealing with a NULL unit view, then:
(a) in the case of an attempted overrun: run the overrun code with 
the ACP/materials deduction modifications suggested by Hans.
(b) in the case of a fire-into: run the fire-into code with the 
hit probability modifications suggested by me.

Is this creating more complexity and more code to maintain? Yes 
and no. One might note that the only real difference between case 
(1) and case (2) is that 'damage_unit' gets called in case (2) 
whereas it does not in case (1). Thus, there is much code in 
common between those cases. OTOH, we are adding some new logic, 
and would have twice as many action checks as before: the existing 
versions, which would be for internal kernel usage, and new 
versions, which would be for use by the AI and UI.

Eric