The border between fiction and reality

The border between fiction and reality

[Hans Ronne]

In my hunt for unit pointers I ran into an interesting problem. Where
exactly is the border between plans and actions in the case of the human
player? Most of the discussion so far has focused on the AI, and I think
there is a consensus that things happen only when an action is executed.
Anything before that (plan execution, task execution) is planning code that
should deal with unit views only.

For the human player, the answer is easy when we are dealing with command
functions that directly schedule actions. Until the command is given, it is
all planning. The corresponding interface code should therefore use unit
views only, which is what the human player sees.

If a human command schedules a task for execution, things become a little
more complicated. However, one can argue, as I have done, that as long as
the task has not scheduled any actions, nothing has really happened that
affects the state of the game. Hence, the task execution code would also be
part of the (extended) planning code, just as for the AI. Unit pointers
should be banned.

However, a different situation arises with move-unit commands, all of which
eventually end up in advance_into_cell. At this point we are committed to
moving, and we have to know what real units are present in the destination
cell. Unit views will not do. Consider the case of a single invisible enemy
unit in the target cell. Because of its presence, advance_into_cell will
schedule an overrun action. In its absence, it schedules a move action.
Whether we see the unit or not is irrelevant.

Every call to advance_into_cell in the interfaces is therefore preceeded by
a unit_at which gets a pointer to the first real unit in the stack.
According to the principle that the interfaces should deal only with unit
views, I started to convert these calls to unit_view_at instead, but soon
realized that this was a mistake.

The best that we can do in this case is to restrict the unit pointers to
the common interface code by letting advance_into_cell look them up itself.
And I will probably do that. Feeding it a unit pointer as an argument that
it can look up itself doesn't make much sense, anyway.

The conclusion would seem to be that advance_into_cell is really part of
the action code (that part of the kernel where things do happen). But it is
also, by definition, part of the interface. So perhaps the two are
inseparable.

One may ask, then, is there really a difference between advance_into_cell
and the task execution code? Both of them recieve commands from the
interface (human player) and both of them schedule actions. Perhaps we
should permit unit pointers in the task execution code as well?

In fact, the task code which does the same thing as advance_into_cell
(do_move_to_task and do_approach_subtask) also checks for real units in the
destination cell. However, the main reason for this seems to be that these
tasks once could schedule attack actions against enemy units, just like
advance_into_cell does. That code was later commented out, so I'm not sure
to what extent we really need these unit pointers in the task execution
code.

Hans

Re: The border between fiction and reality

[Eric McDonald]

On Wed, 18 Aug 2004, Hans Ronne wrote:

> However, a different situation arises with move-unit commands, all of which
> eventually end up in advance_into_cell. At this point we are committed to
> moving, and we have to know what real units are present in the destination
> cell. 

Do we?

> Consider the case of a single invisible enemy
> unit in the target cell. Because of its presence, advance_into_cell will
> schedule an overrun action. In its absence, it schedules a move action.
> Whether we see the unit or not is irrelevant.

Right. Are you saying this is a problem?
If we are advancing into a cell as a result of a movement 
task, then a flag should be passed to the 'advance_into_cell' 
code to indicate that an overrun should not be attempted in the 
case of a seen enemy unit. If the enemy unit is unseen, the an 
overrun should, in fact, be attempted, because this case is no 
different than if the human player had been clicking along cell by 
cell and had accidentally run into the unseen enemy.

> Every call to advance_into_cell in the interfaces is therefore preceeded by
> a unit_at which gets a pointer to the first real unit in the stack.

Yuck.

> According to the principle that the interfaces should deal only with unit
> views, I started to convert these calls to unit_view_at instead, but soon
> realized that this was a mistake.

I am talking without having seen the code recently, so perhaps I 
am missing something, but I would not consider that to be a 
mistake.

> In fact, the task code which does the same thing as advance_into_cell
> (do_move_to_task and do_approach_subtask) also checks for real units in the
> destination cell. However, the main reason for this seems to be that these
> tasks once could schedule attack actions against enemy units, just like
> advance_into_cell does. That code was later commented out, so I'm not sure
> to what extent we really need these unit pointers in the task execution
> code.

Like I stated earlier, if the human wouldn't know the enemy was 
there and the enemy is on the path being taken, then the human 
would have likely clicked on the cell containing the enemy if 
he/she had been moving cell by cell with keys or clicks. The 
automatic movement should not use special knowledge to avoid 
combat when, in fact, the human player could not have such 
knowledge.

Eric

Re: The border between fiction and reality

[Jim Kingdon]

> However, a different situation arises with move-unit commands, all of which
> eventually end up in advance_into_cell. At this point we are committed to
> moving, and we have to know what real units are present in the destination
> cell.

Well, to me that means there should be an advance action, so that the
decision between overrun and move (and the other choices, like
capture) are in the action, rather than outside it.

But perhaps there is a simpler solution, or the status quo is
technically wrong but doesn't lead to any exploits/leaks/etc.  Or even
that advance_into_cell is tied into the user interfaces in ways which
aren't immediately obvious to me, and thus would be hard to put into
an action.

Re: The border between fiction and reality

[Hans Ronne]

>> However, a different situation arises with move-unit commands, all of which
>> eventually end up in advance_into_cell. At this point we are committed to
>> moving, and we have to know what real units are present in the destination
>> cell.
>
>Well, to me that means there should be an advance action, so that the
>decision between overrun and move (and the other choices, like
>capture) are in the action, rather than outside it.

That makes sense. I'll look into it.

>But perhaps there is a simpler solution, or the status quo is
>technically wrong but doesn't lead to any exploits/leaks/etc.  Or even
>that advance_into_cell is tied into the user interfaces in ways which
>aren't immediately obvious to me, and thus would be hard to put into
>an action.

In fact, there is one more rather interesting complication, considering our
previous discussion about selective actions and one action defaulting into
another one. When you click in the target cell, as opposed to a do_dir
command, the interfaces actually look up the unit under the cursor. This is
something that the common interface code cannot do, since the pixel
coordinates differ between different interfaces. It is the main reason why
unit pointers are present in the tcltk/mac/x11 code.

So what is this selected unit doing in a basically non-selective action?
Well, it turns out that if the overrun fails because you don't have enough
ammo to hit all units in the stack, the action is converted into a
selective attack against the unit under the cursor. Here is the relevant
code from advance_into_cell:

rslt = check_overrun_action(unit, unit, x, y, z, 100);
if (valid(rslt)) {
    net_prep_overrun_action(unit, unit, x, y, z, 100);
    return TRUE;
}
if (reason && rslt == A_ANY_NO_AMMO)
    *reason = (HistEventType)rslt;
rslt = check_attack_action(unit, unit, other, 100);
if (valid(rslt)) {
    net_prep_attack_action(unit, unit, other, 100);
    return TRUE;
}

I don't think this happens very often in real games. At least, I was not
aware of the potential selectivity of clicking on a unit. It makes me
wonder if this selectivity could be used also in a successful overrun
action. For example, one could perhaps make the unit that was clicked on
the first one to be attacked, instead of using the normal stack order. Or
make this unit more likely than others to be hit.

Hans

Re: The border between fiction and reality

[Eric McDonald]

On Thu, 19 Aug 2004, Jim Kingdon wrote:

> > However, a different situation arises with move-unit commands, all of which
> > eventually end up in advance_into_cell. At this point we are committed to
> > moving, and we have to know what real units are present in the destination
> > cell.
> 
> Well, to me that means there should be an advance action, so that the
> decision between overrun and move (and the other choices, like
> capture) are in the action, rather than outside it.

I agree. After looking at code again, I saw what Hans was actually 
having an issue with. I would recommend the 'advance' action as 
well. The concept is really not much different than what we have 
been discussing regarding attempted attacks and attempted fire; 
this is simply an attempted move. And again, the distinction is 
handled at the action level, and so there is no requisite that 
unit pointers be used to divine something ahead of time at the 
task level.

Eric

Re: The border between fiction and reality

[Jim Kingdon]

> So what is this selected unit doing in a basically non-selective action?
> Well, it turns out that if the overrun fails because you don't have enough
> ammo to hit all units in the stack, the action is converted into a
> selective attack against the unit under the cursor.

Hmm.  Seems pretty confusing.  I could see making it selective in
general, or non-selective in general, but having it sometimes one and
sometimes another seems odd.

If we want selective, I assume the way is to have the UI pass a unit
view, not a unit, into the kernel.

But making it consistently non-selective is the way I would lean.

Re: The border between fiction and reality

[Hans Ronne]

>> So what is this selected unit doing in a basically non-selective action?
>> Well, it turns out that if the overrun fails because you don't have enough
>> ammo to hit all units in the stack, the action is converted into a
>> selective attack against the unit under the cursor.
>
>Hmm.  Seems pretty confusing.  I could see making it selective in
>general, or non-selective in general, but having it sometimes one and
>sometimes another seems odd.
>
>If we want selective, I assume the way is to have the UI pass a unit
>view, not a unit, into the kernel.

Right. I am currently testing one way of doing this using two new tasks
(TASK_ATTACK and TASK_FIRE). I would prefer to do everything at the action
level, but that proved difficult due to complications involving the network
code.

>But making it consistently non-selective is the way I would lean.

That would certainly be simpler. But perhaps less fun :-).

Hans