public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Jim Kingdon <kingdon@panix.com>
Cc: xconq7@sources.redhat.com
Subject: Re: bug in infantry building a base which is already started
Date: Tue, 25 May 2004 03:33:00 -0000	[thread overview]
Message-ID: <1085455903.1485.503.camel@localhost.localdomain> (raw)
In-Reply-To: <200405240345.i4O3jCG21447@panix5.panix.com>

On Sun, 2004-05-23 at 21:45, Jim Kingdon wrote:

> In the standard game, have an infantry start building a base.  So far
> so good.  Then put a second infantry in the base, and have it build a
> base in the same location.  The correct behavior is for both infantry
> to work together on building the same base (well, at least this is the
> traditional behavior).  The buggy behavior is that the build command
> seemed to work, but nothing happens (the base doesn't get further
> built, and the infantry doesn't expend an ACP).

Well, for once, the report didn't actually lead to a problem in the
create/build code. The 'for_all_view_stack_with_occs' macro does not
consider the incomplete base for some reason, when it is going through
the unit views in the cell. Instead it finds both the infantry, and, of
course, they are not interested in building one another. And so the task
fails silently.

This raises an issue of whether side notification messages should be
generated by tasks or not. The UI and the various impl_* functions are
not omnipotent, and it might be wiser to report failures at the points
of failure instead of trying to guess them (as the UI does).

But the notification issue and the apparent bug in the unit view macro
aside, I believe I have fixed the bug that you reported. I just swapped
the 'for_all_view_stack_with_occs' with 'for_all_view_stack'. The only
reason I used the former to begin with was to handle the case where a
builder might want to work on another unit's occs.

Eric

  parent reply	other threads:[~2004-05-25  3:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-24  3:45 Jim Kingdon
2004-05-24 20:00 ` Eric McDonald
2004-05-25  3:33 ` Eric McDonald [this message]
2004-05-25 21:53   ` Hans Ronne
2004-05-25 22:02     ` Hans Ronne
2004-05-25 22:27       ` Eric McDonald
2004-05-25 23:14         ` Hans Ronne
2004-05-25 23:28           ` Eric McDonald
2004-05-26  0:00             ` Hans Ronne
2004-05-26 21:00               ` Overwatch and Counterbattery? Elijah Meeks
2004-05-26 21:35                 ` Hans Ronne
2004-05-27  2:17                   ` Eric McDonald
2004-05-25 22:14     ` bug in infantry building a base which is already started 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=1085455903.1485.503.camel@localhost.localdomain \
    --to=mcdonald@phy.cmich.edu \
    --cc=kingdon@panix.com \
    --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).