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: Thu, 19 Aug 2004 23:37:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0408191555410.10270-100000@leon.phy.cmich.edu> (raw)
In-Reply-To: <l03130304bd4a804bc448@[212.181.162.155]>

On Thu, 19 Aug 2004, Hans Ronne wrote:

> OK. So your scheme doesn't distinguish between visible and invisible units.

It doesn't need to. 'fire-into' doesn't need to distinguish 
between visible and invisible units.

> That makes your whole argument about units "u1" and "u2", which was based
> on one of them being visible and the other invisible, irrelevant to the
> issue at hand (how to best model hits against stacked units).

Bullshit. And you know it. The argument about units "u1" and "u2" 
pertained to _your_ scheme and not mine. Please stop twisting 
things; it is starting to get a wee bit annoying. I am not asking 
to admit your argument was wrong; if you're too proud to admit a 
mistake, that's fine by me. But don't sit there and take what I 
say out of context and attempt to distort it. I will not let you 
win an argument that way.

Only visible units can be targeted by 'fire-at'. The only way to 
have a chance to hit an invisible unit should be by using 
'fire-into', and the chance of hitting an unit (visible or 
invisible) with 'fire-into' (unaimed fire) should not be the same 
as with 'fire-at' (aimed fire).

> The problem with visible and invisible units having the same hit-chance is
> something that we will have to fix regardless of what model we use for the
> fire-into action. It could all be handled by tables, as already discussed.

Right.

> We should not make things more complicated than they have to be by
> introducing other units and their sizes into the hit-chance calculations
> for a given unit.

Without the introduction of an additional table or property, it is 
highly unlikely you will find an acceptable solution to the 
problem.

> Good. Let's forget about bringing the sizes of other units into the
> hit-chance calculations, then.

If by sizes, you mean the target area suggestion that I had, then 
maybe you should think a little bit more closely about it. It is, 
in fact, equivalent to introducing an 'indirect-fire-hit-chance' 
table or whatever the f___ you want to call it.

  reply	other threads:[~2004-08-19 20:09 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 [this message]
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=Pine.LNX.4.44.0408191555410.10270-100000@leon.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).