From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1301 invoked by alias); 17 Aug 2004 19:39:54 -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 1294 invoked from network); 17 Aug 2004 19:39:53 -0000 Received: from unknown (HELO av6-2-sn2.hy.skanova.net) (81.228.8.107) by sourceware.org with SMTP; 17 Aug 2004 19:39:53 -0000 Received: by av6-2-sn2.hy.skanova.net (Postfix, from userid 502) id 426D237E45; Tue, 17 Aug 2004 21:39:53 +0200 (CEST) Received: from smtp2-2-sn2.hy.skanova.net (smtp2-2-sn2.hy.skanova.net [81.228.8.178]) by av6-2-sn2.hy.skanova.net (Postfix) with ESMTP id 2E3AF37E43; Tue, 17 Aug 2004 21:39:53 +0200 (CEST) Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp2-2-sn2.hy.skanova.net (Postfix) with ESMTP id 52E3337E43; Tue, 17 Aug 2004 21:39:52 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Aug 2004 20:38: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/msg00934.txt.bz2 >> 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. 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. >>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. Which is what getting rid of bogus actions is all about. >> 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. 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). By defaulting fire-at to fire-into, we avoid this absurdity and fix the exploits at the same time. >> 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. 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. >> 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. 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. >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