From: Elijah Meeks <elijahmeeks@yahoo.com>
To: Eric McDonald <mcdonald@phy.cmich.edu>, 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 06:37:00 -0000 [thread overview]
Message-ID: <20040818211030.85504.qmail@web13121.mail.yahoo.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0408181057120.3525-100000@leon.phy.cmich.edu>
> to the space of the entire cell and not to the
> localized region
> ("subarea", as you called it) where the unit is
> located. Now this
> means that if I do a 'fire-into' on a cell that has
> an unseen unit
> unit of type "u1", then the probability of hitting
> it is
> determined by its hit chance (and any modifiers to
> that). So, assuming no
> modifiers on the hit chance, and assuming that type
> "u1" has a 75%
> chance of being hit by type "u2", type "u2" being
> the type which
> is firing, then there is 75% that the unseen unit,
> "u1", will be
> hit.
>
> So far, so good. Now, to throw the wrench. Now
> suppose that "u1"
> is seen, and "u2" does a 'fire-at' on "u1". Again,
> the probability
> is 75% that "u1" will be hit. Ooops, no good.
>
> The problem here is that 'fire-at' assumes that the
> target is
> being aimed at and applies the hit chance on this
> assumption.
> Then, you are coming along, and claiming a different
>
> interpretation of the hit chance when it is being
> used by
> 'fire-into', where aiming is no longer being
> considered. We must
> be able to differentiate between the two cases.
>
> I see two ways out:
> (1) Assume that 'fire-at' has a 100% hit chance and
> apply any
> modifiers to that chance. This is, however,
> inconsistent with the
> way attack works, and makes little sense, IMO.
> (2) Use the method I proposed.
>
> Maybe there are others, but these are the two that I
> see.
>
The problem with a static solution for applying
fire-hit-chance and hit-chance to unseen units is that
it may be the case with certain attacks but not all.
The best way I can describe this is through examples:
I have an artillery battery and I'm firing it at an
Infantry company up on a hill. It's fire-hit-chance
is 75%. That's fine. But let's say I'm firing where
I think there's an infantry company. Indirect fire is
a different method of fire, with different principles,
at least in enough cases to warrant consideration.
Now, if I have a unit-view that turns out to no longer
represent a real unit, then this isn't a mirage, but
faulty intelligence. A mirage or a dummy unit is
something I can see and verify to be there and should
best be represented by a unit. A unit-view without a
corresponding unit (and, really, any unconfirmed unit
view) simply means I have reason to believe a unit is
located in that hex (and in the case of there not
being a corresponding unit, I'm wrong), which wouldn't
be the case with a unit I can see but rather a unit
that I think to be there and am firing at indirectly
(Tanks behind smoke, platoons behind hills or in
cover, newly cloaked starships, all of which I would
not fire at directly).
Likewise, in a fantasy game, if an invisible unit
attacks me, I'd like to have a unit-view, a la
Nethack's 'I'. Maybe it's still there, maybe it's
not, but when I attack a supposed enemy, it's
different than when I attack one I know to be there.
Again, illusory enemies would be better represented by
units (Hmmm, illusory enemies... Sounds like I need
to add more units to Opal...).
So I think this particular problem would be best
solved with new indirect-fire-hit-chance and
indirect-hit-chance tables. This way I could say that
a unit representing an individual with a bolt action
rifle would have a worse chance than an artillery
piece firing explosive shells to hit a unit that it
can't see. Then you could extrapolate the
indirect-fire-hit-chance table into a system of
hitting other units within a hex, something I believe
would be better suited and allow for more dynamic
simulation of hits to stacked units than the current
system.
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
next prev parent reply other threads:[~2004-08-18 21:10 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 [this message]
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=20040818211030.85504.qmail@web13121.mail.yahoo.com \
--to=elijahmeeks@yahoo.com \
--cc=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).