public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Hans Ronne <hronne@comhem.se>
To: Eric McDonald <mcdonald@phy.cmich.edu>
Cc: xconq7@sources.redhat.com
Subject: Re: Major bug and what to do about it (long)
Date: Fri, 20 Aug 2004 01:42:00 -0000	[thread overview]
Message-ID: <l03130306bd4ac13f0bec@[212.181.162.155]> (raw)
In-Reply-To: <Pine.LNX.4.44.0408191555410.10270-100000@leon.phy.cmich.edu>

>Bullshit. And you know it. The argument about units "u1" and "u2"
>pertained to _your_ scheme and not mine. Please stop twisting
>things.

Frankly, Eric, it seemed to me that you were doing that, by changing the
subject to fire-at in the middle of our discussion. But perhaps this was a
misunderstanding? Let's recapitulate:

1. You proposed a scheme for how to model hits against stacked unit in
fire-into (not fire-at). I am referring to the section of your email 2 days
ago that started "Let me clarify and expand upon what I think should happen
wrt 'fire-into'". The scheme you proposed for distributing hits in
fire-into is based on unit sizes and the total terrain area.

2. I pointed out a problem with this scheme, namely that it introduces the
sizes of other units into the hit-chance calculations for a given unit.
This is undesirable both for reasons of principle (hit chances against one
unit should not depend on other units or their sizes) and practical reasons
(it makes the calculations more complicated). I suggested that a better way
to model random hits against a stack of units is to treat them as
statistically independent objects and roll a dice for each one of them.

I did not at that time discuss how to strike a proper balance between hit
chances in fire-at (targeted shots) and fire-into (random shots) or between
invisible and visible targets. I did discuss this elsewhere, in my reply to
Elijah. The reason was that I focused on the issue at hand, namely how to
best model hits against a stack of units subject to random fire (fire-into).

3. After pondering my comments, you claim that this way of modeling hits in
fire-into is flawed because the basal hit-chance against a unit would be
the same as in fire-at (your example with u1 and u2). You make a big deal
of this, and the inference is that your scheme would not suffer from
similar problems.

This argument is incorrect for several reasons. First, I did not state that
the basal hit-chances in fire-into and fire-at (or against invisible and
visible units) should always be the same. That's your assumption, not mine.
Second, these matters are irrelevant to the discussion we had, which was
about how to model random hits against a stack of units. Third, as far as I
understand, your area-subdivision scheme does not address these problems
either, unless modified by further assumptions not described in your
original proposal.

I stand by my criticism of your scheme, but please do not take it
personally. If I critisize an idea it is not to put somebody down, but to
initiate a constructive discussion. And I do think we had that in this
case, right until we got side-tracked into fire-at.

We have always been able discuss technical matters on this list without
getting emotional. Let's keep it that way. And perhaps move on to a
different subject.

Hans


  reply	other threads:[~2004-08-19 23:37 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
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 [this message]
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='l03130306bd4ac13f0bec@[212.181.162.155]' \
    --to=hronne@comhem.se \
    --cc=mcdonald@phy.cmich.edu \
    --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).