This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: The border between fiction and reality
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Hans Ronne <hronne at comhem dot se>
- Cc: xconq7 at sources dot redhat dot com
- Date: Wed, 18 Aug 2004 11:27:53 -0400 (EDT)
- Subject: Re: The border between fiction and reality
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