public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Jim Kingdon <kingdon@panix.com>
To: hronne@comhem.se
Cc: xconq7@sources.redhat.com
Subject: Re: Overrun actions (was: Consumption-per-fire?)
Date: Sat, 05 Jun 2004 22:54:00 -0000	[thread overview]
Message-ID: <200406052254.i55Ms1h23704@panix5.panix.com> (raw)
In-Reply-To: <l03130305bce7b9ad62f3@[212.181.162.155]> (message from Hans Ronne on Sat, 5 Jun 2004 20:35:05 +0200)

> Ideally, the unit should try the attack mode that has the highest
> probability of success first, and then use the other mode as backup,
> if necessary.

What if some materials are more precious than others?  Or one attack
does more damage than the other?  It seems better to let the
player choose, rather than guess which one they might want. 

> The other way to fix this bug is to eliminate the possibility of doing
> overruns by fire.

This makes more sense to me.

Since there will be cases in which either attack or fire is possible,
it seems like the user interface is clearer if the player (or AI) has
to explicitly say which one (the "a" and "f" keys being the most
explicit way, with overrun meaning attack-and-move-if-possible, rather
than attack-or-maybe-fire-and-move-if-possible).

> I think this was also how the overrun code originally worked, as
> revealed by check_overrun_action. The firing code in do_overrun_action
> was probably added at a later point.

Well, for what it is worth, it was added by:

Tue Jun  1 18:41:59 1999  Hans Ronne  <ronne@bmc.uu.se>

	* combat.c (do_overrun_action): Make ovverun after fire possible.
	(check_overrun_action): Make overrun after fire & into empty cell
 	possible.
	(do_fire_at_action): Use SideMask code to handle fire display.
	(do_fire_at_action): Permit attempt to capture after fire from
 	adjacent cell.
	(do_fire_into_action): Use SideMask code to handle fire display.
	(maybe_hit_unit): Support uu_cellwide_protection_against.
	(maybe_hit_unit): Support uu_cellwide_protection_for.
	(maybe_hit_unit): Use SideMask code to handle hit display.
	(maybe_hit_unit): Fix occupant recursion bug.
	(attempt_to_capture_unit): Support uu_cellwide_protection_against.
	(attempt_to_capture_unit): Support uu_cellwide_protection_for.
	(detonate_on_cell): Use for_all_stack_with_occs instead of
 	for_all_stack.
	(can_capture_directly): New function.
	(type_can_capture_directly): New function.
	(type_can_carry): New function.
	(occ_can_defend_transport): New function.

  parent reply	other threads:[~2004-06-05 22:54 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-30  2:52 build doctrine question/bug? Tom Schaub
2004-05-30  3:28 ` Eric McDonald
2004-06-02 20:30   ` Consumption-per-fire? Elijah Meeks
2004-06-04 21:44     ` Consumption-per-fire? Hans Ronne
2004-06-04 22:15       ` Consumption-per-fire? Elijah Meeks
2004-06-04 22:50         ` Consumption-per-fire? Hans Ronne
2004-06-04 23:04           ` Consumption-per-fire? Elijah Meeks
2004-06-04 23:19             ` Consumption-per-fire? Eric McDonald
2004-06-05  3:37               ` Consumption-per-fire? Elijah Meeks
2004-06-05  4:22                 ` Consumption-per-fire? Eric McDonald
2004-06-05  8:11                   ` Consumption-per-fire? Hans Ronne
2004-06-05  8:22                     ` Consumption-per-fire? Hans Ronne
2004-06-05 13:10                     ` Consumption-per-fire? Eric McDonald
2004-06-05 15:03                       ` Consumption-per-fire? Hans Ronne
2004-06-05 15:57                         ` Consumption-per-fire? Elijah Meeks
2004-06-05 17:05                           ` Consumption-per-fire? Hans Ronne
2004-06-05 18:37                           ` Overrun actions (was: Consumption-per-fire?) Hans Ronne
2004-06-05 22:30                             ` Elijah Meeks
2004-06-05 22:54                             ` Jim Kingdon [this message]
2004-06-06  0:31                               ` Hans Ronne
2004-06-06  0:59                                 ` Elijah Meeks
2004-06-06  2:21                                   ` Hans Ronne
2004-06-06  6:17                             ` Eric McDonald
2004-06-06  7:39                               ` Hans Ronne
2004-06-06 13:33                                 ` Eric McDonald
2004-06-05 17:15                         ` Consumption-per-fire? Eric McDonald
2004-06-05 19:30                           ` Consumption-per-fire? Hans Ronne
2004-06-06  6:32                             ` Consumption-per-fire? Eric McDonald
2004-06-06  4:34                           ` Consumption-per-fire? mskala
2004-06-06  6:52                             ` Consumption-per-fire? Eric McDonald
2004-06-06  7:13                             ` Consumption-per-fire? Lincoln Peters
2004-06-05  7:05               ` Consumption-per-fire? Hans Ronne
2004-06-04 23:12           ` Consumption-per-fire? Eric McDonald
2004-06-04 22:22 ` build doctrine question/bug? Hans Ronne
2004-06-05 17:08 ` Hans Ronne

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=200406052254.i55Ms1h23704@panix5.panix.com \
    --to=kingdon@panix.com \
    --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).