From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2782 invoked by alias); 17 Aug 2004 01:13:33 -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 2775 invoked from network); 17 Aug 2004 01:13:32 -0000 Received: from unknown (HELO av15-1-sn4.m-sp.skanova.net) (81.228.10.102) by sourceware.org with SMTP; 17 Aug 2004 01:13:32 -0000 Received: by av15-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 03D0837E45; Tue, 17 Aug 2004 03:13:31 +0200 (CEST) Received: from smtp4-1-sn4.m-sp.skanova.net (smtp4-1-sn4.m-sp.skanova.net [81.228.10.181]) by av15-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id D68C137E43; Tue, 17 Aug 2004 03:13:31 +0200 (CEST) Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp4-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 52A9A37E43; Tue, 17 Aug 2004 03:13:31 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: <41215257.6080904@phy.cmich.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Aug 2004 01:16:00 -0000 To: Eric McDonald From: Hans Ronne Subject: Re: Major bug and what to do about it (long) Cc: xconq7@sources.redhat.com X-SW-Source: 2004/txt/msg00908.txt.bz2 >>>If the action check failed because the unit view doesn't not >>>correspond to an actual unit at the given position, then the task >>>logic should make a callback to the AI or UI to remove the unit >>>view, IMO. This would break the cycle. >> >> >> Yes, I thought about that. However, since failed tasks do not consume acps, >> this would provide a cost-free way to probe the terrain for real vs. bogus >> enemy units. > >No. Tasks don't consume ACP or anything else. Actions do. And, I don't >see a problem if a failed action consumes ACP or materials. If an attack >or a fire misses an actual unit, ACP is consumed in spite of the fact >that it was a miss. How is attacking a ghost unit any different than a miss? Because we are dealing with a failed task here, not a failed action. We never get to the point where we attack the ghost unit. That is the core of the problem. If we did attack the ghost unit, we would certainly consume acps, even if we failed. But the only way to get that far is to use fire_into_action so that the action is not aborted before it happens (or even before it can be scheduled to happen, as in this specific case). >I don't think that tasks should consume ACP or anything else. They are >too high level. We should restrict consumption to actions (as I beleive >the case is now). OK, then we agree on that point. That does, however, rule out the acp penalizing scheme as a possible solution. >>but >> it would go against how Xconq works in all other situations. For example, >> if you click where your unit cannot move, you don't spend any acps. > >In the case of movement this makes sense. But, consider that a melee >attack actually does imply movement (as we agreed upon in an earlier >thread), and thus, even if the attack is unsuccessful, the unit should >be penalized for the implied movement (preferably through the normal >attack costs). If a unit does carry out an attack which is unsuccessful, yes. But if it only gets as far as contemplating an attack (task execution) which never happens, I don't think it should be penalized. Thinking about doing something is not the same thing as doing it. Hans P.S. I think the real problem here is that real units instead of unit views are being checked at a point (task execution), where only unit views should be checked, since that is all the AI or the human player should ever know about. References to real units should be strictly limited to the action code where things do happen. Anything before that is AI code (or interface code), and should be treated accordingly. By firing into or attacking cells instead of units, we can avoid the need to mess with real units already at the task execution stage. That's the gist of my argument.