public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Stan Shebs <shebs@apple.com>
To: Hans Ronne <hronne@comhem.se>
Cc: xconq7@sources.redhat.com
Subject: Re: Major bug and what to do about it (long)
Date: Tue, 17 Aug 2004 11:06:00 -0000	[thread overview]
Message-ID: <412194DC.9060907@apple.com> (raw)
In-Reply-To: <l03130301bd46b33ac8ea@[212.181.162.155]>

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

>

  parent reply	other threads:[~2004-08-17  5:17 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-16 21:53 Hans Ronne
2004-08-16 22:14 ` Eric McDonald
2004-08-16 22:43   ` Hans Ronne
2004-08-17  0:33     ` Hans Ronne
2004-08-17  1:13       ` Eric McDonald
2004-08-17  1:39         ` Hans Ronne
2004-08-17  2:21           ` Eric McDonald
2004-08-17  4:28           ` Jim Kingdon
2004-08-17  5:17             ` Hans Ronne
2004-08-17 18:00               ` Eric McDonald
2004-08-18  5:26               ` Jim Kingdon
2004-08-18 11:11                 ` Hans Ronne
2004-08-17 16:14             ` Eric McDonald
2004-08-17  0:35     ` Eric McDonald
2004-08-17  1:16       ` Hans Ronne
2004-08-17  1:46         ` Eric McDonald
2004-08-17  3:03           ` Hans Ronne
2004-08-17  3:56             ` Eric McDonald
2004-08-17  1:30 ` Eric McDonald
2004-08-17  2:52   ` Hans Ronne
2004-08-17  2:53     ` Eric McDonald
2004-08-17  4:42       ` Jim Kingdon
2004-08-17 16:37         ` Eric McDonald
2004-08-17  4:48       ` Hans Ronne
2004-08-17 16:42         ` Eric McDonald
2004-08-18 10:56         ` Jim Kingdon
2004-08-17 11:06 ` Stan Shebs [this message]
2004-08-17 15:29   ` Hans Ronne
2004-08-17 16:01     ` Hans Ronne
2004-08-17 18:57       ` Eric McDonald
2004-08-17 20:38         ` Hans Ronne
2004-08-17 21:55           ` Eric McDonald
2004-08-17 23:42             ` Hans Ronne
2004-08-18  0:49               ` Eric McDonald
2004-08-18  4:59                 ` Hans Ronne
2004-08-18 15:28                   ` Eric McDonald
2004-08-19  6:37                     ` Elijah Meeks
2004-08-19 12:46                       ` Hans Ronne
2004-08-19 16:46                       ` Eric McDonald
2004-08-19 13:09                     ` Hans Ronne
2004-08-19 16:05                       ` Eric McDonald
2004-08-19 20:09                         ` Hans Ronne
2004-08-19 23:37                           ` Eric McDonald
2004-08-20  1:42                             ` Hans Ronne
2004-08-20  3:29                               ` Clearing the Air (long) Eric McDonald
2004-08-20 15:26                                 ` Stan Shebs
2004-08-18  5:30         ` Major bug and what to do about it (long) Jim Kingdon
2004-08-18 12:52           ` Hans Ronne
2004-08-17 18:23     ` Eric McDonald
2004-08-17 18:47       ` Hans Ronne
2004-08-17 18:59         ` Eric McDonald
2004-08-17 19:39           ` Hans Ronne
2004-08-17 21:14             ` 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=412194DC.9060907@apple.com \
    --to=shebs@apple.com \
    --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).