From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30275 invoked by alias); 17 Aug 2004 18:47:32 -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 30267 invoked from network); 17 Aug 2004 18:47:30 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 17 Aug 2004 18:47:30 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i7HIgJP6004787; Tue, 17 Aug 2004 14:42:19 -0400 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Aug 2004 14:47:23 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 5B27A70011; Tue, 17 Aug 2004 14:47:16 -0400 (EDT) Date: Tue, 17 Aug 2004 18:57:00 -0000 From: Eric McDonald To: Hans Ronne Cc: xconq7@sources.redhat.com, Stan Shebs , Jim Kingdon , Elijah Meeks 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: 17 Aug 2004 18:47:23.0098 (UTC) FILETIME=[A1F863A0:01C4848A] X-CanItPRO-Stream: default X-Spam-Score: 0.5 () X-Bayes-Prob: 0.9999 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg00930.txt.bz2 On Tue, 17 Aug 2004, Hans Ronne wrote: > 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. Good. > 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. I would add that this should only be applicable in the case of firing. In the case of attacking, which seems to be a bit more personal and up-close, I think the unit view should disappear instantly if there is not a real unit to prop it up. > 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. What does this have to do with interface simplification? Let's fix the exploits. >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"). What does this have to do with interface simplification? Let's fix the task code. > Third, a failed fire-at action cannot hit other units in the target cell, > even though you are shelling them with real ammo. And this is a bad thing because? > 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 also automatically switches action types on a player without his or her explicit consent. > 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. This can be taken care of merely by swapping the bindings for "f" and "CTRL-f" as I suggested earlier. > 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. Or to fire into an apparently empty cell to see if you can manage to hit anything. (I think one of the areas of confusion arising in this discussion is that the current implementation of 'fire-into' applies the full hit-chance, if I remember the code correctly, to the first unit it finds in a cell; I think this, in itself, is broken, and that, unless spread damage is in effect, the chance of 'fire-into' hitting something should be miniscule and weighted by the discovered target's 'size-in-terrain'.) > 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. Good. This is reasonable. I would suggest two actions: 'attempt-attack' and 'attempt-fire'. Each would take a UnitView*, x and y coords, and possibly a number-of-times-to-execute argument. If the the UnitView* is NULL, then it should mean attempt an overrun in the 'attempt-attack' case, and do a fire-into in the 'attempt-fire' case. (1) If the kernel determines that the unit view passed to the attempted action no longer corresponds to an unit at the position, then: (a) in the case of an attempted attack, it expends ammo and ACP and returns 'A_UNIT_NOT_FOUND', as suggested by Hans. The unit view should be removed immediately. (b) in the case of a fire-at, it expends ammo, has the UI draw firing lines, and then returns 'A_UNIT_NOT_FOUND', if, after a dice roll or random number in a probability, it is determined that the firing unit has discovered that it is firing upon something that is not there. (2) If the kernel determines that the unit view corresponds to an unit at the position, then: (a) in the case of an attempted attack: run the attack code as normal. (b) in the case of fire-at: run the fire code as normal. (3) If the kernel is dealing with a NULL unit view, then: (a) in the case of an attempted overrun: run the overrun code with the ACP/materials deduction modifications suggested by Hans. (b) in the case of a fire-into: run the fire-into code with the hit probability modifications suggested by me. Is this creating more complexity and more code to maintain? Yes and no. One might note that the only real difference between case (1) and case (2) is that 'damage_unit' gets called in case (2) whereas it does not in case (1). Thus, there is much code in common between those cases. OTOH, we are adding some new logic, and would have twice as many action checks as before: the existing versions, which would be for internal kernel usage, and new versions, which would be for use by the AI and UI. Eric