From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29634 invoked by alias); 17 Aug 2004 03:03:43 -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 29622 invoked from network); 17 Aug 2004 03:03:42 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 17 Aug 2004 03:03:42 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (rwcrmhc12) with ESMTP id <2004081703034101400lhd2oe>; Tue, 17 Aug 2004 03:03:42 +0000 Message-ID: <41217581.40308@phy.cmich.edu> Date: Tue, 17 Aug 2004 03:56:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) MIME-Version: 1.0 To: Hans Ronne CC: xconq7@sources.redhat.com Subject: Re: Major bug and what to do about it (long) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00916.txt.bz2 Hans Ronne wrote: >>I disagree. There is (or should be) an attempted attack carried out on >>the ghost unit. As near as I can tell, an attempted attack could be >>framed in terms of an action (which may, in turn, invoke other actions). > > > I agree that there should be an attempt to attack the ghost unit, which > should be framed in terms of an action. That is my whole point. That is my point as well. >But this is > not how the code works. What happens is that the attempted attack never > occurs because check_fire_at_action returns false. This, I would emphasize, > happens before prep_fire_at_action is called, so the action is not even > scheduled, much less attempted. Right. And I have recognized this as shortcoming in the code since at least Dec 29 of last year. > The check_x_action functions are actually used in two completely different > ways. Right. I have done enough action and task hacking to have witnessed the two different modes of usage many times in the past. > As > I see it, the latter is really an abuse of these functions, particularly if > they reference real units instead of unit views, as in the current case. Right. And I have certainly argued in past threads that we move away from using real units at all in AI and UI code. This reduces the temptation to reference them when they should not be referenced. (And also helps forge the path towards going client-server with Xconq.) Eric