public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Hans Ronne <hronne@comhem.se>
To: Eric McDonald <mcdonald@phy.cmich.edu>
Cc: xconq7@sources.redhat.com
Subject: Re: Major bug and what to do about it (long)
Date: Tue, 17 Aug 2004 01:16:00 -0000	[thread overview]
Message-ID: <l03130303bd47042bd358@[212.181.162.155]> (raw)
In-Reply-To: <41215257.6080904@phy.cmich.edu>

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



  reply	other threads:[~2004-08-17  1:13 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 [this message]
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
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='l03130303bd47042bd358@[212.181.162.155]' \
    --to=hronne@comhem.se \
    --cc=mcdonald@phy.cmich.edu \
    --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).