From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6229 invoked by alias); 28 May 2004 02:07:02 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 6214 invoked from network); 28 May 2004 02:07:00 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 28 May 2004 02:07:00 -0000 Received: from [67.172.156.222] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (sccrmhc11) with SMTP id <20040528020659011009isq9e>; Fri, 28 May 2004 02:06:59 +0000 Subject: Re: does the tutorial lie? From: Eric McDonald To: mskala@ansuz.sooke.bc.ca Cc: Tom Schaub , xconq7@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1085709882.1485.553.camel@localhost.localdomain> Mime-Version: 1.0 Date: Fri, 28 May 2004 02:07:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00430.txt.bz2 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