public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Peter Garrone <pgarrone@acay.com.au>
Cc: xconq7@sources.redhat.com
Subject: Re: pathfinding refueling
Date: Sat, 20 Dec 2003 06:43:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0312182226010.14884-100000@leon.phy.cmich.edu> (raw)
In-Reply-To: <20031218220459.GA969@leonardo>


OK, here are the scenarios. For the purposes of this discussion, I 
have a couple working definitions:
(1) Fuel-Material: Any material which must be consumed during 
normal movement of a unit.
(2) Range: The distance a unit can go, consuming a fuel-material, 
before it must resupply that fuel-material.

And the scenarios are:
(1) Suppose that a unit has just finished with combat and is now 
low on two fuel-materials, fuel1 and fuel2. The unit is at point 
A. The unit would like to move to point B. Destination C has an 
available supply of fuel1, but no available fuel2. Destination D 
has an available supply of fuel2, but no available fuel1. The unit 
consumes fuel1 and fuel2 at the rate of 1 per move. The unit has 3 
out of 10 fuel1 and 4 out of 8 fuel2. The distance from A to C is 
3, from A to D is 4, and C to D is 2.
  Under your proposal, fuel2 would be regarded as the critical 
fuel-material. However, because fuel1 is in a low supply 
condition, either you would have to wait for the player to request 
the destination again to override a safeguard (similar to the 
existing behavior), or else you would have to ignore it under the 
assumption that it would be replenished at the end of the turn. If 
you ignored it, then you seem to suggest that the unit would be 
directed towards destination D (because fuel2 has the shorter 
range). However, in that case, the unit would never make it, 
because it would run out of fuel1 first.
  Under my proposal, I would make sure that the player was aware 
of the fuel-materials situation by perhaps making him/her 
re-request a destination. If given the re-request, then the 
pathfinder would recognize that fuel1, not fuel2, was the most 
critically needed, and would direct the unit towards destination 
C, not D. The unit would arrive at C and refuel. After that, the 
unit would still be in a predicament because it would have only 1 
fuel2 left to reach D with, __not enough. However, it would have a 
better chance at regaining mobility or just surviving because it 
was able to replenish fuel1 (at least to some extent).

(2) Consider scenario 1 with the following modification. The unit 
now has 6 out of 8 fuel2.
  Under your proposal, the unit would attempt to reach destination 
D (as in scenario 1) and would fail because it ran out of fuel1 
first (as in scenario 1).
  Under my proposal, the pathfinder would recognize that fuel1 was 
the more critical and would attempt to reach destination C. The 
unit would reach destination C, refuel, and then attempt to move 
to B. Having only 3 of 8 fuel2, it would then divert to D (or 
possibly a destination E, if E was within range, had available 
fuel2, and was closer to B than D). There, it would refuel, and 
then attempt to move onward to final destination B. In this 
circumstance, my proposal is a clear win, because the unit 
remains mobile and intact.

I have a few other scenarios in mind, but I am getting tired, so I 
will leave them for another day (perhaps tomorrow).

Eric

  parent reply	other threads:[~2003-12-19  4:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20031218063340.GA733@leonardo>
2003-12-18 21:54 ` Eric McDonald
2003-12-19  1:43   ` Peter Garrone
2003-12-19  4:12     ` Eric McDonald
2003-12-20  6:44       ` Peter Garrone
2003-12-20 23:00         ` pathfinding refueling 2 (was Re: pathfinding refueling) Eric McDonald
2003-12-20  6:43     ` Eric McDonald [this message]
2003-12-20  6:43       ` pathfinding refueling Peter Garrone
2003-12-20 22:50         ` Eric McDonald
2003-12-20 23:00           ` Hans Ronne
2003-12-21  2:36             ` Peter Garrone
2003-12-20 23:21           ` Peter Garrone
2003-12-21  7:27             ` Mark A. Flacy
2003-12-20  6:43     ` Hans Ronne
2003-12-20 16:09       ` Peter Garrone
2003-12-20 17:08         ` Hans Ronne
2003-12-20 23:31           ` Peter Garrone
2003-12-21  7:22             ` Hans Ronne
2003-12-21 23:07               ` Peter Garrone
2003-12-22 11:46                 ` Hans Ronne
2003-12-23  4:08                 ` Lincoln Peters
2003-12-23  4:25                   ` Peter Garrone
2003-12-17 10:28 Peter Garrone
2003-12-18  5:30 ` Eric McDonald
2003-12-19  0:12 ` Jim Kingdon
2003-12-20 11:55   ` Peter Garrone

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.0312182226010.14884-100000@leon.phy.cmich.edu \
    --to=mcdonald@phy.cmich.edu \
    --cc=pgarrone@acay.com.au \
    --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).