From: Peter Garrone <pgarrone@acay.com.au>
To: xconq7@sources.redhat.com
Subject: pathfinding refueling
Date: Wed, 17 Dec 2003 10:28:00 -0000 [thread overview]
Message-ID: <20031217103541.GA1448@leonardo> (raw)
There was some discussion on another thread about refueling,
so I though I would attempt to tie this together in its own thread.
I propose that only one material per unit type be considered for
refueling control during pathfinding. In the standard game, this
would be fuel. In bellum, there appears to be marine fuel and aircraft
fuel. If a unit type is under refueling control, then a path is invalid
if the unit does not have enough fuel to travel to a refuelling point at the
end of its trip, and it would have enough at the start.
The pathfinding is helper-ai, not "refereed" code, so we try to keep it out
of the GDL. A material is a candidate for "fuel" for a unit if
1) The storage of that material is greater than zero
2) The consumption per move, or base consumption, is greater than zero
3) The distance that the unit can receive the material is zero.
I cannot see any units that require more than one type of fuel. In
bellum for example, the "c" material is not a fuel because it has a
send/receive distance greater than zero. In the roman game, food is a
fuel though it is only consumed per turn.
The main reason only one material can be a fuel are as follows:
- To be within range, a final untaken trip is calculated to a supply
point, and having multiple supply points makes it all too difficult.
- It would require a variable length array to be added to pathfinding
structures, making it a bit cumbersome.
Refueling points are units whose capacity and current supply exceeds the
travelling units capacity, are either immobile or have a "refueling"
task. So an aircraft carrier could be assigned a refueling task to
support an invasion. It just sits there doing nothing while aircraft
automatically go to it, refuel, get ammo, and return to the attack.
I would add some code to take ammo as well if refueling.
Peter
next reply other threads:[~2003-12-17 10:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-17 10:28 Peter Garrone [this message]
2003-12-18 5:30 ` Eric McDonald
2003-12-19 0:12 ` Jim Kingdon
2003-12-20 11:55 ` Peter Garrone
[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 6:43 ` Eric McDonald
2003-12-20 6:43 ` 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
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=20031217103541.GA1448@leonardo \
--to=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).