public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: mskala@ansuz.sooke.bc.ca
Cc: Tom Schaub <tom_and_sue_schaub@mac.com>, xconq7@sources.redhat.com
Subject: Re: does the tutorial lie?
Date: Fri, 28 May 2004 02:07:00 -0000	[thread overview]
Message-ID: <1085709882.1485.553.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.21.0405272043490.13337-100000@diamond.ansuz.sooke.bc.ca>

On Thu, 2004-05-27 at 18:48, mskala@ansuz.sooke.bc.ca wrote:
> I have not specifically tried the case you're talking about, but a couple
> thoughts: First of all, the tutorial probably *does* lie.  So does most of
> the rest of the documentation.  I've written things that the documentation
> said would work, and had them not work, quite often.  You have to solve
> these things by experiment, and preferably report it so the documentation
> and/or code can be fixed.

I'm not going to sit here and get defensive about the manuals since I
didn't write them, and have certainly been frustrated by them a number
times as well.

However, I am not sure that it is fitting to describe the manuals as
"lying". I doubt that Stan wrote them with an intent to deceive. Rather,
it seems that features and code changes have accumulated over time, and
those that added the features or made the changes didn't bother to
document their work in a way that was accessible to users or game
designers. So, I would say that they are outdated but not intentionally
deceiving. I suppose this might be an issue of semantics though.

I think a valid question is: should they be marked as such on the Xconq
Web site? These manuals also do contain up-to-date information, so maybe
they should simply have a caveat lector note next to their links.

> On your specific problem, I imagine that it's probably a zone of control
> issue.  I've faced something similar in one of my projects.  Units exert a
> zone of control that by default covers their entire hex, and units from
> enemy sides cannot enter that zone without attacking and defeating the
> controlling unit.  Look up zone of control (ZOC) in the manual, and try
> changing the zoc-range table to -1 for rubble piles versus all units.

I believe that is what Stan was just suggesting. Alternatively, one
might also be able to adjust the 'mp-to-enter-zoc' and 'mp-to-leave-zoc'
tables to make the ZOC non-blocking.

Eric

  reply	other threads:[~2004-05-28  2:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-27 23:55 Tom Schaub
2004-05-28  0:37 ` Stan Shebs
2004-05-28  0:47 ` mskala
2004-05-28  2:07   ` Eric McDonald [this message]
2004-05-28  6:45     ` Jim Kingdon
2004-05-28 16:46       ` Eric McDonald
2004-05-28 17:46       ` Stan Shebs
2004-05-28 17:27     ` Stan Shebs
2004-05-29  1:20       ` 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=1085709882.1485.553.camel@localhost.localdomain \
    --to=mcdonald@phy.cmich.edu \
    --cc=mskala@ansuz.sooke.bc.ca \
    --cc=tom_and_sue_schaub@mac.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).