public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Hans Ronne <hronne@comhem.se>
Cc: xconq7@sources.redhat.com
Subject: Re: The border between fiction and reality
Date: Wed, 18 Aug 2004 21:10:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0408181117560.3525-100000@leon.phy.cmich.edu> (raw)
In-Reply-To: <l03130305bd4886f0d11e@[212.181.162.155]>

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

  reply	other threads:[~2004-08-18 15:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-18 15:14 Hans Ronne
2004-08-18 21:10 ` Eric McDonald [this message]
2004-08-19 11:25 ` Jim Kingdon
2004-08-19 11:57   ` Hans Ronne
2004-08-19 17:03     ` Jim Kingdon
2004-08-19 19:43       ` Hans Ronne
2004-08-19 15:46   ` Eric McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0408181117560.3525-100000@leon.phy.cmich.edu \
    --to=mcdonald@phy.cmich.edu \
    --cc=hronne@comhem.se \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).