From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9736 invoked by alias); 18 Aug 2004 00:48:42 -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 9728 invoked from network); 18 Aug 2004 00:48:41 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org with SMTP; 18 Aug 2004 00:48:41 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (rwcrmhc11) with ESMTP id <200408180048400130018u9ue>; Wed, 18 Aug 2004 00:48:40 +0000 Message-ID: <4122A750.6070006@phy.cmich.edu> Date: Wed, 18 Aug 2004 00:49:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) MIME-Version: 1.0 To: Hans Ronne CC: xconq7@sources.redhat.com Subject: Re: Major bug and what to do about it (long) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00943.txt.bz2 Hans Ronne wrote: >>Properly dealing with bogus actions does not (or should not) >>entail removing two actions. > > I am not suggesting that. Okay, good. > I don't like the current situation where you get a free > shot at all units in the stack for just one acp. Nor do I. >What I would like to have > is an action where you fire at the cell, one unit is picked as the target, > and you either hit or miss that unit. The logic behind this would be that > the shell has to land somewhere in the cell, and only one unit can sit > where it lands. But, this is where we differ, I think. The shell has to land somewhere, and it is possible that _no_ unit sits where it lands. >So yes, it would certainly be possible to do a fire-into > action and not hit a single unit. The probability of missing an unit is not the same as the probability of landing where an unit is not. (And it is for this reason why I argued that missing a ghost unit should not imply a normal chance to hit another unit.) > I don't think that this a necessary preconditon for fixing the other bugs, > though. I favour a step-by-step procedure. Sure. I am not trying to delay you from fixing the other bugs. I hope this was not your impression. My only concern right now is getting the most sensible thing done regarding 'fire-at' at ghost units and the general handling of 'fire-into'. Let me clarify and expand upon what I think should happen wrt 'fire-into': (1) When a 'fire-into' is executed, it should first tally up the total percent of the cell that is covered by unit target area. Unit target area should ideally be determined by a new TableUT and TableUU. Unit sizes in terrain are for cell capacity limits which are not the same as target areas. For example, a cell could only hold 16 units of a given type, but their total target area might only be 32% (2% per unit). (2) After the total unit target area is calculated, a call to 'probability' should be made if it is less than 100%. If 'probability' returns false, then the barrage missed all units. (For the future: Damage should only be calculated if spread damage is indicated rather than point damage.) (3) If 'probability' returns true or total target area >= 100%, then one of the units in the stack should be selected with larger ones (presumably larger target areas) given preference. The usual hit-or-miss logic should be applied to that unit. If that unit is missed, then no damage occurs to any unit in the cell (with the possible exception of spread damage). If that unit is hit, then it is damaged per normal rules. Now, I think that what you are arguing for is what I termed as 'fire-at-any' earlier. 'fire-at-any' assumes a 100% probability of hitting the stack, and then essentially proceeds with step (3) as outlined above. I hope this clears up what I am getting at. Eric P.S. The default for unit target area might be somewhat tricky to handle. Probably it would have to be -1, with the understanding that Xconq would recalculate it during game initialization, perhaps by taking a proprotion using 'unit-size-in-terrain' and terrain capacity for the new TableUT, and using 'unit-size-as-occupant' and unit capacity for the new TableUU.