public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Hans Ronne <hronne@comhem.se>
Cc: xconq7@sources.redhat.com
Subject: Re: Major bug and what to do about it (long)
Date: Wed, 18 Aug 2004 00:49:00 -0000	[thread overview]
Message-ID: <4122A750.6070006@phy.cmich.edu> (raw)
In-Reply-To: <l03130302bd483fae0dd7@[212.181.162.155]>

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.

  reply	other threads:[~2004-08-18  0:48 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-16 21:53 Hans Ronne
2004-08-16 22:14 ` Eric McDonald
2004-08-16 22:43   ` Hans Ronne
2004-08-17  0:33     ` Hans Ronne
2004-08-17  1:13       ` Eric McDonald
2004-08-17  1:39         ` Hans Ronne
2004-08-17  2:21           ` Eric McDonald
2004-08-17  4:28           ` Jim Kingdon
2004-08-17  5:17             ` Hans Ronne
2004-08-17 18:00               ` Eric McDonald
2004-08-18  5:26               ` Jim Kingdon
2004-08-18 11:11                 ` Hans Ronne
2004-08-17 16:14             ` Eric McDonald
2004-08-17  0:35     ` Eric McDonald
2004-08-17  1:16       ` Hans Ronne
2004-08-17  1:46         ` Eric McDonald
2004-08-17  3:03           ` Hans Ronne
2004-08-17  3:56             ` Eric McDonald
2004-08-17  1:30 ` Eric McDonald
2004-08-17  2:52   ` Hans Ronne
2004-08-17  2:53     ` Eric McDonald
2004-08-17  4:42       ` Jim Kingdon
2004-08-17 16:37         ` Eric McDonald
2004-08-17  4:48       ` Hans Ronne
2004-08-17 16:42         ` Eric McDonald
2004-08-18 10:56         ` Jim Kingdon
2004-08-17 11:06 ` Stan Shebs
2004-08-17 15:29   ` Hans Ronne
2004-08-17 16:01     ` Hans Ronne
2004-08-17 18:57       ` Eric McDonald
2004-08-17 20:38         ` Hans Ronne
2004-08-17 21:55           ` Eric McDonald
2004-08-17 23:42             ` Hans Ronne
2004-08-18  0:49               ` Eric McDonald [this message]
2004-08-18  4:59                 ` Hans Ronne
2004-08-18 15:28                   ` Eric McDonald
2004-08-19  6:37                     ` Elijah Meeks
2004-08-19 12:46                       ` Hans Ronne
2004-08-19 16:46                       ` Eric McDonald
2004-08-19 13:09                     ` Hans Ronne
2004-08-19 16:05                       ` Eric McDonald
2004-08-19 20:09                         ` Hans Ronne
2004-08-19 23:37                           ` Eric McDonald
2004-08-20  1:42                             ` Hans Ronne
2004-08-20  3:29                               ` Clearing the Air (long) Eric McDonald
2004-08-20 15:26                                 ` Stan Shebs
2004-08-18  5:30         ` Major bug and what to do about it (long) Jim Kingdon
2004-08-18 12:52           ` Hans Ronne
2004-08-17 18:23     ` Eric McDonald
2004-08-17 18:47       ` Hans Ronne
2004-08-17 18:59         ` Eric McDonald
2004-08-17 19:39           ` Hans Ronne
2004-08-17 21:14             ` Eric McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4122A750.6070006@phy.cmich.edu \
    --to=mcdonald@phy.cmich.edu \
    --cc=hronne@comhem.se \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).