From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4554 invoked by alias); 3 Dec 2003 03:04:55 -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 4542 invoked from network); 3 Dec 2003 03:04:54 -0000 Received: from unknown (HELO garm.central.cmich.local) (141.209.15.48) by sources.redhat.com with SMTP; 3 Dec 2003 03:04:54 -0000 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2003 22:04:53 -0500 Received: from localhost (unknown [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 72FC27001F; Tue, 2 Dec 2003 22:04:48 -0500 (EST) Date: Wed, 03 Dec 2003 21:13:00 -0000 From: Eric McDonald To: Lincoln Peters Cc: Xconq list Subject: Re: Reduced Visibility Table? In-Reply-To: <1070419340.15132.353.camel@odysseus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 03 Dec 2003 03:04:53.0665 (UTC) FILETIME=[394E3110:01C3B94A] X-SW-Source: 2003/txt/msg00955.txt.bz2 Hi Lincoln, On Tue, 2 Dec 2003, Lincoln Peters wrote: > Could there have been more than one unit in that cell? I checked for that by thoroughly scouring the hex and its vicinity with land units and air units following the obliteration of the enemy Armor. So I think the chances are low, though not impossible. Anyway, it would still be a bug because any other unit that could have possibly been in that cell would also have been vulnerable to the Fighters and hence should have been attacked.... >I've run into > that occasionally, but only when two or more enemy units are present in > a cell and I am only aware of the presence of one of them. Yes, I have too. It can make firing into a cell a total PITA. > It's because > when the UI tries to figure out what you want to do, it sees multiple > small unit images when you see only one, Right. I believe that the xform_unit code in kernel/ui.c is partially responsible for this, or at least that's what I got from looking at it when I was fixing a bug last week. > I would agree that it's a bug; the action the unit takes should be based > on what you see when you click on a cell, not necessarily what is > actually there. > > Did anything I just said make any sense? Completely. Like I said, I have seen this behavior too. But I believe it to be a separate issue. Eric