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.
next prev parent 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).