From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32004 invoked by alias); 29 Sep 2004 05:26:27 -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 31910 invoked from network); 29 Sep 2004 05:26:26 -0000 Received: from unknown (HELO smtp809.mail.sc5.yahoo.com) (66.163.168.188) by sourceware.org with SMTP; 29 Sep 2004 05:26:26 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@64.175.251.169 with plain) by smtp809.mail.sc5.yahoo.com with SMTP; 29 Sep 2004 05:26:25 -0000 Subject: Re: Transports that affect protection? From: Lincoln Peters To: Eric McDonald Cc: Xconq list In-Reply-To: References: Content-Type: text/plain Message-Id: <1096435736.4050.4494.camel@localhost> Mime-Version: 1.0 Date: Wed, 29 Sep 2004 14:52:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01280.txt.bz2 On Tue, 2004-09-28 at 12:12, Eric McDonald wrote: > On Mon, 27 Sep 2004, Lincoln Peters wrote: > > city. The wall usually provides 1000% protection against normal attacks > > (they can only attack the wall), so the army is going to have one heck > > of a time taking the city. On the other hand, if a siege tower moves > > adjacent to the city, any knights within the tower should be able to > > attack the city and ignore the wall. The same is true for knights who > > attack from flying vehicles or from the backs of flying monsters. > > It is tempting to classify this as a sort of elevation-dependent > problem. > > As I recall, there is already a property out there which affects > an occupant's height (for the purpose of vision). Perhaps this > could be commandeered for some sort of attack modification as > well. Just a thought.... That is an interesting thought, and I can see how it might solve this problem. > I would probably restate the problem as how a transport modifies > its occupant's hit chance versus various targets. I believe that > there is already a sort of generalized occupant hit chance > modifier table, a TableUU between transport and occupant. I think > what you are proposing would perhaps require something like > 'transport-adds-hit-chance-against' (one would not be able to > specify an occupant type in this case, since we don't have 3D > tables, __just the type of the occ's transport and the type of > the defender). Somehow, I had not realized that a 3D table might be required to do exactly what I was describing. A "transport-adds-hit-chance-against" table should work in my case, though. I'll add that to the "to-do" list for knightmare.g, then implement it there when it is implemented in the kernel. (In case your wondering, I think I'm close to having an Alpha release ready, but my off-line schedule is such that I can't predict exactly when.) --- Lincoln Peters Parts that positively cannot be assembled in improper order will be.