This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
pathfinding refueling 2 (was Re: pathfinding refueling)
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Peter Garrone <pgarrone at acay dot com dot au>
- Cc: xconq7 at sources dot redhat dot com
- Date: Sat, 20 Dec 2003 12:08:15 -0500 (EST)
- Subject: pathfinding refueling 2 (was Re: pathfinding refueling)
On Sat, 20 Dec 2003, Peter Garrone wrote:
>I do not see it as the role of pathfinding to
> guarantee that all units remain in supply at all times.
So you then think it is OK for a unit following a path to get
stranded or suicided in some cases?
> > Nor do I. I was simply pointing out that one fuel-material may be
> > lower than another, even if the "full-tank" range of the lower
> > fuel-material is greater.
>
> Then I assume we agree that the pathfinding does not have to guarantee
> supply.
You assume incorrectly, insofar as pathfinding can guarantee
supply.
> The pathfinding does not have to guarantee supply, as we agreed.
We did not and do not agree.
>It is
> merely improving playability by reducing the number of clicks.
A laudable goal, but at what sacrifice? A stranded unit here, a
dead unit there?
> On a side note I wish you would give those bellum materials proper
> names.
They have abbreviated names so that they will properly fit on some
displays. However, the help for each material mentions what it is
and what it is good for.
> c is not an issue, because any aircaft can fill up on c when it
> fills up on fuel.
Not necessarily. In a combat zone, the resupply point may have
already been drained of c.
> An automobile service station usually supplies water air and oil
> as well as fuel.
"Usually" is key here. A service station may be sold out of any of
the above.
This working assumption that you keep making about the
availability of supplies is dangerous and unrealistic.
> materials were supplied at different positions. Then the pathfinding
> would take care of the material having the shortest effective range,
The scenarios I provided already demonstrate the fallacy of
that approach. Unless by "effective", you mean material on hand,
rather than assuming a full-tank supply.
> What example?
The one I gave where a unit runs out of c while in pursuit of f1
or f2.
> > ?
>
> Adhoc, sub-optimal. It is easy to provide cases where it would fail.
Please do. I had hoped that our discussion would have been more
along these lines.
> It takes no advantage of the optimality of the astar pathfinding
> algorithm.
Maybe not from point A to final destination B, but from A to
resupply destination C, it certainly does.
> My approach gives the player as much control as previously,
Sure, but previously a unit would not be endangered by movement
unless the player explicitly told it to do the endangering
movement.
> and freedom
> to kill off units, as is currently the case.
My approach preserves this freedom as well.
> But you do not address this issue.
How not?
> This is not a proper description for a workable algorithm.
It is not a detailed description, but it is a valid
general description.
> It certainly does not address the termination problem.
How not?
> What if you run out of material A while going for material B.
Most likely the unit would be going for material A rather than
material B, if there was a danger of A running out before B.
By contrast, your answer to this case, which I have raised several
times now, seems to be that you only care about B (assuming that
it has the shorter full-tank range), and so it doesn't matter what
happens with A.
>What if a
> later leg is found to be impassable.
A leg cannot be impassable or else it wouldn't be a leg. (Or does
your implementation of Astar allow for impassable paths to be
calculated? :-)
But, maybe you are wondering what if the unit cannot reach its
final destination because of the chosen legs?
Well then, I guess it won't reach its final destination. At least
the unit is still alive, and didn't die an automated death. It
would be closer to the final destination.
> How do you determine the most
> suitable refueling hops.
I illustrated this in the scenarios I provided yesterday.
> I am not interested in implementing this approach myself, so would
> prefer not discussing it in this thread.
I renamed the thread....
I am not interested in having two competing approaches. I have
demonstrated aspects of yours which are unsound. I have yet to be
shown how mine is unsound.
> For all current games, if the unit takes on all possible fuels at each
> refueling point, the single fuel approach will work.
Sure. "If" it takes on. Even if a game is designed to provide all
the possible fuels at one resupply point, that resupply point is
not guaranteed to be able to provide them.
So even if someone doesn't design a "stupid" game, it is still
possible for your approach to do something bad to a unit.
> different point to get c. There are several ways to handle this. If the
> pathfinding had to handle it, then the best way would be to extend the
> path node state to include two fuel quantities.
I have already stated that I think the best way would be to focus
on whatever was the more critical fuel-material quantity.
Trying to create a path based on two or more fuel-materials
simultaneously would be a computational nuisance, as I think both
you and I agree.
> The best way to handle this hypothetical situation is to simply have the
> player ferry the aircraft between the points that supply c, and it will
> pick up ordinary fuel in intermediate hops.
If it doesn't run out of c en route.
> > I agree, if the players are willing to occasionally have their
> > units 100% automatically stranded or suicided....
>
> Well units occasionally get stranded and suicided now.
Sometimes a unit may get stranded due to changing game
circumstances (as Hans said, war is a dynamic situation), but
there isn't a thing you can do about that (except possibly play
better :-). And, of course, a player may choose to suicide a
unit....
> has to think it out. I dont believe that the pathfinding should
> guarantee that no unit will ever be lost to lack of supply.
It cannot guarantee that, but it should not be callous about it
either.
>Rather it
> should automate the micromanagement (credit to Hans for this term) a bit.
Agreed.
Eric