From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20255 invoked by alias); 17 Aug 2004 15:29:03 -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 20245 invoked from network); 17 Aug 2004 15:29:02 -0000 Received: from unknown (HELO av7-1-sn2.hy.skanova.net) (81.228.8.108) by sourceware.org with SMTP; 17 Aug 2004 15:29:02 -0000 Received: by av7-1-sn2.hy.skanova.net (Postfix, from userid 502) id C372137E47; Tue, 17 Aug 2004 17:29:01 +0200 (CEST) Received: from smtp2-1-sn2.hy.skanova.net (smtp2-1-sn2.hy.skanova.net [81.228.8.177]) by av7-1-sn2.hy.skanova.net (Postfix) with ESMTP id AB6CC37E42; Tue, 17 Aug 2004 17:29:01 +0200 (CEST) Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp2-1-sn2.hy.skanova.net (Postfix) with ESMTP id B36B837E43; Tue, 17 Aug 2004 17:29:00 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: References: <412194DC.9060907@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Aug 2004 16:01:00 -0000 To: xconq7@sources.redhat.com From: Hans Ronne Subject: Re: Major bug and what to do about it (long) Cc: Stan Shebs , Eric McDonald , Jim Kingdon , Elijah Meeks X-SW-Source: 2004/txt/msg00923.txt.bz2 >There is also the problem of what should happen if the targeted unit is not >there, but something else is sitting in the cell instead (not an uncommon >situation). My feeling is that fire-at should somehow default to fire-into. Thanks for the feedback, all of you. I think simplifying the action code is important, and in the end may decide Xconq's viability as a project. However, there are clearly some problems that first must be solved, the most important one being how to pick the best defender without making it impossible to hit a cell. Meanwhile, I think I know how to fix the various bugs and exploits that we discussed, simplify both the AI code and the interface, and maintain some selectivity. The key is the above-mentioned notion of defaulting fire-at to fire-into in the absence of the intended target. Here is my new agenda: 1. Getting rid of unit pointers in the task code. I have looked into the possibility of feeding unit views instead of units to the attack and fire-at actions, as suggested by Stan, and I think it can be done. Most of the problems are related to interface callbacks that ask for real units, but I think they can be fixed with a reasonable amount of work. 2. Unit view clearance. This will not fix the unit view bug, since the AI will continue to schedule futile hit-unit tasks as long as the bogus view is around. Clearly, we must clear the view. I think the best way is to make the failed action return a new result A_UNIT_NOT_FOUND that triggers clearance of the bogus view at a certain rate. I will make this rate a utype property. One failed hit should be enogh to tell that a metropolis is not located where it is supposed to be, but the view of a guerilla unit may take longer to clear. 3. Interface simplification. As already discussed, there are several problems with the current situation. First, there are the various exploits that make it possible to obtain information about the real world by bogus actions. Second, the task code is second-guessing the player, telling him what he may or may not do ("No visible unit to fire at in that cell"). Third, a failed fire-at action cannot hit other units in the target cell, even though you are shelling them with real ammo. I think the best way to fix these problems is to make a selective action default to the corresponding non-selective action if the intended target cannot be found. This would fix all current and future exploits in one stroke, since an attack or fire command always would result in an action being executed, with acps and ammo being spent. It would also make the human interface simpler. You would no longer need to switch to fire-into mode (ctrl-f) in order to shell an apparently emtpy cell. The normal fire-at command would do the job. The only reason to ever use an explicit fire-into command would be the unlikely situation where you want to shell a cell but avoid targeting any of those enemy units that you can actually see. For attack actions, the non-selective default would be identical to an overrun action, except for the fact that the attacking unit would not move into the cell. Jim's example with sub hunting would work like this: each time you hit 'a' a real attack would be executed even if the target cell seems to be empty. The attack may or may not hit any invisible subs in the cell. This would be completely analogous to real life sub hunting using depth charges. No more bogus attacks. 4. Combat resolution. I think the proposed changes to the overrun and fire-into actions could still be implemented within this revised agenda. By this I mean the notion that one attack should spend 1 acp and 1 round of ammo, and as a consequence hit only one unit in the stack. This would also make model 0 overruns more similar to model 1 overruns, which is a good thing for several reasons (code sharing, AI design). As already discussed, I think somewhat different schemes should be used to pick the target unit in case of fire-into and overrun actions. Hans