From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2447 invoked by alias); 19 Aug 2004 15:46:29 -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 2439 invoked from network); 19 Aug 2004 15:46:27 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 19 Aug 2004 15:46:27 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i7JFfHP6029974; Thu, 19 Aug 2004 11:41:17 -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 11:43:41 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id BA27170011; Thu, 19 Aug 2004 11:46:20 -0400 (EDT) Date: Thu, 19 Aug 2004 16:05: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 15:43:41.0864 (UTC) FILETIME=[4DA10A80:01C48603] 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/msg00961.txt.bz2 On Thu, 19 Aug 2004, Hans Ronne wrote: > The problem of visible and invisible units currently having the same > hit-chance, which you used as an example, is indeed important, as is the > question of whether targeted attacks should have an inherently higher > hit-chance. See my reply to Elijah for some comments. I fail to see how > your area-subdivision scheme would address this, however. Presumably > visible and invisible units would still have the same size in the terrain? Right. And they should. Just because an unit is not seen does not mean that it should somehow have a smaller footprint than one that is seen in the case of random fire entering a cell, which is what I thought we were discussing wrt 'fire-into' (not its current implementation, but what it should be). > My basic objection to this scheme is that it introduces other units in the > cell (and their sizes) into the hit-chance calculation for a given unit. As more units are added to the stack then the chance that the stack is hit should increase. However, the chance that any one unit within a stack is hit should not change with stack size. If you see an error with the way the probabilities play out in my scheme, could you please point out exactly what that error is? > did my best to explain what the problem is, as I see it, and have little to > add to that. C'mon, Hans. I explained the problem and you proposed something that turned out to be an absurdity once I compared it side by side with 'fire-at'. Please stop trying to twist things around. >The key point is that targets of a random process (fire into a > cell) should be treated as statistically independent objects. Right. I don't think we disagree on that point. Eric