Major bug and what to do about it (long)

Major bug and what to do about it (long)

[Hans Ronne]

I've been doing some heavy game testing and found a large number of bugs. I
will check in fixes to most of them soon. However, one bug (or perhaps
rather a design flaw) is particularly insidious, and will require major
code surgery to fix. I would therefore like to get some feedback before I
proceed.

The problem has to do with the difference between unit views and real
units, and the two types of attacks that are possible (both for normal
attacks and fire actions, respectively).

Typically, the AI will look for possible targets near a unit and then set a
hit_unit task. This task specifies the position, type and side of the
target, but not (and this is important) the actual unit. The reason for
this is that the AI sees only unit views, which may be real or not.

So far so good. However, when do_hit_unit_task is executed, the kernel
cheats and looks up the actual unit. The reason for this is that both
do_attack_action and do_fire_at_action require a pointer to a real unit as
argument. A unit view or just a position will not do. This is because unit
views was a rather late addition to Xconq, which was grafted onto the
existing code.

The bug that I found works like this. First, the AI finds a target at
position (x, y) and sets a hit_unit task. However, when do_hit_unit_task
looks up the actual unit, it finds that the unit no longer exists or has
moved. The call to check_attack_action (or check_fire_at_action) fails and
the task itself also fails after 3 attempts (the latter restriction is a
recent hack by Eric who may have stumbled across the same bug).

Now the ball returns to the AI, who should find something else for our unit
to do. However, the AI still sees the same unit view and doesn't know that
the task failed, so it sets the same hit_unit task again. Since no acps are
consumed by failed tasks, this vicious cycle goes on until we hit the
ceiling on plan executions per turn (1000 attempts). At that point, our
unit is put into reserve mode, and rests until the next turn. This despite
the fact that it has not done anything and therefore not consumed a single
acp!

So what can we do about this? The obvious solution is to use
unit-independent versions of do_attack_action and do_fire_at_action, which
already exist in Xconq. They are called do_overrun_action and
do_fire_into_action, respectively.

Here is how these unit-independent actions work. The unit attacks (or fires
into) a cell (x, y). The code then attempts to hit each unit at (x, y) in
stack order. One round of ammo is consumed for each unit (whether you hit
it or not), so these kinds of attacks are more ammo-expensive then hitting
a single unit. OTOH, the same amount of acps are consumed at the end, so
you get a free shot at all units at (x, y) for the same acp cost as when
you attack a single unit! This is a huge advantage when you are dealing
with stacked units, as you are in many games. On the balance, I would
therfore say that these attack actions are more efficient than those who
target single units.

However, the AI does not use unit-independent attacks a lot. It relies
mostly on do_hit_unit_task, which targets single units. Hence the above
bug. In the human case, unit-indpendent normal attacks (overrun actions)
are favoured  by the interface code. Thus, clicking on an enemy unit
schedules an overrun action into that cell. To schedule an attack on a
single unit, you have to use the 'a' command instead. OTOH, if you do the
simplest fire command, i.e. press 'f' with a unit that can fire, you will
schedule a unit-dependent fire-at action. To do a fire-into action, you
must press 'ctrl-f'. So the interface code is not very consistent about
what it prefers.

I have given the above bug and its consequences some serious thought. Here
is what I think should be done:

1. We should eliminate the attack unit/attack position code split. Instead
of the four actions that are possible today, we should just have two:
do_attack_action and do_fire_action. These actions should be
unit-independent, i.e. work pretty much like the old do_overrun_action and
do_fire_into_action.

This would have a number of advantages. First, we could do away with unit
pointers in the combat code. The bug I just found would be fixed, and no
doubt many other bugs yet to be discovered. Writing new AI code would be
much easier without the code bifurcation. The interface could also be
simpler. For example, clicking on an enemy unit could schedule a normal
attack (overrun action) and right-clicking on it a fire action. No need to
use the keyboard at all. Yet another advantage with this scheme is that it
would make combat model 0 more similar to combat model 1, which only uses
overrun actions. This in turn would make it a lot easier to improve both
the AI and the combat code in the future.

2. I'm not sure, however, that do_attack_action and do_fire_action should
work exactly like do_overrun_action and do_fire_into_action do today.
Specifically, I don't like the fact that you get a free shot at every unit
in the cell for just one acp consumed, even if you have to pay for it in
ammo. It seems more logical that one attack (either normal or round of
fire) is just that, and that you consume 1 acp and 1 round of ammo each
time you attack. As a consequence, you should also be able to hit only one
unit (and possibly its occupants) each time you attack.

3. The question is then how to pick the unit to hit. I can see three
possibilities. The first is to hit units in stack order. This is easy to
implement and is therefore how things frequently work in the kernel, but I
don't think it is a good idea in this case. The second possibility is to
pick a unit at random, perhaps weighted according to unit-size-in-terrain.
The third possibility is to always pick the best defender, on the theory
that this is the unit that the defending side would send forward to meet
the enemy.

Combat model 1 already works like the third alternative (as does Civ2 on
which it is modelled). I think this would be a good way to handle normal
attacks also in combat model 0. This would make it even easier to deal with
the two co-existing combat models. The main difference between them would
remain the fact that a model 1 attack continues until death, while a model
0 attack continues only as long as the attacker wishes to continue and has
acps left.

4. However, I doubt that this is a good solution for fire actions, which by
their very nature are more random. In that case, I'm leaning towards a
size-weighted random target, as described above. In addition, the
probability of hitting something should be greater if there are several
units in the cell (or, in other words, the probability of hitting one unit
should not be reduced by the presence of other units in the same cell). One
could therefore imagine a scheme similar to do_fire_into_action where the
fire code tests all units in the cell. The main difference would be that
once a unit is hit, the iteration would stop, since the same round of ammo
cannot hit several different units. I think that this scheme would most
closely resemble the real life situation of artillery firing into a crowded
position occupied by several units.

It should be noted that fire actions are currently not supported in combat
model 1, so we don't need to worry about that aspect. OTOH, when we add
fire actions to combat model 1, which I plan to do, they should preferably
work exactly as in combat model 0.

These are my thoughts so far. The proposed changes would have profound
consequences for all games in the library, so they require some careful
thought. I cannot at present see a better way to deal with the underlying
problems, though.

Hans

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

[Eric McDonald]

On Mon, 16 Aug 2004, Hans Ronne wrote:

> Now the ball returns to the AI, who should find something else for our unit
> to do. However, the AI still sees the same unit view and doesn't know that
> the task failed, so it sets the same hit_unit task again. 

If the action check failed because the unit view doesn't not 
correspond to an actual unit at the given position, then the task 
logic should make a callback to the AI or UI to remove the unit 
view, IMO. This would break the cycle.

However, the unit should be penalized (in terms of ACP, 
material expenditure, etc...) for attempting the action on a 
"ghost" unit. I believe I have mentioned this before, either in 
private email or on the list. In that case, what motivated me to 
mention it was the fire-at-ghost-unit / fire-into cell case. I 
believe this was shortly after I made a fix so that one could not 
probe from cell to cell using the fire command to discover where 
hidden enemy units were.

I will reply in greater detail to some of your other thoughts 
after I get home tonight. There is a lot to carefully examine....

Eric

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

[Hans Ronne]

>On Mon, 16 Aug 2004, Hans Ronne wrote:
>
>> Now the ball returns to the AI, who should find something else for our unit
>> to do. However, the AI still sees the same unit view and doesn't know that
>> the task failed, so it sets the same hit_unit task again.
>
>If the action check failed because the unit view doesn't not
>correspond to an actual unit at the given position, then the task
>logic should make a callback to the AI or UI to remove the unit
>view, IMO. This would break the cycle.

Yes, I thought about that. However, since failed tasks do not consume acps,
this would provide a cost-free way to probe the terrain for real vs. bogus
enemy units. A better solution is therefore to use do_fire_into_action
instead, which will not fail because of the intended target being a bogus
unit, and clear the stale unit view if nothing is hit. It was this line of
thought that made me think that we perhaps should do away with
do_fire_at_action altogether, and, by analogy, also do_attack_action.

>However, the unit should be penalized (in terms of ACP,
>material expenditure, etc...) for attempting the action on a
>"ghost" unit. I believe I have mentioned this before, either in
>private email or on the list. In that case, what motivated me to
>mention it was the fire-at-ghost-unit / fire-into cell case. I
>believe this was shortly after I made a fix so that one could not
>probe from cell to cell using the fire command to discover where
>hidden enemy units were.

Letting the failed task consume acps might work in this specific case, but
it would go against how Xconq works in all other situations. For example,
if you click where your unit cannot move, you don't spend any acps. Plans
and tasks are supposed to be only brainchilds of the AI, so it makes sense
to consume acps and materials only when it actually does someting, i.e.
performs an action.

Hans

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

[Hans Ronne]

>>If the action check failed because the unit view doesn't not
>>correspond to an actual unit at the given position, then the task
>>logic should make a callback to the AI or UI to remove the unit
>>view, IMO. This would break the cycle.
>
>Yes, I thought about that. However, since failed tasks do not consume acps,
>this would provide a cost-free way to probe the terrain for real vs. bogus
>enemy units.

To follow up, this problem already exists with the current code. If I
switch off the AI and try to hit the same bogus unit view with a manual 'f'
command I get the anser "No visible unit there" (and no acp is consumed).
So probing the terrain for free is already possible, precisely because
do_hit_unit_task tries to do a fire_at_action (or an attack_action) instead
of a fire_into_action (or an overrun_action). Only the latter are really
safe to use in a unit view context.

Hans

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

[Eric McDonald]

Hans Ronne wrote:
>>On Mon, 16 Aug 2004, Hans Ronne wrote:
>>
>>
>>>Now the ball returns to the AI, who should find something else for our unit
>>>to do. However, the AI still sees the same unit view and doesn't know that
>>>the task failed, so it sets the same hit_unit task again.
>>
>>If the action check failed because the unit view doesn't not
>>correspond to an actual unit at the given position, then the task
>>logic should make a callback to the AI or UI to remove the unit
>>view, IMO. This would break the cycle.
> 
> 
> Yes, I thought about that. However, since failed tasks do not consume acps,
> this would provide a cost-free way to probe the terrain for real vs. bogus
> enemy units. 

No. Tasks don't consume ACP or anything else. Actions do. And, I don't 
see a problem if a failed action consumes ACP or materials. If an attack 
or a fire misses an actual unit, ACP is consumed in spite of the fact 
that it was a miss. How is attacking a ghost unit any different than a miss?

>A better solution is therefore to use do_fire_into_action
> instead, 

This depends a lot on whether the firing results in spread (surface) 
destruction or point destruction (to use the terms that Bruno Boettcher 
(?) used in a thread last year). In cases of point destruction, the 
action should be treated like a firing that missed. IMSO.

>>However, the unit should be penalized (in terms of ACP,
>>material expenditure, etc...) for attempting the action on a
>>"ghost" unit. I believe I have mentioned this before, either in
>>private email or on the list. In that case, what motivated me to
>>mention it was the fire-at-ghost-unit / fire-into cell case. I
>>believe this was shortly after I made a fix so that one could not
>>probe from cell to cell using the fire command to discover where
>>hidden enemy units were.
> 
> Letting the failed task consume acps might work in this specific case, 

I don't think that tasks should consume ACP or anything else. They are 
too high level. We should restrict consumption to actions (as I beleive 
the case is now).

>but
> it would go against how Xconq works in all other situations. For example,
> if you click where your unit cannot move, you don't spend any acps. 

In the case of movement this makes sense. But, consider that a melee 
attack actually does imply movement (as we agreed upon in an earlier 
thread), and thus, even if the attack is unsuccessful, the unit should 
be penalized for the implied movement (preferably through the normal 
attack costs).

Eric

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

[Eric McDonald]

Hans Ronne wrote:

> To follow up, this problem already exists with the current code. If I
> switch off the AI and try to hit the same bogus unit view with a manual 'f'
> command I get the anser "No visible unit there" (and no acp is consumed).
> So probing the terrain for free is already possible, precisely because
> do_hit_unit_task tries to do a fire_at_action (or an attack_action) instead
> of a fire_into_action (or an overrun_action). Only the latter are really
> safe to use in a unit view context.

Unless this has been changed, the patch I made to the Tcl/Tk interface 
on 2003/12/29 addresses this. (This is what I was referring to earlier; 
I guess it was a comment in which I suggested the "attempted fire at" 
function, and not necessarily an email message.) If you look at the 
comments I put in the code, you can see that I was already thinking of 
ways to address the present problem back then.

2003-12-29  Eric McDonald

         Squash two firing bugs in Tcl/Tk interface with one fix.
         * tkcmd.c (common_fire_at): Get rid of call to unit_at, which
         would return the first unit, friend or foe. Instead iterate
         through view stack and pick out the first unit not on
         attacker's side, if there is any such unit. This accomplishes
         two things. First, this prevents a player from cheating by
         probing all cells in firing range, hoping to uncover an unseen
         enemy unit (the code would report "Nothing to fire at!" from
         unit_at()'s omniscient perspective rather than a non-see-all
         side's less knowledgable one). Second, this allows a player
         to fire into a cell which contains his or her own units. This
         is a mixed blessing, since friendly fire incidents can occur
         because of the way the firing code is currently set up.

RCS file: /cvs/xconq/xconq/tcltk/tkcmd.c,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- xconq/tcltk/tkcmd.c	2003/12/25 19:22:31	1.59
+++ xconq/tcltk/tkcmd.c	2003/12/29 23:57:36	1.60
@@ -624,16 +624,50 @@
  common_fire_at(Unit *unit, int x, int y)
  {
      int rslt;
-    Unit *other;
-
-    /* (should only be able to target unit if covered...) */
-    other = unit_at(x, y);
+    Unit *other = NULL;
+    UnitView *uview = NULL;
+    int methere = FALSE, minethere = FALSE;
+
+    /* Check only those units which we can see. */
+    for_all_view_stack(unit->side, x, y, uview) {
+        /* And which are not on our side. Note that we are allowed to
+           hit other trusted sides, though doing so may make them not
+           trusted for long. :-) */
+        if (unit->side != side_n(uview->siden)) {
+            other = uview->unit;
+            /* Assume we have the right target. (Bad assumption,
+               but what else can one do with the info presently 
available?) */
+            break;
+        }
+        /* If one of our units is in the cell, we make note of this, in
+           case there turns out to be no visible enemies there. */
+        else {
+            if (uview->unit == unit)
+              methere = TRUE;
+            else
+              minethere = TRUE;
+        }
+    }
+    /* Target may be a ghost (view of dead or moved unit), but the player
+       cannot know that, and hence we should proceed with a fire-into
+       action instead. */
+    /* (This code should not be in the interface. Instead the referee
+        code in the kernel should accept UnitView * instead of
+        Unit *, and perform these checks for us, and guide the
+        fire-into action to be safer in such cases. Or perhaps just run
+        an attempted_fire_at procedure, which would expend ammo, draw the
+        fire lines, and do not much else.) */
+    if (other && (!in_play(other) || (other->x != x) || (other->y != y))) {
+        common_fire_into(unit, x, y);
+        return;
+    }
      if (other == NULL) {
-	cmd_error(dside, "Nothing there to fire at!");
-    } else if (other == unit) {
-	cmd_error(dside, "You can't fire at yourself!");
-    } else if (other->side == unit->side) {
-	cmd_error(dside, "You can't fire at one of your own units!");
+        if (methere)
+          cmd_error(dside, "You can't fire at yourself!");
+        else if (minethere)
+          cmd_error(dside, "You can't fire at one of your own units!");
+        else
+	  cmd_error(dside, "Apparently nothing there to fire at!");
      } else {
  	rslt = check_fire_at_action(unit, unit, other, -1);
  	if (valid(rslt)) {


Eric

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

[Hans Ronne]

>>>If the action check failed because the unit view doesn't not
>>>correspond to an actual unit at the given position, then the task
>>>logic should make a callback to the AI or UI to remove the unit
>>>view, IMO. This would break the cycle.
>>
>>
>> Yes, I thought about that. However, since failed tasks do not consume acps,
>> this would provide a cost-free way to probe the terrain for real vs. bogus
>> enemy units.
>
>No. Tasks don't consume ACP or anything else. Actions do. And, I don't
>see a problem if a failed action consumes ACP or materials. If an attack
>or a fire misses an actual unit, ACP is consumed in spite of the fact
>that it was a miss. How is attacking a ghost unit any different than a miss?

Because we are dealing with a failed task here, not a failed action. We
never get to the point where we attack the ghost unit. That is the core of
the problem. If we did attack the ghost unit, we would certainly consume
acps, even if we failed. But the only way to get that far is to use
fire_into_action so that the action is not aborted before it happens (or
even before it can be scheduled to happen, as in this specific case).

>I don't think that tasks should consume ACP or anything else. They are
>too high level. We should restrict consumption to actions (as I beleive
>the case is now).

OK, then we agree on that point. That does, however, rule out the acp
penalizing scheme as a possible solution.

>>but
>> it would go against how Xconq works in all other situations. For example,
>> if you click where your unit cannot move, you don't spend any acps.
>
>In the case of movement this makes sense. But, consider that a melee
>attack actually does imply movement (as we agreed upon in an earlier
>thread), and thus, even if the attack is unsuccessful, the unit should
>be penalized for the implied movement (preferably through the normal
>attack costs).

If a unit does carry out an attack which is unsuccessful, yes. But if it
only gets as far as contemplating an attack (task execution) which never
happens, I don't think it should be penalized. Thinking about doing
something is not the same thing as doing it.

Hans

P.S. I think the real problem here is that real units instead of unit views
are being checked at a point (task execution), where only unit views should
be checked, since that is all the AI or the human player should ever know
about. References to real units should be strictly limited to the action
code where things do happen. Anything before that is AI code (or interface
code), and should be treated accordingly.

By firing into or attacking cells instead of units, we can avoid the need
to mess with real units already at the task execution stage. That's the
gist of my argument.

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

[Eric McDonald]

Hans Ronne wrote:

> I have given the above bug and its consequences some serious thought. Here
> is what I think should be done:
> 
> 1. We should eliminate the attack unit/attack position code split. Instead
> of the four actions that are possible today, we should just have two:
> do_attack_action and do_fire_action. These actions should be
> unit-independent, i.e. work pretty much like the old do_overrun_action and
> do_fire_into_action.
> 
> This would have a number of advantages. First, we could do away with unit
> pointers in the combat code. 

I agree with doing away with the unit pointers, and I mention this in my 
Dec 29 fix from last year.

> For example, clicking on an enemy unit could schedule a normal
> attack (overrun action) and right-clicking on it a fire action. 

We would then lose the ability to do selective attacks into a cell.

Also, I am still quite apprehensive about using right-clicks for firing 
(as we have discussed previously).

> Yet another advantage with this scheme is that it
> would make combat model 0 more similar to combat model 1, which only uses
> overrun actions. 

I don't particularly see this as advantage, since one would then get 
much more combat than one necessarily bargained for or even desired.

> 2.
> Specifically, I don't like the fact that you get a free shot at every unit
> in the cell for just one acp consumed, even if you have to pay for it in
> ammo. 

I agree. More combat should imply more ACP expended (though possibly at 
a discounted rate; "buy one attack, get the next one at half price" to 
apply mercantile jargon to the situation).

>It seems more logical that one attack (either normal or round of
> fire) is just that, and that you consume 1 acp and 1 round of ammo each
> time you attack. As a consequence, you should also be able to hit only one
> unit (and possibly its occupants) each time you attack.

Right, unless the attack or fire does spread (surface) damage.

> 3. The question is then how to pick the unit to hit. I can see three
> possibilities. 

>The first is to hit units in stack order. This is easy to
> implement and is therefore how things frequently work in the kernel, but I
> don't think it is a good idea in this case. 

This would be reasonable if one could assume that the game designer set 
up the stack order with defensive ranking on mind. If we did this, I 
would then set up Halberdiers (acting as pikemen) to be before 
Longbowmen in the stack in Wreckreation.

>The second possibility is to
> pick a unit at random, perhaps weighted according to unit-size-in-terrain.

I like this idea very much in the case of fire. I am not sure that it 
makes much sense in terms of melee combat though.

> The third possibility is to always pick the best defender, on the theory
> that this is the unit that the defending side would send forward to meet
> the enemy.

This could turn out to be a complicated calculation, and, in the end, we 
would probably end up with someone asking for it to me made into an AI 
"hints" table, as has happened with some of the other aspects of AI 
behavior recently. And, as with the second possibility, I am not sure 
how relevant this is for firing.

> The main difference between them would
> remain the fact that a model 1 attack continues until death, while a model
> 0 attack continues only as long as the attacker wishes to continue and has
> acps left.

Right. And, if I get around to implementing the modular combat system 
after the 7.5 release, then this multi-round combat behvaior will just 
be controlled by a GDL switch. Setting 'combat-model' to 1 will flip 
this switch on, but it will also be able to switched on independently. 
Of course, a variation on mutli-round combat (involving more than 2 
units) alos might be considered (see the "battle" and "commit level" 
concepts in 'doc/PROJECTS').

> 4. However, I doubt that this is a good solution for fire actions, which by
> their very nature are more random. In that case, I'm leaning towards a
> size-weighted random target, as described above. 

I would agree with the "size-weighted" part, but not necessarily the 
"random" part. If the fire damage does point damage, and the target is a 
ghost unit, then the fire should miss. (I suppose a random chance could 
be added that another unit just happened to be in the ghost unit's 
position and thus got clobbered.) However, if the fire does spread 
damage, then I think all units in the cell (or spread damage radius, or 
spread damage max victim count) should be affected.

> These are my thoughts so far. The proposed changes would have profound
> consequences for all games in the library, so they require some careful
> thought. 

Indeed!

Eric

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

[Hans Ronne]

>Hans Ronne wrote:
>
>> To follow up, this problem already exists with the current code. If I
>> switch off the AI and try to hit the same bogus unit view with a manual 'f'
>> command I get the anser "No visible unit there" (and no acp is consumed).
>> So probing the terrain for free is already possible, precisely because
>> do_hit_unit_task tries to do a fire_at_action (or an attack_action) instead
>> of a fire_into_action (or an overrun_action). Only the latter are really
>> safe to use in a unit view context.
>
>Unless this has been changed, the patch I made to the Tcl/Tk interface
>on 2003/12/29 addresses this.

No, your patch addressed a different problem: the fire-into-empty cells
cheat. What I am talking about is attempting to fire at unit views in order
to find out if the unit is still sitting there or if it is a ghost view.
And this exploit is still possible, both in the tcltk interface and in the
mac interface. In effect, what it means is that you can attempt to fire at
unit views for free until you target a real unit, in which case the fire
action will execute and you will be charged.

It is not as bad as the fire-into-empty-cells cheat, but certainly not
something that should be permitted without any cost in acps or materials.
Only real actions, whether they fail or not, should provide information
about the enemy side and its units.

Hans

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

[Eric McDonald]

Hans Ronne wrote:

>> How is attacking a ghost unit any different than a miss?
> 
> Because we are dealing with a failed task here, not a failed action. We
> never get to the point where we attack the ghost unit. 

I disagree. There is (or should be) an attempted attack carried out on 
the ghost unit. As near as I can tell, an attempted attack could be 
framed in terms of an action (which may, in turn, invoke other actions).

> OK, then we agree on that point. That does, however, rule out the acp
> penalizing scheme as a possible solution.

Only if you insist on thinking inside the box and are unwilling to 
develop additional machinery. I am suggesting an "attempted attack" 
action or something akin to an action.


> If a unit does carry out an attack which is unsuccessful, yes. But if it
> only gets as far as contemplating an attack (task execution) which never
> happens, 

It is not a matter of "contemplating"; it is a matter of "attempting". 
As I see it, anyway.

>I don't think it should be penalized. Thinking about doing
> something is not the same thing as doing it.

Exactly.

> P.S. I think the real problem here is that real units instead of unit views
> are being checked at a point (task execution), where only unit views should
> be checked, since that is all the AI or the human player should ever know
> about. 

I agree about 90%.

>References to real units should be strictly limited to the action
> code where things do happen. Anything before that is AI code (or interface
> code), and should be treated accordingly.

I agree 100%.

Eric

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

[Eric McDonald]

Hans Ronne wrote:

> No, your patch addressed a different problem: the fire-into-empty cells
> cheat. 

OK. Then I misunderstood your complaint.

>What I am talking about is attempting to fire at unit views in order
> to find out if the unit is still sitting there or if it is a ghost view.
> And this exploit is still possible, both in the tcltk interface and in the
> mac interface. In effect, what it means is that you can attempt to fire at
> unit views for free until you target a real unit, in which case the fire
> action will execute and you will be charged.

Right. And I saw that that was a problem, and wrote a comment (in the 
aforementioned patch) that suggested "attempted fire" as a way to deal 
with the problem you describe.

> It is not as bad as the fire-into-empty-cells cheat, but certainly not
> something that should be permitted without any cost in acps or materials.

Agreed.

> Only real actions, whether they fail or not, should provide information
> about the enemy side and its units.

Agreed.

Eric

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

[Hans Ronne]

>> For example, clicking on an enemy unit could schedule a normal
>> attack (overrun action) and right-clicking on it a fire action.
>
>We would then lose the ability to do selective attacks into a cell.

If you mean the ability to pick what unit to attack first within a single
cell, true. That is the price we have to pay. I've given it some thought,
but I don't think it is a big problem in any existing game. Units that you
really would like to hit with a high priority, like cities, frequently
occupy an entire cell. And you could always argue that it should be the
defending side's privilege to decide what unit to send forward when a cell
is attacked. In effect, this kind of scheme might partially compensate for
the AIs rather poor ability to defend key units.

>Also, I am still quite apprehensive about using right-clicks for firing
>(as we have discussed previously).

Yes, there are also platform-specific issues as we already discussed (e.g.
right-clicking is used to bring up the unit closeup on the Mac). But it is
still easier to find good interface solutions for two actions instead of
four, which was my point.

>> Yet another advantage with this scheme is that it
>> would make combat model 0 more similar to combat model 1, which only uses
>> overrun actions.
>
>I don't particularly see this as advantage, since one would then get
>much more combat than one necessarily bargained for or even desired.

I'm not arguing that the multiple rounds of attack in combat model 1 should
apply in model 0. On the contrary, this is the main difference between the
models, which should be preserved. My point was rather that if both models
use overrun actions only, it is easier to write AI code that can handle
both of them well.

>> 3. The question is then how to pick the unit to hit. I can see three
>> possibilities.
>
>>The first is to hit units in stack order. This is easy to
>> implement and is therefore how things frequently work in the kernel, but
>>>>I don't think it is a good idea in this case.
>
>This would be reasonable if one could assume that the game designer set
>up the stack order with defensive ranking on mind. If we did this, I
>would then set up Halberdiers (acting as pikemen) to be before
>Longbowmen in the stack in Wreckreation.

I agree. Only the Roman and Russian Revolution games use stack order now,
however. And it is not yet supported by the unit view code (this is on my
todo list, but not a high priority).

>>The second possibility is to
>> pick a unit at random, perhaps weighted according to unit-size-in-terrain.
>
>I like this idea very much in the case of fire. I am not sure that it
>makes much sense in terms of melee combat though.

No, I agree with that.

>> The third possibility is to always pick the best defender, on the theory
>> that this is the unit that the defending side would send forward to meet
>> the enemy.
>
>This could turn out to be a complicated calculation

Well complicated or not, the code is already there. See model_1_attack. The
question is rather how to improve it. But even a simple solution such as
picking the unit with the highest defense value is far better (from the
defender's point of view) than a random pick. And in fact we have an
advantage in that the type of attacking unit is known at this point, which
makes any calculation much simpler.

>> 4. However, I doubt that this is a good solution for fire actions, which by
>> their very nature are more random. In that case, I'm leaning towards a
>> size-weighted random target, as described above.
>
>I would agree with the "size-weighted" part, but not necessarily the
>"random" part. If the fire damage does point damage, and the target is a
>ghost unit, then the fire should miss. (I suppose a random chance could
>be added that another unit just happened to be in the ghost unit's
>position and thus got clobbered.) However, if the fire does spread
>damage, then I think all units in the cell (or spread damage radius, or
>spread damage max victim count) should be affected.

I think spread damage could be easily implemented, perhaps as some kind of
detonation-on-hit action. My main point was that we should avoid solutions
that makes the hit-chance against one unit dependent on the presence or
absence of other units in the same cell. Unless, of course, these other
units provide cellwide-protection-for or some other property that modifies
the hit chances.

Hans

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

[Eric McDonald]

Hans Ronne wrote:


>>We would then lose the ability to do selective attacks into a cell. 
> 
> If you mean the ability to pick what unit to attack first within a single
> cell, true. That is the price we have to pay. 

And it is a very hefty price for games in which players might rely on 
guerilla tactics against specific types of units, commando strikes 
against specific targets, etc....

What I also meant is that it sounded to me that you were suggesting the 
use of overrun, which would imply engaging _all_ units (or, as many as 
the attacker had ammo and ACP for) in the cell, would it not?

>I've given it some thought,
> but I don't think it is a big problem in any existing game. Units that you
> really would like to hit with a high priority, like cities, frequently
> occupy an entire cell. 

True, but this is not always the case. With what you are proposing, I 
could always escort tankers with destroyers, and ruin a sub's day 
because it would be unable to target the tanker. Not good.

>And you could always argue that it should be the
> defending side's privilege to decide what unit to send forward when a cell
> is attacked. 

In some cases. In other cases, as alluded to above, it most definitely 
is not (when an unit is being individually attacked).

>In effect, this kind of scheme might partially compensate for
> the AIs rather poor ability to defend key units.

Perhaps. But at what price?

> But it is
> still easier to find good interface solutions for two actions instead of
> four, which was my point.

This is true. But, I wouldn't consider it a selling point for what you 
propose.

> I'm not arguing that the multiple rounds of attack in combat model 1 should
> apply in model 0.

I know, but you were arguing that an overrun rather than an individual 
attack should always be used. That is what I am taking issue with.

>>>The third possibility is to always pick the best defender, on the theory
>>>that this is the unit that the defending side would send forward to meet
>>>the enemy.
>>
>>This could turn out to be a complicated calculation
> 
> Well complicated or not, the code is already there. See model_1_attack. 
>The
> question is rather how to improve it. But even a simple solution such as
> picking the unit with the highest defense value is far better (from the
> defender's point of view) than a random pick. And in fact we have an
> advantage in that the type of attacking unit is known at this point, which
> makes any calculation much simpler.

Model 1 uses attack and defense values, but model 0 has much more to 
consider, such as range, hit chance, protection, damage, minimum HP 
against a given unit type, etc....

At this point I would suggest that a 'defense-order' unit property might 
be called for. That way we can let 'stack-order' pertain to unit views 
as was intended. And this also gives the advantage that the game 
designer can rank for himself/herself what units defend first rather 
than trying to fight with a calculation.

And, I think that 'defense-order' should only apply in conjunction with 
units than cannot do selective attacks. I do think, as I have already 
argued, that the ability to do selective attacks should be kept though.

> I think spread damage could be easily implemented, perhaps as some kind of
> detonation-on-hit action. 

I would agree that it should be fairly easy. I have been holding back on 
doing it until I take care of the combat code modularization, but 
depending on how far I get with Wreckreation development, I may be 
tempted to implement it before then.

Eric

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

[Hans Ronne]

>Hans Ronne wrote:
>
>>> How is attacking a ghost unit any different than a miss?
>>
>> Because we are dealing with a failed task here, not a failed action. We
>> never get to the point where we attack the ghost unit.
>
>I disagree. There is (or should be) an attempted attack carried out on
>the ghost unit. As near as I can tell, an attempted attack could be
>framed in terms of an action (which may, in turn, invoke other actions).

I agree that there should be an attempt to attack the ghost unit, which
should be framed in terms of an action. That is my whole point. But this is
not how the code works. What happens is that the attempted attack never
occurs because check_fire_at_action returns false. This, I would emphasize,
happens before prep_fire_at_action is called, so the action is not even
scheduled, much less attempted.

The check_x_action functions are actually used in two completely different
ways. One is in execute_action, where they check if a scheduled but not yet
executed action will fail or not. But they are also used in the planning
and task execution code, to evaluate possible actions that the AI or the
human player is contemplating, but has not yet scheduled for execution. As
I see it, the latter is really an abuse of these functions, particularly if
they reference real units instead of unit views, as in the current case.

Hans

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

[Eric McDonald]

Hans Ronne wrote:

>>I disagree. There is (or should be) an attempted attack carried out on
>>the ghost unit. As near as I can tell, an attempted attack could be
>>framed in terms of an action (which may, in turn, invoke other actions).
> 
> 
> I agree that there should be an attempt to attack the ghost unit, which
> should be framed in terms of an action. That is my whole point. 

That is my point as well.

>But this is
> not how the code works. What happens is that the attempted attack never
> occurs because check_fire_at_action returns false. This, I would emphasize,
> happens before prep_fire_at_action is called, so the action is not even
> scheduled, much less attempted.

Right. And I have recognized this as shortcoming in the code since at 
least Dec 29 of last year.

> The check_x_action functions are actually used in two completely different
> ways. 

Right. I have done enough action and task hacking to have witnessed the 
two different modes of usage many times in the past.

> As
> I see it, the latter is really an abuse of these functions, particularly if
> they reference real units instead of unit views, as in the current case.

Right. And I have certainly argued in past threads that we move away 
from using real units at all in AI and UI code. This reduces the 
temptation to reference them when they should not be referenced. (And 
also helps forge the path towards going client-server with Xconq.)

Eric

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

[Jim Kingdon]

> And this exploit is still possible, both in the tcltk interface and in the
> mac interface. In effect, what it means is that you can attempt to fire at
> unit views for free until you target a real unit, in which case the fire
> action will execute and you will be charged.

The attack into an empty cell exploit still exists with attack ("a").
For example, in the standard game cruise around the ocean, trying to
attack random sea cells.  One will eventually find a submarine.

I haven't generally thought it is a particularly big deal, just
because the AI doesn't know to exploit it and a human player won't
have the patience to exploit it all that often.  But it would be nice
to plug, if doing so doesn't cause other problems.

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

[Jim Kingdon]

> And it is a very hefty price for games in which players might rely on 
> guerilla tactics against specific types of units, commando strikes 
> against specific targets, etc....

Well, yes, I've gotten in the habit of targeting specific units.  For
example, in the standard game, on land I might target infantry and
armor (because they can capture my cities), and ignore aircraft.
At sea, I might target bomber and troop transports (because they can
carry units which can capture my cities), and ignore fighters and
other ships.

As for whether this is a key part of the game, I don't know.

I will say that it is an *obscure* part of the game.  To the beginner,
it isn't clear what the difference between attack and overrun is.  I
certainly played xconq for a while before I discovered attack, with no
obvious grave loss of capability or fun.

So I guess I'm supportive of the proposal, although it is certainly
true that it is a big change, and worthy of careful consideration.

One detail: it should be visually apparent which unit will be attacked
(at least if it is deterministic).  Probably by making stack order
match defense order one way or another.

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

[Hans Ronne]

>What I also meant is that it sounded to me that you were suggesting the
>use of overrun, which would imply engaging _all_ units (or, as many as
>the attacker had ammo and ACP for) in the cell, would it not?

Not at all. This is how the current overrun code works (at least in model
0), but it is one of the things that I propose to change. One attack with 1
acp and 1 round of ammo should hit one enemy unit, not all of them.

>>I've given it some thought,
>> but I don't think it is a big problem in any existing game. Units that you
>> really would like to hit with a high priority, like cities, frequently
>> occupy an entire cell.
>
>True, but this is not always the case. With what you are proposing, I
>could always escort tankers with destroyers, and ruin a sub's day
>because it would be unable to target the tanker. Not good.

Well, to turn the argument around, naval escorts would for the first time
work in Xconq. You would be forced to take on the escort before you could
hit the valuable target. You would also for the first time be able to group
high-offense and high-defense units together, and know that the former
would benefit from the latter's defense. Just as in Civ2, where you would
group chariots together with a fortified phalanx, to give one example. My
feeling is that it would make most games more fun to play. You would
certainly have to give much greater attention to tactical unit deployments
than with the current code.

However, if you want to have a game where subs primarily hit tankers, there
should be ways to achieve that. What would happen if subs only can hit
tankers? Should the presence of units that it cannot hit at all block an
attack? I don't think so. Interestingly, there was a very similar problem
in the first version of Civ2, where putting a bomber on top of a city would
make it immune to ground attack. This was of course fixed in the first
patch.

These are important questions, and how the target selection is done is
clearly the key point. Just picking the unit with the highest defense value
might be too simplistic, I agree with that. Perhaps the hit-chance against
different units should also play a role.

>Model 1 uses attack and defense values, but model 0 has much more to
>consider, such as range, hit chance, protection, damage, minimum HP
>against a given unit type, etc....

This is how model 0 attack originally worked. But it now uses computations
(real_attack_value, real_defense_value) that are just as complex as those
in model 0.

>At this point I would suggest that a 'defense-order' unit property might
>be called for. That way we can let 'stack-order' pertain to unit views
>as was intended. And this also gives the advantage that the game
>designer can rank for himself/herself what units defend first rather
>than trying to fight with a calculation.

I agree. However, I suspect that this is what the stack order was supposed
to be used for, though it was never implemented. The stack order has no
practical consequence right now, so we could certainly give it a role in a
reworked combat code. My concern with the unit view code was trying to
maintain a faithful copy of the stack order for unit views. However, I am
not sure if this is necessary or even desirable, which is why I didn't make
it a high priority.

>And, I think that 'defense-order' should only apply in conjunction with
>units than cannot do selective attacks. I do think, as I have already
>argued, that the ability to do selective attacks should be kept though.

I agree that it would be nice, though getting rid of unit pointers in the
AI code would be even nicer. However, I asked myself yesterday: when did I
last use a unit-specific attack in a real game, i.e. walk up adjacent to a
unit, and then put the cursor on top of it, followed by pressing 'a'. It
turned out that I couldn't even remember, which I suspect is fairly typical
for the average Xconq player. I know that I tested this functionality a few
times when i was debugging the Mac interface, but this is about it.
Clicking on a unit is so much easier.

Hans

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

[Hans Ronne]

>> And this exploit is still possible, both in the tcltk interface and in the
>> mac interface. In effect, what it means is that you can attempt to fire at
>> unit views for free until you target a real unit, in which case the fire
>> action will execute and you will be charged.
>
>The attack into an empty cell exploit still exists with attack ("a").
>For example, in the standard game cruise around the ocean, trying to
>attack random sea cells.  One will eventually find a submarine.
>
>I haven't generally thought it is a particularly big deal, just
>because the AI doesn't know to exploit it and a human player won't
>have the patience to exploit it all that often.  But it would be nice
>to plug, if doing so doesn't cause other problems.

Interesting observation. What happens if you just move around in the ocean
without hitting 'a'? Woudn't you expect overrun actions to accomplish the
same thing, i.e. hit any units that are present in the cell, even if hidden
from view? Or are invisible units immune from overruns but not direct
attacks?

It would seem more logical to me if it was the other way around, that is if
direct attacks against invisible units were impossible while overrun
attacks were possible.

Hans

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

[Stan Shebs]

Hans Ronne wrote:

>[...]
>
>The bug that I found works like this. First, the AI finds a target at
>position (x, y) and sets a hit_unit task. However, when do_hit_unit_task
>looks up the actual unit, it finds that the unit no longer exists or has
>moved. The call to check_attack_action (or check_fire_at_action) fails and
>the task itself also fails after 3 attempts (the latter restriction is a
>recent hack by Eric who may have stumbled across the same bug).
>
>
An interesting case. The theory of "attack" and "fire-at" is that
you get to be selective about your victims, which is useful in
particular situations, at least if the game design differentiates
(artillery delivered on top of a tank should be more effective than
firing wildly everywhere in a kilometer-wide cell).

Now if you're directly shooting at the mirage of a tank, then you
are definitely performing the action, even though it's wasted effort,
and at the end of it you may or may not realize it was wasted.  So
the bug is that action checking should have succeeded and then action
execution should have done nothing; and there should be a percentage
chance that the lack of a burning chassis clues in the firing unit
that nobody is there (I thought I added that at some point) and
erases the mirage.

And of course if the view isn't cleared, the AI (or less-intelligent
human player :-) ) could keep shooting over and over at the mirage
aka decoy, which is exactly what the crafty Xconq player wants to
be able to set up, heh-heh.

So I think if you can change the two actions to always take a view
unit instead of an actual unit, you can solve the problem in a
relatively localized way.

On the larger question of the distinction between actions, there
*should* be a huge difference between the types of actions.
Attacking a single unit in a cell should be relatively safe,
while attacking a whole stack of four should be near-suicidal.
The machinery for this is a little lacking; for instance,
bombers and maybe special forces ought to be able to pick and
choose a ground formation to clobber, while grunts have to fight
the whole stack. Similarly, firing on a designated unit (or image
of one) should be much more deadly than into an unseen cell hoping
to hit something, but the random firing may still be a worthwhile
way to harass the enemy.

Setting up good interface for the distinction is more
complicated, which is why it's been neglected I think.

Pruning down the number of actions would certainly simplify
Xconq, and it needs simplification. The most-affected games
would be those at the tactical level, although if the interface
isn't there or is too obscure for players to use much, the
actions' absence won't be noticed.

Stan

>

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

[Hans Ronne]

>And of course if the view isn't cleared, the AI (or less-intelligent
>human player :-) ) could keep shooting over and over at the mirage
>aka decoy, which is exactly what the crafty Xconq player wants to
>be able to set up, heh-heh.

Right. The question of when to clear the view is actually quite tricky.
Should a single failed action do it? I don't think so. But there has got to
be a point where even a stupid AI realizes that it is shooting at a mirage.

Another thing I thought about is to gradually let a unit view fade away as
it ages. The views have a dating mechanism, but it is currently not used
for anything. The corresponding thing for the AI would be to make a unit
view a less attractive target as it ages.

It should be noted that most of these problems will go unnoticed in a melee
game where the enemy units that you target usually are within vision range.
The same thing is true for short range firing units. A game that I am
working on has a unit that can fire from 20 cells away. This creates a huge
shadow zone which highlights the problems.

>So I think if you can change the two actions to always take a view
>unit instead of an actual unit, you can solve the problem in a
>relatively localized way.

Yes. Or we could change the AI code so that it preferentially uses
fire-into instead of fire-at (which might actually make it a better
player). But this would not provide the simplification that I think would
be a huge benfit in the long run, particularly for AI development.

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.
The probability of hitting an unseen unit should not be affected by the
fact that you think you are shooting at something which is not there.
However, this line of thought, when pursued further, also makes you wonder
if we really need both actions.

>Pruning down the number of actions would certainly simplify
>Xconq, and it needs simplification. The most-affected games
>would be those at the tactical level, although if the interface
>isn't there or is too obscure for players to use much, the
>actions' absence won't be noticed.

I agree that tactical level games would be the most affected ones. As I
mentioned in a reply to Eric, I think that tactical unit deployment
(putting a phalanx in the same cell as a chariot to protect it) would
become much more important than it is now. But this should make most games
more interesting.

Hans

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

[Hans Ronne]

>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

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

[Eric McDonald]

On Mon, 16 Aug 2004, Jim Kingdon wrote:

> The attack into an empty cell exploit still exists with attack ("a").
> For example, in the standard game cruise around the ocean, trying to
> attack random sea cells.  One will eventually find a submarine.

Yeah, I only plugged the hole for firing because that was what was 
bothering me at the time. I didn't bother fixing it for attacking 
as well.

> because the AI doesn't know to exploit it and a human player won't
> have the patience to exploit it all that often.  But it would be nice
> to plug, if doing so doesn't cause other problems.

I think it is important to fix because if a human player just had 
a transport full of troops sunk by a sub, and happened to have a 
few destroyers in the area, I can bet that he/she would exploit it 
if he/she knew about it. Vengeance knows no bounds.

Eric

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

[Eric McDonald]

On Tue, 17 Aug 2004, Jim Kingdon wrote:

> I will say that it is an *obscure* part of the game.  To the beginner,
> it isn't clear what the difference between attack and overrun is.  I
> certainly played xconq for a while before I discovered attack, with no
> obvious grave loss of capability or fun.

I agree that it is obscure, but since at least you and I use it to 
good effect, it cannot be considered unuseful or unused. 
Therefore, I would argue, it should be kept as an option in some 
form or another.

Eric

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

[Eric McDonald]

On Tue, 17 Aug 2004, Hans Ronne wrote:

> Not at all. This is how the current overrun code works (at least in model
> 0), but it is one of the things that I propose to change. One attack with 1
> acp and 1 round of ammo should hit one enemy unit, not all of them.

Okay, good. It had sounded to me like you were planning on binding 
'a' to the overrun action since you had planned on doing away with 
attacking individual units. 

> Well, to turn the argument around, naval escorts would for the first time
> work in Xconq. 

They already do: through the use of the protection tables.

>You would be forced to take on the escort before you could
> hit the valuable target. You would also for the first time be able to group
> high-offense and high-defense units together, and know that the former
> would benefit from the latter's defense. 

This only makes sense in some cases such as pikemen supporting 
longbow archers. It does not make sense if a sub slips in and has 
to first torpedo an escort ship before torpedoing a juicy target.

>Just as in Civ2, where you would
> group chariots together with a fortified phalanx, to give one example. My
> feeling is that it would make most games more fun to play. You would
> certainly have to give much greater attention to tactical unit deployments
> than with the current code.

It very well might. But, it is the games that it would degrade 
that I am worried about.

As an aside, I am going to get back to doing some more work with 
formations, hopefully in the next week or two. One of the things I 
hope to implement is AI support for using formations (possibly 
through some sort of unit-unit gravity table (as was suggested by 
Henry Cobb, I think)). Setting desired formation distance to 0 (in 
the same cell) in an unit-unit formation distance table would make 
your suggested change more relevant from the AI prespective.

(I am also seriously considering changing the way setting 
formations works in the Tcl/Tk interface. Selecting an unit, 
hitting "F", and then selecting its leader is tedious. I think it 
would be better to select the leader, hit "F", and the select all 
of its followers using a modal that it is terminated by escape 
(cancel) or enter (accept list of followers). This would be much 
more efficient and less tedious, I think.)

> However, if you want to have a game where subs primarily hit tankers, there
> should be ways to achieve that. What would happen if subs only can hit
> tankers? Should the presence of units that it cannot hit at all block an
> attack? I don't think so. 

If the sub has even a small chance to hit a destroyer, it should 
not be forced to engage the destroyer first before the tanker.

> These are important questions, and how the target selection is done is
> clearly the key point. 

Yes, I definitely think so. It seems we agree about the need use 
unit views with whatever form the rennovated actions take.

> might be too simplistic, I agree with that. Perhaps the hit-chance against
> different units should also play a role.

And it quickly blossoms out from there. Do you pick a unit with a 
low hit chance against but that can only survive one blow, or do 
you pick one with a higher hit chance against but that it quite 
tough. These are all things I wrestled with in the victim finder, 
and I am now inclined to avoid such calculations when possible.

> >At this point I would suggest that a 'defense-order' unit property might
> >be called for. That way we can let 'stack-order' pertain to unit views
> >as was intended. And this also gives the advantage that the game
> >designer can rank for himself/herself what units defend first rather
> >than trying to fight with a calculation.
> 
> I agree. However, I suspect that this is what the stack order was supposed
> to be used for, though it was never implemented. The stack order has no
> practical consequence right now, so we could certainly give it a role in a
> reworked combat code. 

I will concede that. Both you and Jim have argued convincingly 
that stack order should coincide with defense order (in games 
where this ought to apply, at least).

> I agree that it would be nice, though getting rid of unit pointers in the
> AI code would be even nicer. 

I don't see those as diametrically opposing goals. Why should we 
need to get rid of selective attacks just because we are getting 
rid of unit pointers?

> last use a unit-specific attack in a real game, i.e. walk up adjacent to a
> unit, and then put the cursor on top of it, followed by pressing 'a'. It
> turned out that I couldn't even remember, which I suspect is fairly typical
> for the average Xconq player. I know that I tested this functionality a few
> times when i was debugging the Mac interface, but this is about it.
> Clicking on a unit is so much easier.

When all targets are equally desirable perhaps. But, both Jim and 
I actually do selectively hit targets using "a" and "f" in cases 
where we are, in fact, trying to single certain ones out to our 
tactical advantage. Without this ability, we are losing tactics in 
a big way and Xconq should essentially be regarded as strategy 
game engine, tactical games need not apply.

(I do think that the roles of "f" and "CTRL-f" could be swapped 
though, if some of us are willing to retrain our fingers....)

Eric

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

[Eric McDonald]

On Tue, 17 Aug 2004, Hans Ronne wrote:

> >The attack into an empty cell exploit still exists with attack ("a").
> >For example, in the standard game cruise around the ocean, trying to
> >attack random sea cells.  One will eventually find a submarine.
> 
> Interesting observation. What happens if you just move around in the ocean
> without hitting 'a'?

Then you are using 'advance_into_cell' as opposed to directly 
using the attack logic. I think Jim was referring to using the 
attack command to probe adjacent hexes without advancing into 
them. I fixed this for firing but not for attacking in the Tcl/Tk 
interface.

Eric

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

[Eric McDonald]

On Tue, 17 Aug 2004, Hans Ronne wrote:

> >And of course if the view isn't cleared, the AI (or less-intelligent
> >human player :-) ) could keep shooting over and over at the mirage
> >aka decoy, which is exactly what the crafty Xconq player wants to
> >be able to set up, heh-heh.
> 
> Right. The question of when to clear the view is actually quite tricky.
> Should a single failed action do it? I don't think so. But there has got to
> be a point where even a stupid AI realizes that it is shooting at a mirage.

In the case of firing, I think that a percent chance of the 
mistake being discovered was suggested. The percentage would take 
care of this problem as it would remove the unit view.

> Another thing I thought about is to gradually let a unit view fade away as
> it ages. The views have a dating mechanism, but it is currently not used
> for anything. The corresponding thing for the AI would be to make a unit
> view a less attractive target as it ages.

I like this idea.

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

Unless the code in the Dec 29 patch is failing, this is what the 
Tcl/Tk interface should be doing. However, I do not feel that this 
is the correct answer; the only reason I implemented it that 
way was because the attempted fire mechanism didn't exist.

> The probability of hitting an unseen unit should not be affected by the
> fact that you think you are shooting at something which is not there.

Why? Surely if you were firing at an individual unit, then the 
chance of another just happening to be in its place coupled with 
the chance of hitting the substitute unit should be smaller than 
the hit chance of directly aiming at the substitute unit.

> I agree that tactical level games would be the most affected ones. As I
> mentioned in a reply to Eric, I think that tactical unit deployment
> (putting a phalanx in the same cell as a chariot to protect it) would
> become much more important than it is now. But this should make most games
> more interesting.

And would ruin an important aspect of others.

Eric

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

[Hans Ronne]

>> The probability of hitting an unseen unit should not be affected by the
>> fact that you think you are shooting at something which is not there.
>
>Why? Surely if you were firing at an individual unit, then the
>chance of another just happening to be in its place coupled with
>the chance of hitting the substitute unit should be smaller than
>the hit chance of directly aiming at the substitute unit.

Not at all. I am talking about a fire-into substitute action here, not a
fire-at action against the unseen unit (which would be impossible by
definition). So the hit chance should really be the same regardless of
where the unit is located in the cell.

Hans

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

[Eric McDonald]

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 

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

[Eric McDonald]

On Tue, 17 Aug 2004, Hans Ronne wrote:

> >Why? Surely if you were firing at an individual unit, then the
> >chance of another just happening to be in its place coupled with
> >the chance of hitting the substitute unit should be smaller than
> >the hit chance of directly aiming at the substitute unit.
> 
> Not at all. I am talking about a fire-into substitute action here, 

When we talk about 'fire-into' as it presently stands, it is 
really 'fire-at-any'. 

>not a
> fire-at action against the unseen unit (which would be impossible by
> definition). So the hit chance should really be the same regardless of
> where the unit is located in the cell.

Only if the other units are seen and we are treating 'fire-into' 
as chosing a random target from among the unit views. In the case 
where the other units are not seen, then this makes no sense. 
Unseen units should be very difficult to hit (unless they have a 
very large target cross-section relative to the size of the cell).

Eric

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

[Hans Ronne]

>> >Why? Surely if you were firing at an individual unit, then the
>> >chance of another just happening to be in its place coupled with
>> >the chance of hitting the substitute unit should be smaller than
>> >the hit chance of directly aiming at the substitute unit.
>>
>> Not at all. I am talking about a fire-into substitute action here,
>
>When we talk about 'fire-into' as it presently stands, it is
>really 'fire-at-any'.
>
>>not a
>> fire-at action against the unseen unit (which would be impossible by
>> definition). So the hit chance should really be the same regardless of
>> where the unit is located in the cell.
>
>Only if the other units are seen and we are treating 'fire-into'
>as chosing a random target from among the unit views. In the case
>where the other units are not seen, then this makes no sense.
>Unseen units should be very difficult to hit (unless they have a
>very large target cross-section relative to the size of the cell).

Exactly. But this small chance would still be the same regardless of where
the unseen unit is in the cell. You seemed to argue above that we would be
"directly aiming at the subsitute unit", but this is not possible if it is
invisible.

Hans

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

[Hans Ronne]

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

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

[Eric McDonald]

On Tue, 17 Aug 2004, Hans Ronne wrote:

> >> >Why? Surely if you were firing at an individual unit, then the
> >> >chance of another just happening to be in its place coupled with
> >> >the chance of hitting the substitute unit should be smaller than
> >> >the hit chance of directly aiming at the substitute unit.
> >>
> >>not a
> >> fire-at action against the unseen unit (which would be impossible by
> >> definition). So the hit chance should really be the same regardless of
> >> where the unit is located in the cell.
> >
> >Only if the other units are seen and we are treating 'fire-into'
> >as chosing a random target from among the unit views. In the case
> >where the other units are not seen, then this makes no sense.
> >Unseen units should be very difficult to hit (unless they have a
> >very large target cross-section relative to the size of the cell).
> 
>But this small chance would still be the same regardless of where
> the unseen unit is in the cell. 

Well, no kidding. I am not sure how the position of an unseen unit 
in a cell found its way into the this discussion. The only time 
the "position" of an unseen unit in a cell matters is if we roll 
the dice and the unseen unit is determined to be in the position 
where the ghost unit was at, in the event of a 'fire-at' at the 
ghost unit. In the case of a 'fire-into' (here meaning a random 
barrage into a cell), the position of the unseen unit is totally 
irrelevant.

>You seemed to argue above that we would be
> "directly aiming at the subsitute unit", but this is not possible if it is
> invisible.

Maybe the choice of wording made the meaning unclear. What I was 
saying that, if you see unit X and aim directly at it, then the 
chance of hitting it is determined by 'hit-chance' or 
'fire-hit-chance'. If you think you see unit Y, aim directly at 
it, but unit Y turns out to be a ghost and unit X happens to be 
in the same cell, then the chance of unit X being considered to be 
in the position of unit Y is really quite small in most cases, and 
thus unit X should not be hit with the same chance from the 
barrage intended for unit Y. Clearer or muddier?

Eric

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

[Eric McDonald]

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

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

[Hans Ronne]

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

I don't consider the ability to attempt bogus actions a functionality but a
bug, and I think we both agree on that. What I am suggesting is a solution
that will fix these problems forever. Just like putting wrapx on the
accessor macros fixed all the wrapping bugs.

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

I am not suggesting that. I am suggesting that a fire-at action without a
valid target should be converted into (default into) a fire-into action.
See point 3 on my agenda.

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

As I stated previously (point 4 in my agenda), I would like to change how
fire-into works. I don't like the current situation where you get a free
shot at all units in the stack for just one acp. What I would like to have
is an action where you fire at the cell, one unit is picked as the target,
and you either hit or miss that unit. The logic behind this would be that
the shell has to land somewhere in the cell, and only one unit can sit
where it lands. So yes, it would certainly be possible to do a fire-into
action and not hit a single unit.

I don't think that this a necessary preconditon for fixing the other bugs,
though. I favour a step-by-step procedure.

Hans

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

[Eric McDonald]

Hans Ronne wrote:

>>Properly dealing with bogus actions does not (or should not)
>>entail removing two actions.
> 
> I am not suggesting that. 

Okay, good.

> I don't like the current situation where you get a free
> shot at all units in the stack for just one acp. 

Nor do I.

>What I would like to have
> is an action where you fire at the cell, one unit is picked as the target,
> and you either hit or miss that unit. The logic behind this would be that
> the shell has to land somewhere in the cell, and only one unit can sit
> where it lands. 

But, this is where we differ, I think. The shell has to land somewhere, 
and it is possible that _no_ unit sits where it lands.

>So yes, it would certainly be possible to do a fire-into
> action and not hit a single unit.

The probability of missing an unit is not the same as the probability of 
landing where an unit is not. (And it is for this reason why I argued 
that missing a ghost unit should not imply a normal chance to hit 
another unit.)

> I don't think that this a necessary preconditon for fixing the other bugs,
> though. I favour a step-by-step procedure.

Sure. I am not trying to delay you from fixing the other bugs. I hope 
this was not your impression. My only concern right now is getting the 
most sensible thing done regarding 'fire-at' at ghost units and the 
general handling of 'fire-into'.

Let me clarify and expand upon what I think should happen wrt 'fire-into':

(1) When a 'fire-into' is executed, it should first tally up the total 
percent of the cell that is covered by unit target area. Unit target 
area should ideally be determined by a new TableUT and TableUU. Unit 
sizes in terrain are for cell capacity limits which are not the same as 
target areas. For example, a cell could only hold 16 units of a given 
type, but their total target area might only be 32% (2% per unit).
(2) After the total unit target area is calculated, a call to 
'probability' should be made if it is less than 100%. If 'probability' 
returns false, then the barrage missed all units. (For the future: 
Damage should only be calculated if spread damage is indicated rather 
than point damage.)
(3) If 'probability' returns true or total target area >= 100%, then one 
of the units in the stack should be selected with larger ones 
(presumably larger target areas) given preference. The usual hit-or-miss 
logic should be applied to that unit. If that unit is missed, then no 
damage occurs to any unit in the cell (with the possible exception of 
spread damage). If that unit is hit, then it is damaged per normal rules.

Now, I think that what you are arguing for is what I termed as 
'fire-at-any' earlier. 'fire-at-any' assumes a 100% probability of 
hitting the stack, and then essentially proceeds with step (3) as 
outlined above.

I hope this clears up what I am getting at.

Eric

P.S. The default for unit target area might be somewhat tricky to 
handle. Probably it would have to be -1, with the understanding that 
Xconq would recalculate it during game initialization, perhaps by taking 
a proprotion using 'unit-size-in-terrain' and terrain capacity for the 
new TableUT, and using 'unit-size-as-occupant' and unit capacity for the 
new TableUU.

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

[Hans Ronne]

>But, this is where we differ, I think. The shell has to land somewhere,
>and it is possible that _no_ unit sits where it lands.

Of course. And it is also possible that the target unit is entrenched,
protected by other units or the terrain, or takes evasive action. One could
also argue, as you do, that larger units are easier to hit etc.

I do understand the "Unit target area" scheme that you are proposing, or at
least I think so. You would calculate how much of the total area is
covered, and then use that to distribute hit-chances between the units and
the empty area. However, I think this may be both too simplistic and too
complicated. Too simplistic because many factors affect the hit chance
(some are mentioned above) and the unit size in terrain is just one of
them, not necessarily the most important one. Too complicated for reasons
that have to do with the underlying statistics. Perhaps I should elaborate
on the latter, because it is an important point to clear up.

I see random firing of a gun into a terrain area as a statistical process
in two space dimesions (we need not consider time here). The key aspect of
this process is that the position of each hit is independent of both
previous and coming hits. This means that a given unit (or subarea) has a
fixed probability of being hit with each shot. This probability may depend
on the unit's size, its protection, the terrain and many other factors. The
probability may be anything from 0% to 100%.

Now, as I see it, all these factors (including the unit's size) are already
weighed into the hit-chance table and its various modifier tables such as
uu_protection etc. I certainly assign a larger hit chance against units
that are big targets when I design a game. So if the hit-chance for
artillery against infantry is 20% it means that an infantry unit which sits
in a standard terrain cell (no terrain modifiers) has a 20% chance of being
hit each time a piece of artillery fires into that cell.

This probability, and this is the key point in my argument, is not affected
by the presence of other units in the cell (or - in the case of failed
fire-at actions - their absence). Nor is it affected by the sizes of these
other units or the total area covered by all units. The only size that
matters is the size of our own unit, which is already weighed into the
hit-chance table. We can therefore forget about these other units, which
are statistically independent of our unit, in the hit-chance calculation.
The only exception is if one of them has a protection property that affects
our unit.

So, to answer your question, if we have 5 units in the cell, and the
artillery has a 1% hit-chance against each one of them, the probability
that no unit at all will be hit is (1 - 0.01) ^ 5, or 95.1%. If we have 2
units in the cell and the hit-chance against each one is 98% the
probability that no unit will be hit is (1 - 0.98) ^ 2, or 0.04%. A small
but still non-zero number. I would expect the combined hit-chance to equal
100% only if the hit-chance against at least one of the units is 100%, in
which case it will always be 100%.

So how do we translate this into a combat resolution algorithm that makes
sense? I would favour a Monte Carlo approach, where the dice is rolled once
for each unit in the stack, using its own individual hit-chance. This dice
rolling should stop, however, once a unit has been hit. The reason for this
is that if we know that the shell hit one position, it cannot also hit a
completely different postion. Sort of like the collapse of the wave
function in quantum mechanics, if you see what I mean.

Furthermore, it is important that the dice rolling is done in a random
order, since we would otherwise favour hits of units at the top of the
stack, particularly when each unit has a high hit-chance.

I hope this clarified my views.

Hans

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

[Jim Kingdon]

> What happens if you just move around in the ocean without hitting
> 'a'?

If there is no submarine, then you expend an ACP.

Whereas hitting "a" where there is no submarine doesn't cost you
anything.

> It would seem more logical to me if it was the other way around,
> that is if direct attacks against invisible units were impossible
> while overrun attacks were possible.

So "a" would only attack units you can see, but overruns would
possibly attack units you can't see?  That sounds logical.

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

[Jim Kingdon]

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

Makes sense.  In fact I was somewhat confused by all the discussion of
percentages and so on, until I realized that people were talking about
firing, not necessarily attacking.

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

[Jim Kingdon]

> However, I asked myself yesterday: when did I last use a unit-specific
> attack in a real game, i.e. walk up adjacent to a unit, and then put
> the cursor on top of it, followed by pressing 'a'.

I use this attack almost every time that I attack a cell with more
than one unit.

The overrun attack isn't as appealing because: (a) you spread out your
attack among too many units, thus reducing the chance that you'll kill
any (at least in the case where it requires more than one hit to kill
a defender), and (b) all those extra units in the stack get
counterattacks.  I guess Stan might be saying that (b) is a feature,
but since I've found a way around it.....

On the other hand, I don't use fire much (because I mostly play the
standard game, which doesn't have firing).

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

[Hans Ronne]

>> What happens if you just move around in the ocean without hitting
>> 'a'?
>
>If there is no submarine, then you expend an ACP.
>
>Whereas hitting "a" where there is no submarine doesn't cost you
>anything.

Right.

>> It would seem more logical to me if it was the other way around,
>> that is if direct attacks against invisible units were impossible
>> while overrun attacks were possible.
>
>So "a" would only attack units you can see, but overruns would
>possibly attack units you can't see?  That sounds logical.

That's how I expected things to work, since 'a' supposedly targets a
selected and therefore visible unit. Maybe the attack command, too, is
buggy in the tcltk interface.

From what you describe, it sounds like it defaults into an "attack-into"
command when there is no visible unit to attack, and hits any unit that is
present in the cell. This is actually very interesting, since it is similar
to what I propose as a general solution for both the attack and fire-at
commands. The only difference would be that this current buggy (?)
attack-into is not triggered if the cell is empty. Under my scheme, an
attack against an empty cell would always spend both ammo and acps, which
would make all exploits of this type impossible.

Hans

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

[Hans Ronne]

>> 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.
>
>Makes sense.  In fact I was somewhat confused by all the discussion of
>percentages and so on, until I realized that people were talking about
>firing, not necessarily attacking.

I would add that bogus views rarely is a problem in the case of melee
attacks. The reason for this is that almost all units have a vision range
of at least 1, which means that the view of a cell is up-to-date anyway
when you attack it. My bug fix would apply also to attack actions, but that
is just to cover oddball situations like "blind" units and attack ranges
greater than 1 cell.

Hans

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

[Eric McDonald]

On Wed, 18 Aug 2004, Hans Ronne wrote:

> >But, this is where we differ, I think. The shell has to land somewhere,
> >and it is possible that _no_ unit sits where it lands.
> 
> Of course. And it is also possible that the target unit is entrenched,
> protected by other units or the terrain, 

Protection is already handled by other tables, and doesn't factor 
into this argument, I think.

> I do understand the "Unit target area" scheme that you are proposing, or at
> least I think so. You would calculate how much of the total area is
> covered, and then use that to distribute hit-chances between the units and
> the empty area. 

That is essentially correct.

> I see random firing of a gun into a terrain area as a statistical process
> in two space dimesions (we need not consider time here). The key aspect of
> this process is that the position of each hit is independent of both
> previous and coming hits. This means that a given unit (or subarea) has a
> fixed probability of being hit with each shot. This probability may depend
> on the unit's size, its protection, the terrain and many other factors. The
> probability may be anything from 0% to 100%.

What I think you are saying is that the 'hit-chance' or 
'fire-hit-chance' probabilities apply against the entire space of 
the cell and not against the local region that the unit is 
located.

> Furthermore, it is important that the dice rolling is done in a random
> order, since we would otherwise favour hits of units at the top of the
> stack, particularly when each unit has a high hit-chance.

Sure. Of course.

> I hope this clarified my views.

Your argument was well made, and for a couple of minutes almost 
had me believing that apples were oranges. However, apples are 
still not oranges, and here's why:

According to you, if I understand you correctly and I think I 
do, the hit chance applies to the unit as it relates 
to the space of the entire cell and not to the localized region 
("subarea", as you called it) where the unit is located. Now this 
means that if I do a 'fire-into' on a cell that has an unseen unit 
unit of type "u1", then the probability of hitting it is 
determined by its hit chance (and any modifiers to that). So, assuming no 
modifiers on the hit chance, and assuming that type "u1" has a 75% 
chance of being hit by type "u2", type "u2" being the type which 
is firing, then there is 75% that the unseen unit, "u1", will be 
hit.

So far, so good. Now, to throw the wrench. Now suppose that "u1" 
is seen, and "u2" does a 'fire-at' on "u1". Again, the probability 
is 75% that "u1" will be hit.   Ooops, no good.

The problem here is that 'fire-at' assumes that the target is 
being aimed at and applies the hit chance on this assumption. 
Then, you are coming along, and claiming a different 
interpretation of the hit chance when it is being used by 
'fire-into', where aiming is no longer being considered. We must 
be able to differentiate between the two cases.

I see two ways out:
(1) Assume that 'fire-at' has a 100% hit chance and apply any 
modifiers to that chance. This is, however, inconsistent with the 
way attack works, and makes little sense, IMO.
(2) Use the method I proposed.

Maybe there are others, but these are the two that I see.

Eric

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

[Elijah Meeks]

> to the space of the entire cell and not to the
> localized region 
> ("subarea", as you called it) where the unit is
> located. Now this 
> means that if I do a 'fire-into' on a cell that has
> an unseen unit 
> unit of type "u1", then the probability of hitting
> it is 
> determined by its hit chance (and any modifiers to
> that). So, assuming no 
> modifiers on the hit chance, and assuming that type
> "u1" has a 75% 
> chance of being hit by type "u2", type "u2" being
> the type which 
> is firing, then there is 75% that the unseen unit,
> "u1", will be 
> hit.
> 
> So far, so good. Now, to throw the wrench. Now
> suppose that "u1" 
> is seen, and "u2" does a 'fire-at' on "u1". Again,
> the probability 
> is 75% that "u1" will be hit.   Ooops, no good.
> 
> The problem here is that 'fire-at' assumes that the
> target is 
> being aimed at and applies the hit chance on this
> assumption. 
> Then, you are coming along, and claiming a different
> 
> interpretation of the hit chance when it is being
> used by 
> 'fire-into', where aiming is no longer being
> considered. We must 
> be able to differentiate between the two cases.
> 
> I see two ways out:
> (1) Assume that 'fire-at' has a 100% hit chance and
> apply any 
> modifiers to that chance. This is, however,
> inconsistent with the 
> way attack works, and makes little sense, IMO.
> (2) Use the method I proposed.
> 
> Maybe there are others, but these are the two that I
> see.
> 

The problem with a static solution for applying
fire-hit-chance and hit-chance to unseen units is that
it may be the case with certain attacks but not all. 
The best way I can describe this is through examples:

I have an artillery battery and I'm firing it at an
Infantry company up on a hill.  It's fire-hit-chance
is 75%.  That's fine.  But let's say I'm firing where
I think there's an infantry company.  Indirect fire is
a different method of fire, with different principles,
at least in enough cases to warrant consideration.  

Now, if I have a unit-view that turns out to no longer
represent a real unit, then this isn't a mirage, but
faulty intelligence.  A mirage or a dummy unit is
something I can see and verify to be there and should
best be represented by a unit.  A unit-view without a
corresponding unit (and, really, any unconfirmed unit
view) simply means I have reason to believe a unit is
located in that hex (and in the case of there not
being a corresponding unit, I'm wrong), which wouldn't
be the case with a unit I can see but rather a unit
that I think to be there and am firing at indirectly
(Tanks behind smoke, platoons behind hills or in
cover, newly cloaked starships, all of which I would
not fire at directly).

Likewise, in a fantasy game, if an invisible unit
attacks me, I'd like to have a unit-view, a la
Nethack's 'I'.  Maybe it's still there, maybe it's
not, but when I attack a supposed enemy, it's
different than when I attack one I know to be there. 
Again, illusory enemies would be better represented by
units (Hmmm, illusory enemies...  Sounds like I need
to add more units to Opal...).

So I think this particular problem would be best
solved with new indirect-fire-hit-chance and
indirect-hit-chance tables.  This way I could say that
a unit representing an individual with a bolt action
rifle would have a worse chance than an artillery
piece firing explosive shells to hit a unit that it
can't see.  Then you could extrapolate the
indirect-fire-hit-chance table into a system of
hitting other units within a hex, something I believe
would be better suited and allow for more dynamic
simulation of hits to stacked units than the current
system.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

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

[Hans Ronne]

>So I think this particular problem would be best
>solved with new indirect-fire-hit-chance and
>indirect-hit-chance tables.

I've been thinking along the same lines. Perhaps we should have a selected
unit hit-chance bonus table (uu_precision) that increases the probability
of hitting a selected unit, as opposed to any unit. Precision is an
important difference between different weapons. In contrast, the
probability of hitting something at random should be the same, unless you
have units with a spread-fire action, as already discussed.

Another aspect of this whole problem is the difference (or not) between how
visible and invisible units are treated. I think it might make sense for
invisible units to have a reduced hit-chance in all kinds of actions.
Presumably, the unit doing the actual attack will try to hit things it can
see first also during an overrun. So a table uu_unseen_protected might be
called for.

Hans

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

[Hans Ronne]

>I see two ways out:
>(1) Assume that 'fire-at' has a 100% hit chance and apply any
>modifiers to that chance. This is, however, inconsistent with the
>way attack works, and makes little sense, IMO.
>(2) Use the method I proposed.

The problem of visible and invisible units currently having the same
hit-chance, which you used as an example, is indeed important, as is the
question of whether targeted attacks should have an inherently higher
hit-chance. See my reply to Elijah for some comments. I fail to see how
your area-subdivision scheme would address this, however. Presumably
visible and invisible units would still have the same size in the terrain?

My basic objection to this scheme is that it introduces other units in the
cell (and their sizes) into the hit-chance calculation for a given unit. I
did my best to explain what the problem is, as I see it, and have little to
add to that. The key point is that targets of a random process (fire into a
cell) should be treated as statistically independent objects. Otherwise, we
will open the door for all sorts of weird interactions.

Hans

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

[Eric McDonald]

On Thu, 19 Aug 2004, Hans Ronne wrote:

> The problem of visible and invisible units currently having the same
> hit-chance, which you used as an example, is indeed important, as is the
> question of whether targeted attacks should have an inherently higher
> hit-chance. See my reply to Elijah for some comments. I fail to see how
> your area-subdivision scheme would address this, however. Presumably
> visible and invisible units would still have the same size in the terrain?

Right. And they should. Just because an unit is not seen does not 
mean that it should somehow have a smaller footprint than one that 
is seen in the case of random fire entering a cell, which is what 
I thought we were discussing wrt 'fire-into' (not its current 
implementation, but what it should be).

> My basic objection to this scheme is that it introduces other units in the
> cell (and their sizes) into the hit-chance calculation for a given unit. 

As more units are added to the stack then the chance that the 
stack is hit should increase. However, the chance that any one 
unit within a stack is hit should not change with stack size.

If you see an error with the way the probabilities play out in my 
scheme, could you please point out exactly what that error is?

> did my best to explain what the problem is, as I see it, and have little to
> add to that. 

C'mon, Hans. I explained the problem and you proposed something 
that turned out to be an absurdity once I compared it side by side 
with 'fire-at'. Please stop trying to twist things around.

>The key point is that targets of a random process (fire into a
> cell) should be treated as statistically independent objects. 

Right. I don't think we disagree on that point.

Eric

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

[Eric McDonald]

On Wed, 18 Aug 2004, Elijah Meeks wrote:

> Now, if I have a unit-view that turns out to no longer
> represent a real unit, then this isn't a mirage, but
> faulty intelligence.  

I think that Stan used the term "mirage" in a somewhat figurative 
sense, and didn't literally mean a mirage. The terms "ghost unit" 
and "mirage" apply to any unit view that doesn't correspond to the 
unit it purports to correspond to (excepting mistaken sightings) 
at the position of the unit view.

> that I think to be there and am firing at indirectly
> (Tanks behind smoke, platoons behind hills or in
> cover, newly cloaked starships, all of which I would
> not fire at directly).

Unfortunately, cells are not subdivided into smaller spatial 
regions in any literal sense. Even the scheme that I am proposing 
treats subregions as virtual and not having any distinct 
coordinates within the cell.

What this leads to is that if you see an unit view in a cell, you 
can attempt direct fire == aimed fire == 'fire-at' at it. If you 
don't see any unit view in the cell, but suspect there might be 
one, then you can attempt indirect fire == 'fire-into' at it. 
Indirect fire against spatial subregions is currently not 
supported and would probably require some additional 
work to add. 

> Likewise, in a fantasy game, if an invisible unit
> attacks me, I'd like to have a unit-view, a la
> Nethack's 'I'.  

Do you know which direction it attacked you from? :-)

> Again, illusory enemies would be better represented by
> units (Hmmm, illusory enemies...  Sounds like I need
> to add more units to Opal...).

:-)

> indirect-hit-chance tables.  This way I could say that
> a unit representing an individual with a bolt action
> rifle would have a worse chance than an artillery
> piece firing explosive shells to hit a unit that it
> can't see.  Then you could extrapolate the
> indirect-fire-hit-chance table into a system of
> hitting other units within a hex, something I believe
> would be better suited and allow for more dynamic
> simulation of hits to stacked units than the current
> system.

If we are saying that precision (as Hans called it) is not 
factored into 'hit-chance' and 'fire-hit-chance' already, then 
this might be something worth considering. Interesting idea....

Eric

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

[Hans Ronne]

>> The problem of visible and invisible units currently having the same
>> hit-chance, which you used as an example, is indeed important, as is the
>> question of whether targeted attacks should have an inherently higher
>> hit-chance. See my reply to Elijah for some comments. I fail to see how
>> your area-subdivision scheme would address this, however. Presumably
>> visible and invisible units would still have the same size in the terrain?
>
>Right. And they should.

OK. So your scheme doesn't distinguish between visible and invisible units.
That makes your whole argument about units "u1" and "u2", which was based
on one of them being visible and the other invisible, irrelevant to the
issue at hand (how to best model hits against stacked units).

The problem with visible and invisible units having the same hit-chance is
something that we will have to fix regardless of what model we use for the
fire-into action. It could all be handled by tables, as already discussed.
And the same is true for the efficiency of targeted vs. untargeted attacks.
We should not make things more complicated than they have to be by
introducing other units and their sizes into the hit-chance calculations
for a given unit.

>>The key point is that targets of a random process (fire into a
>> cell) should be treated as statistically independent objects.
>
>Right. I don't think we disagree on that point.

Good. Let's forget about bringing the sizes of other units into the
hit-chance calculations, then.

Hans

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

[Eric McDonald]

On Thu, 19 Aug 2004, Hans Ronne wrote:

> OK. So your scheme doesn't distinguish between visible and invisible units.

It doesn't need to. 'fire-into' doesn't need to distinguish 
between visible and invisible units.

> That makes your whole argument about units "u1" and "u2", which was based
> on one of them being visible and the other invisible, irrelevant to the
> issue at hand (how to best model hits against stacked units).

Bullshit. And you know it. The argument about units "u1" and "u2" 
pertained to _your_ scheme and not mine. Please stop twisting 
things; it is starting to get a wee bit annoying. I am not asking 
to admit your argument was wrong; if you're too proud to admit a 
mistake, that's fine by me. But don't sit there and take what I 
say out of context and attempt to distort it. I will not let you 
win an argument that way.

Only visible units can be targeted by 'fire-at'. The only way to 
have a chance to hit an invisible unit should be by using 
'fire-into', and the chance of hitting an unit (visible or 
invisible) with 'fire-into' (unaimed fire) should not be the same 
as with 'fire-at' (aimed fire).

> The problem with visible and invisible units having the same hit-chance is
> something that we will have to fix regardless of what model we use for the
> fire-into action. It could all be handled by tables, as already discussed.

Right.

> We should not make things more complicated than they have to be by
> introducing other units and their sizes into the hit-chance calculations
> for a given unit.

Without the introduction of an additional table or property, it is 
highly unlikely you will find an acceptable solution to the 
problem.

> Good. Let's forget about bringing the sizes of other units into the
> hit-chance calculations, then.

If by sizes, you mean the target area suggestion that I had, then 
maybe you should think a little bit more closely about it. It is, 
in fact, equivalent to introducing an 'indirect-fire-hit-chance' 
table or whatever the f___ you want to call it.

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

[Hans Ronne]

>Bullshit. And you know it. The argument about units "u1" and "u2"
>pertained to _your_ scheme and not mine. Please stop twisting
>things.

Frankly, Eric, it seemed to me that you were doing that, by changing the
subject to fire-at in the middle of our discussion. But perhaps this was a
misunderstanding? Let's recapitulate:

1. You proposed a scheme for how to model hits against stacked unit in
fire-into (not fire-at). I am referring to the section of your email 2 days
ago that started "Let me clarify and expand upon what I think should happen
wrt 'fire-into'". The scheme you proposed for distributing hits in
fire-into is based on unit sizes and the total terrain area.

2. I pointed out a problem with this scheme, namely that it introduces the
sizes of other units into the hit-chance calculations for a given unit.
This is undesirable both for reasons of principle (hit chances against one
unit should not depend on other units or their sizes) and practical reasons
(it makes the calculations more complicated). I suggested that a better way
to model random hits against a stack of units is to treat them as
statistically independent objects and roll a dice for each one of them.

I did not at that time discuss how to strike a proper balance between hit
chances in fire-at (targeted shots) and fire-into (random shots) or between
invisible and visible targets. I did discuss this elsewhere, in my reply to
Elijah. The reason was that I focused on the issue at hand, namely how to
best model hits against a stack of units subject to random fire (fire-into).

3. After pondering my comments, you claim that this way of modeling hits in
fire-into is flawed because the basal hit-chance against a unit would be
the same as in fire-at (your example with u1 and u2). You make a big deal
of this, and the inference is that your scheme would not suffer from
similar problems.

This argument is incorrect for several reasons. First, I did not state that
the basal hit-chances in fire-into and fire-at (or against invisible and
visible units) should always be the same. That's your assumption, not mine.
Second, these matters are irrelevant to the discussion we had, which was
about how to model random hits against a stack of units. Third, as far as I
understand, your area-subdivision scheme does not address these problems
either, unless modified by further assumptions not described in your
original proposal.

I stand by my criticism of your scheme, but please do not take it
personally. If I critisize an idea it is not to put somebody down, but to
initiate a constructive discussion. And I do think we had that in this
case, right until we got side-tracked into fire-at.

We have always been able discuss technical matters on this list without
getting emotional. Let's keep it that way. And perhaps move on to a
different subject.

Hans

Clearing the Air (long)

[Eric McDonald]

Debugging email is a tiresome business and I think both of our efforts 
could better be spent doing other things. However, I do feel compelled 
to reply to this, and attempt to set things to right.

We have worked together on this project for over a year now, and I doubt 
it would be good for the project if our collaboration were to end. So, 
I'll make another attempt to clarify and rectify.

Hans Ronne wrote:

> by changing the
> subject to fire-at in the middle of our discussion. 

I don't know how this could be construed as changing the subject. In 
practically every case where I mention 'fire-at', there is a 
corresponding mention of 'fire-into' lying near at hand. Comparison and 
contrast are legitimate tools to use in a debate.

>But perhaps this was a
> misunderstanding? Let's recapitulate:

Yes, let's:

> 1. You proposed a scheme for how to model hits against stacked unit in
> fire-into (not fire-at). 

Correct.

>I am referring to the section of your email 2 days
> ago that started "Let me clarify and expand upon what I think should happen
> wrt 'fire-into'". The scheme you proposed for distributing hits in
> fire-into is based on unit sizes and the total terrain area.

If, by unit sizes, you mean the unit target area coverages, then that is 
essentially correct.

> 2. I pointed out a problem with this scheme, namely that it introduces the
> sizes of other units into the hit-chance calculations for a given unit.

I am still quite confused by what this supposed problem is. I asked you 
earlier to give me an example of where my probabilities are screwed up, 
and you have, thus far, not done so.

But, since we're all about clarification these days, allow me to clarify:
(1) Suppose I have one unit in a cell, and its target coverage area 
(subarea size, subregion size, or whatever) against the backdrop of the 
cell is 2%, and its hit probability is 50%. The coverage area of the 
stack is therefore 2%. This means that there is a 98% chance of missing 
the stack. Now suppose that the stack is hit. What does this really 
mean? It means that we randomly chose an unit, mutliplied its target 
coverage area by its hit probability and determined a hit. In this case, 
we only have one unit, and so it is "randomly" chosen, and then its 
target coverage area (2%) is multipled by its hit probability (50%), 
thus giving it a 1% probability of being randomly hit.
(2) Suppose I have two units in a cell, and each has a target coverage 
area against the backdrop of the cell of 2%, and that their hit 
probabilities are both 50%. The coverage area of the stack is therefore 
4%. This means that there is a 96% chance of missing the stack. Now 
randomly choose one of the two units in the stack, apply its target 
coverage area multiplied by its hit probability. We get 1% (as in the 
previous case of an identical solo unit occupying the cell). Now suppose 
we miss the first unit occupying the cell, so we calculate the 
probability of hitting the second unit after it is "randomly" chosen. 
Guess what? The probability of hitting the second unit is also 1%. 
Therefore, it is not dependent on other units in the stack.

Quod erat demonstrandum (QED).

>  I suggested that a better way
> to model random hits against a stack of units is to treat them as
> statistically independent objects and roll a dice for each one of them.

You mean you suggested what I suggested?

> I did not at that time discuss how to strike a proper balance between hit
> chances in fire-at (targeted shots) and fire-into (random shots) 

That is unfortunate, because your "hit-chance" comment certainly fooled 
me into thinking you had made a significant oversight. (Your 
"hit-chance" comment is mentioned below.)

> 3. After pondering my comments, you claim that this way of modeling hits in
> fire-into is flawed because the basal hit-chance against a unit would be
> the same as in fire-at (your example with u1 and u2). You make a big deal
> of this, 

Well, yeah, it was the fatal flaw in your scheme, as I understood it. 
(Again, see the mention of your "hit-chance" comment below.)

>and the inference is that your scheme would not suffer from
> similar problems.

That is correct. It would not suffer from similar problems.

> This argument is incorrect for several reasons. First, I did not state that
> the basal hit-chances in fire-into and fire-at (or against invisible and
> visible units) should always be the same. That's your assumption, not mine.

Actually, to quote you in 
http://sources.redhat.com/ml/xconq7/2004/msg00944.html:

"Now, as I see it, all these factors (including the unit's size) are already
weighed into the hit-chance table and its various modifier tables such as
uu_protection etc. I certainly assign a larger hit chance against units
that are big targets when I design a game. So if the hit-chance for
artillery against infantry is 20% it means that an infantry unit which sits
in a standard terrain cell (no terrain modifiers) has a 20% chance of being
hit each time a piece of artillery fires into that cell."

You clearly and unequivocally state that you are considering the 
'hit-chance' table (which _is used_ by 'fire-at'), and, yes, we were 
most definitely discussing 'fire-into'. The subject had not been changed 
and 'fire-into' was very much the topic at hand.

So, my "assumption" is based on something you wrote in the context of 
the discussion. Not too shabby of an "assumption", I would say.

> Second, these matters are irrelevant to the discussion we had, which was
> about how to model random hits against a stack of units. 

You're saying that your own mention of 'hit-chance' was irrelevant to 
the discussion we had?

>Third, as far as I
> understand, your area-subdivision scheme does not address these problems
> either, unless modified by further assumptions not described in your
> original proposal.

The unit area coverage scheme was made out of the necessity to 
differentiate between 'fire-at' and 'fire-into' by better modelling 
'fire-into', and it appears to do exactly that. Your above claim that it 
does not address "these problems" is, quite frankly, bizarre and 
contradictory.

> I stand by my criticism of your scheme, but please do not take it
> personally. 

I don't take it personally. I do think it shows that you still 
misunderstand the unit target area coverage scheme.

What I am taking personally, as you likely would too if the situation 
was reversed, is what appears to be the way you have distorted my 
arguments. If you didn't understand them, you could have asked for 
further clarification instead of making them out to be something they 
are not. I even gave you an opportunity recently to demonstrate your 
understanding of them by asking you to show their supposed statistical 
flaw, but you did not take me up on the offer.

>And I do think we had that in this
> case, right until we got side-tracked into fire-at.

As I mention above, there was no sidetracking or changing of subject. If 
anything, it was your mention of 'hit-chance' that sidetracked things.

> We have always been able discuss technical matters on this list without
> getting emotional. Let's keep it that way. 

I wish we could. And perhaps calm can return again if you can 
convincingly show me that you were not abusing my arguments in the way I 
perceived.

>And perhaps move on to a
> different subject.

I would like to, but I am not sure that the 'fire-into' stuff is 
completely thought through yet. Although this is not presently as 
critical to me as some of the earlier topics in the thread, I am still 
concerned about and keen on helping make sure that we do the right/best 
thing wrt it. However, if we want to take a breather from the 
discussion, I think it would probably be welcome by all those who have 
been watching the flames and shards of ice fly.

Eric

Re: Clearing the Air (long)

[Stan Shebs]

It's almost never a good idea to guess that there must be secret evil
intent, and react as if that were really the case. There are about a
half-dozen interconnected ideas being kicked around, and I think
everybody is operating with different assumptions, some of which have
probably not been written down yet.

To put things in perspective, this is a depth of modelling that the
professional game designers don't even want to get into; if you
"deconstruct" an A-list game, you'll see that they carefully restrict
the rules, for instance to avoid stacks of units entirely by making
each unit have a physical size in a fine-grained coordinate system.
And of course the rules themselves have minimal variability. One of
Xconq's attributes is a high degree of flexibility, but as we've
seen many times, it can be difficult to take advantage of it; try
something really exotic in a game module, and interfaces are
unintelligible, the AI doesn't know what to do, etc.

So the goal is to find a set of parameters that model the kinds
of games you want to be able to play, but that means that you
need to start with an agreement about what those games are.
Just a "might want to" or "would be nice" is not enough; Xconq
is littered with stubbed-out code that started with that thought
and was never finished. Do we want to enhance the standard
game, add new tactical possibilities to the panzer game, design
new games that weren't possible before, what? After all, this
whole discussion started with Hans just trying to fix bugs...

Stan