From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10645 invoked by alias); 17 Aug 2004 21:14:52 -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 10626 invoked from network); 17 Aug 2004 21:14:50 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 17 Aug 2004 21:14:50 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i7HL9hP6010884; Tue, 17 Aug 2004 17:09:43 -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 17:14:47 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 0B80070011; Tue, 17 Aug 2004 17:14:45 -0400 (EDT) Date: Tue, 17 Aug 2004 21:55:00 -0000 From: Eric McDonald To: Hans Ronne Cc: xconq7@sources.redhat.com 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 21:14:47.0651 (UTC) FILETIME=[39BC1330:01C4849F] X-CanItPRO-Stream: default X-Spam-Score: -0.9 () X-Bayes-Prob: 0.0001 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg00936.txt.bz2 On Tue, 17 Aug 2004, Hans Ronne wrote: > >What does this have to do with interface simplification? Let's fix > >the exploits. > > The exploits are an interface problem. By eliminating the cause of the > problem (the ability to attempt bogus actions) you fix all possible > exploits in one stroke. I don't think that killing the patient is a good way to cure the diesease. Can we please just keep existing functionality while fixing the problems with it, instead of ripping out functionality as a way of fixing the problems? > >What does this have to do with interface simplification? Let's fix > >the task code. > > Which is what getting rid of bogus actions is all about. Properly dealing with bogus actions does not (or should not) entail removing two actions. > >> 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? > > Because it does not make sense. The unseen units in that cell should not be > "protected" from random hits only because we are trying to fire at > something which is not there. Really? Unless the fire-at does spread damage, the other units in the cell _should_ have a greatly diminished chance of being hit. I am starting to feel like a broken record, arguing this point over and over again. >This would mean that the state of the > player's mind (the incorrect belief that a specific unit is sitting at x,y) > would affect physical reality (the hit chances for units that really are > sitting there). How so? > >This can be taken care of merely by swapping the bindings for "f" > >and "CTRL-f" as I suggested earlier. > > No. The point was to avoid the need to switch keys, and use only one > command. Just swapping the bindings would not make things simpler. I didn't say it would. It might, however, make things more convenient for the user. > >Or to fire into an apparently empty cell to see if you can manage > >to hit anything. > > On the contrary, this is something that you could do with the normal fire > command, if it defaults to a fire-into command for an empty cell. This is > the whole point of the defaulting mechanism. You call it defaulting. I call it overloading. > >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. > > If I understand you correctly, this is pretty much the same thing as I > suggested. By defaulting fire-at to fire-into I mean that a fire-at action > with a bogus or NULL unit view would instead lead to a fire-into action > that uses the coordinates of the target cell. Hans, I think a lot of our disagreement stems from which working definition of 'fire-into' we are using. By 'fire-into' do you mean fire and hit the first unit in the stack or a randomly (possibly weighted by size) chosen unit from the stack? Or, do you mean that there is a real possibility that nothing is hit even if there is a stack of units in the cell? I have been arguing thinking that you are working from the former definition, but have been urging that we adopt the latter one. Eric