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

[Hans Ronne <hronne at comhem dot se>]

>There is also the problem of what should happen if the targeted unit is not
>there, but something else is sitting in the cell instead (not an uncommon
>situation). My feeling is that fire-at should somehow default to fire-into.

Thanks for the feedback, all of you. I think simplifying the action code is
important, and in the end may decide Xconq's viability as a project.
However, there are clearly some problems that first must be solved, the
most important one being how to pick the best defender without making it
impossible to hit a cell.

Meanwhile, I think I know how to fix the various bugs and exploits that we
discussed, simplify both the AI code and the interface, and maintain some
selectivity. The key is the above-mentioned notion of defaulting fire-at to
fire-into in the absence of the intended target.

Here is my new agenda:

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.

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.

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. 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").
Third, a failed fire-at action cannot hit other units in the target cell,
even though you are shelling them with real ammo.

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

For attack actions, the non-selective default would be identical to an
overrun action, except for the fact that the attacking unit would not move
into the cell. Jim's example with sub hunting would work like this: each
time you hit 'a' a real attack would be executed even if the target cell
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.

4. Combat resolution. I think the proposed changes to the overrun and
fire-into actions could still be implemented within this revised agenda. By
this I mean the notion that one attack should spend 1 acp and 1 round of
ammo, and as a consequence hit only one unit in the stack. This would also
make model 0 overruns more similar to model 1 overruns, which is a good
thing for several reasons (code sharing, AI design). As already discussed,
I think somewhat different schemes should be used to pick the target unit
in case of fire-into and overrun actions.

Hans