public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: mskala@ansuz.sooke.bc.ca
To: Elijah Meeks <elijahmeeks@yahoo.com>
Cc: xconq7@sources.redhat.com
Subject: Re: Table Request: Accident-Occupant-Effect
Date: Thu, 23 Sep 2004 02:26:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.21.0409222125590.29175-100000@diamond.ansuz.sooke.bc.ca> (raw)
In-Reply-To: <20040923004610.31863.qmail@web13121.mail.yahoo.com>

On Wed, 22 Sep 2004, Elijah Meeks wrote:
> Only accidents don't affect occupants.  So, if anyone
> can think of a better solution to this problem, let me
> know, otherwise, if somebody in the know gets the
> chance, I think it's worthwhile to see accidents
> affect occupants.

I don't know if this is better, but you could probably do it by giving
each "offline" unit a material which, once fully consumed, will cause the
unit to wreck into its "online" form.  For randomness you could give it
just one point of the material and use a sufficiently small fractional
consumption rate (we do support fractional consumption rates, right?).

While we're wishlisting for terrain accidents, I would like to be able to
set accidents or attrition for *movement through*, as opposed to *presence
in*, terrain.  I wanted to model a school bus which can be driven over
hostile terrain, but which takes damage if you do that.  Well, if I use
"attrition" then you can drive over rocks and broken glass with impunity
as long as you make sure to end the turn on the road; and if I use
"wrecking" then you pay the penalty as soon as you move into a
hostile-terrain hex, but the wrecked form can't also be vulnerable to
wrecking on that terrain, because wrecking repeats recursively until it
hits a form that won't wreck in the hex.

Neither of those solutions addresses the fact that if you park on hostile
terrain you shouldn't take any additional damage just sitting there,
beyond the damage you took getting there - it is movement in particular
that causes the damage.  The ideal solution would be to be able to set a
(possibly fractional and probabilistic) hit point cost paid every time,
and as soon as, the unit moves into (or maybe out of) a hex of the hostile
terrain..
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

  reply	other threads:[~2004-09-23  1:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-23  1:40 Elijah Meeks
2004-09-23  2:26 ` mskala [this message]
2004-09-23  5:38   ` Eric McDonald
2004-09-23 15:09   ` Elijah Meeks
2004-09-23 17:59     ` Eric McDonald
2004-09-24  1:51       ` Elijah Meeks
2004-09-23  3:10 ` Eric McDonald
2004-09-23 17:47   ` Elijah Meeks
2004-09-23 18:23     ` 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.21.0409222125590.29175-100000@diamond.ansuz.sooke.bc.ca \
    --to=mskala@ansuz.sooke.bc.ca \
    --cc=elijahmeeks@yahoo.com \
    --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).