From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25756 invoked by alias); 19 Aug 2004 20:09:18 -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 25741 invoked from network); 19 Aug 2004 20:09:17 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 19 Aug 2004 20:09:17 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i7JK45P6019657; Thu, 19 Aug 2004 16:04:05 -0400 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Aug 2004 16:06:26 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 3A8E670011; Thu, 19 Aug 2004 16:09:06 -0400 (EDT) Date: Thu, 19 Aug 2004 23:37:00 -0000 From: Eric McDonald To: Hans Ronne Cc: xconq7@sources.redhat.com Subject: Re: Major bug and what to do about it (long) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Aug 2004 20:06:26.0757 (UTC) FILETIME=[023CCF50:01C48628] X-CanItPRO-Stream: default X-Spam-Score: -0.9 () X-Bayes-Prob: 0.0001 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg00966.txt.bz2 On Thu, 19 Aug 2004, Hans Ronne wrote: > OK. So your scheme doesn't distinguish between visible and invisible units. It doesn't need to. 'fire-into' doesn't need to distinguish between visible and invisible units. > That makes your whole argument about units "u1" and "u2", which was based > on one of them being visible and the other invisible, irrelevant to the > issue at hand (how to best model hits against stacked units). Bullshit. And you know it. The argument about units "u1" and "u2" pertained to _your_ scheme and not mine. Please stop twisting things; it is starting to get a wee bit annoying. I am not asking to admit your argument was wrong; if you're too proud to admit a mistake, that's fine by me. But don't sit there and take what I say out of context and attempt to distort it. I will not let you win an argument that way. Only visible units can be targeted by 'fire-at'. The only way to have a chance to hit an invisible unit should be by using 'fire-into', and the chance of hitting an unit (visible or invisible) with 'fire-into' (unaimed fire) should not be the same as with 'fire-at' (aimed fire). > The problem with visible and invisible units having the same hit-chance is > something that we will have to fix regardless of what model we use for the > fire-into action. It could all be handled by tables, as already discussed. Right. > We should not make things more complicated than they have to be by > introducing other units and their sizes into the hit-chance calculations > for a given unit. Without the introduction of an additional table or property, it is highly unlikely you will find an acceptable solution to the problem. > Good. Let's forget about bringing the sizes of other units into the > hit-chance calculations, then. If by sizes, you mean the target area suggestion that I had, then maybe you should think a little bit more closely about it. It is, in fact, equivalent to introducing an 'indirect-fire-hit-chance' table or whatever the f___ you want to call it.