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

[Hans Ronne <hronne at comhem dot se>]

>> 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.

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.

>>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.

Which is what getting rid of bogus actions is all about.

>> 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. 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).

By defaulting fire-at to fire-into, we avoid this absurdity and fix the
exploits at the same time.

>> 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.

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.

>> 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.

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.

>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