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

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

On Tue, 17 Aug 2004, Hans Ronne wrote:

> >What does this have to do with interface simplification? Let's fix
> >the exploits.
> 
> The exploits are an interface problem. By eliminating the cause of the
> problem (the ability to attempt bogus actions) you fix all possible
> exploits in one stroke.

I don't think that killing the patient is a good way to cure the 
diesease. Can we please just keep existing functionality while 
fixing the problems with it, instead of ripping out functionality 
as a way of fixing the problems?

> >What does this have to do with interface simplification? Let's fix
> >the task code.
> 
> Which is what getting rid of bogus actions is all about.

Properly dealing with bogus actions does not (or should not)  
entail removing two actions.

> >> 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?
> 
> Because it does not make sense. The unseen units in that cell should not be
> "protected" from random hits only because we are trying to fire at
> something which is not there. 

Really? Unless the fire-at does spread damage, the other units in 
the cell _should_ have a greatly diminished chance of being hit. 
I am starting to feel like a broken record, arguing this point 
over and over again.

>This would mean that the state of the
> player's mind (the incorrect belief that a specific unit is sitting at x,y)
> would affect physical reality (the hit chances for units that really are
> sitting there).

How so?

> >This can be taken care of merely by swapping the bindings for "f"
> >and "CTRL-f" as I suggested earlier.
> 
> No. The point was to avoid the need to switch keys, and use only one
> command. Just swapping the bindings would not make things simpler.

I didn't say it would. It might, however, make things more 
convenient for the user.

> >Or to fire into an apparently empty cell to see if you can manage
> >to hit anything.
> 
> On the contrary, this is something that you could do with the normal fire
> command, if it defaults to a fire-into command for an empty cell. This is
> the whole point of the defaulting mechanism.

You call it defaulting. I call it overloading.

> >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.
> 
> If I understand you correctly, this is pretty much the same thing as I
> suggested. By defaulting fire-at to fire-into I mean that a fire-at action
> with a bogus or NULL unit view would instead lead to a fire-into action
> that uses the coordinates of the target cell.

Hans, I think a lot of our disagreement stems from which working 
definition of 'fire-into' we are using. By 'fire-into' do you mean 
fire and hit the first unit in the stack or a randomly (possibly 
weighted by size) chosen unit from the stack? Or, do you mean that 
there is a real possibility that nothing is hit even if there is a 
stack of units in the cell? I have been arguing thinking that you 
are working from the former definition, but have been urging that 
we adopt the latter one.

Eric