Re: pathfinding refueling

[Hans Ronne <hronne@comhem.se>]

I think we need to refocus this discussion on how to handle refueling in
the best way. Peter's inital analysis had a lot of good points in it, but
so do some of Eric's comments. Here are my own reflections:

>Refueling points are units whose capacity and current supply exceeds the
>travelling units capacity, are either immobile or have a "refueling"
>task.

I would consider anything that has excess fuel a refueling point, even if
mobile and on a move-to task. Think of a carrier moving across the ocean on
its way to the enemy shore. It must be able to launch combat air patrols
while in transit and the latter must be able to find their way back to the
carrier for refueling.

What should be considered excess fuel is the key question. In the standard
game, I found some time ago that airplanes almost never resupplied from
carriers, since the threshold was too high. I therefore lowered it. See
ChangeLog 2003-08-17  for details.

> > >1) The storage of that material is greater than zero
> >
> > Does this include treasury storage?
>
>Its not a fuel if it is not consumed every turn or hex.

I think Eric was making the point that it is possible for fuel to be
consumed every turn or hex, but then filled up again at the start of each
turn from the treasury. This is a valid point, but it should be relatively
easy to handle.

>Maybe we need to take a more piecewise approach to path-finding.
> <snip>
>So we don't try to calculate the entire path ab initio (which
>would require considering multiple fuel types and would be messy),
>but rather do it in segments....

This is an interesting point not only with respect to refueling, but for
path finding in general. One problem with the new path code is that if a
unit cannot find a path to its destination, it does not move at all. It
just sits where it is and accumulates failed move-to tasks. With the old
code, a unit would move in the direction of its target even if it could not
get there. Problems such as blocking enemy units or a lack of transports
(maybe because the necessary advances had not yet been researched) would
frequently get solved while the unit was on its way, and the side would
gain time, which is always important.

The point here is that a war is a very dynamic situation. Tactical
decisions, including path finding, should be reconsidered frequently since
conditions may change rapidly. It could therefore make sense, as Eric
suggests, to recompute paths on every leg of a journey, and also to
reconsider what material is currently limiting the range (and thus to be
considered as fuel) for this unit here and now. To this I would add that if
a clear path to the destination cannot be found, any move that takes the
unit closer to its destination should be considered.

The notion of precomputing a complex path involving perhaps both ferry
tasks and visits to multiple resupply points is very neat. I am therefore
not saying that one should not calculate the entire path ab initio (as Eric
put it). What I am suggesting is that a unit should stop at each leg on its
journey and dynamically reconsider how to best get where it wants to go,
just like a human would do. This would not be overly burdensome and it
would make path finding much more adaptive.

A final comment is that this is also how the combat code has evolved over
the last few years. The strategy code was originally much more important. A
unit would get assigned to a theater, move there, and hold a position, with
no consideration for what would happen on the way. A unit in transit would
not attack enemy units or come to the rescue of beleaguered cities. This
lack of flexibility made it very easy to beat the mplayer. For this reason,
we added the action-reaction code which dynamically reassesses what the
unit should do.

I think that in general, an AI that dynamically recomputes its tasks
(within reasonable limits) will do much better than a static AI which
adheres to a precomputed grand plan for each of its units.

Hans