This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Major bug and what to do about it (long)
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Hans Ronne <hronne at comhem dot se>
- Cc: xconq7 at sources dot redhat dot com
- Date: Tue, 17 Aug 2004 17:14:44 -0400 (EDT)
- Subject: Re: Major bug and what to do about it (long)
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