Re: pathfinding refueling

[Peter Garrone <pgarrone@acay.com.au>]

On Sun, Dec 21, 2003 at 01:27:22AM +0100, Hans Ronne wrote:
> >This heuristic should work. After refueling successfully at a refueling
> >point, a units checks its next refueling point by examining the cached
> >path.
> >
> >If it has insufficient movement points
> >to reach the next point in the move, and it has used some mp this turn,
> >and the next point is a mobile
> >unit, it goes into reserve for that turn,
> >and rechecks at the start of its next turn.
> 
> Yes, if fuel consumption is per-move. If it is per-turn, going into reserve
> makes little sense. Unless it can resupply itself from the terrain, of
> course.

Thanks. Of course in the roman game, food is consumed per turn. But that
would never be a problem because there arent any mobile land-based
resupply points. But I will certainly check for that in the code.

> 
> Yes. But we must still check the treasury in order to decide what materials
> should at all be considered as fuel.

I am planning on testing all materials for all materials, once at the
start. If any materials are consumed and required per turn or per move,
then it is a fuel. If any fuels have a receive-from distance of zero,
then it is a controlled fuel. The controlled fuel giving the shortest
range is the one that is controlled in the path-finding. But all
refueling points must be able to replenish all fuels required, otherwise
it is ignored as a refueling point. I am not planning to do a global
treasury check. Actually I am not completely sure what you mean, which
is why i am reiterating the proposed algorithm, hopefully it covers what
you mean.

> 
> 
> >> Yes. It depends on how big the computational load is. The optimal solution
> >> would be once each turn, right before the unit moves, so that the tactical
> >> situation always is up-to-date. This is how the action-reaction code works.
> >> But if we cannot afford that, I would suggest at least at the following
> >> points:
> >>
> >> 1. When the unit leaves a resupply point (so that it may check what
> >> material is currently limiting its movement and use it as fuel in the path
> >> calculation).
> >
> >I think my suggested heuristic ovecomes this. It investigates the next cached
> >resupply point, and if it is out of any sort of fuel, or has moved, then
> >recalculate.
> >
> >> 2. When a unit leaves a ferry.
> >
> >I am not in complete agreement here.
> >The ferry will drop a unit off at its planned point.
> >Perhaps when a ferry drops off a unit, a recalculation for all
> >other occupants might be justified, because the current dropdown point might
> >be better than the scheduled point for a unit. This should provide sufficient
> >tactical flexibility.
> 
> My thinking was that after the unit has been sitting x number of turns on a
> ferry, the tactical situation has changed. And it is the unit that gets off
> that has to worry about blocking enemy units etc. So a path recalculation
> at this point seemed like a good idea.

Ferry dropdowns are relatively rare, so I dont really have a problem
doing this.

> 
> >> 3. When its movement is obstructed in any way.
> >
> >What do you mean by obstruction? The pathfinding will naturally move
> >around terrain obstructions, and also calculate optimal paths based on
> >friendly units moving out of the way to an extent. But if an action
> >suggested by the pathfinding fails, then it would probably be reasonable
> >for a re-calculation.
> 
> That's what I meant. The prime example being an enemy unit that blocks the
> path.

OK.

> 
> >One point is that with refueling and a more sophisticated
> >transportation ferrying model, pathfinding will become quite expensive.
> >There are some very big games in the library, so some care needs to be
> >taken.
> 
> I agree. Only testing can tell what we can afford in the end. And I think
> getting the path cache to work without desync problems will be critical.
> The code is much faster with it.

I was thinking of trying to set a global flag that determines if the
function is called locally or should be pushed globally, so that it is
easy to determine if caching should occur or not. Another way would be
to set a bit in the "flags" parameter that determines if the function is
invoked from the mplayer/ai code or not, and that can control caching,
so you might do that as a temporary fix there. I will eventually be
looking at these options.

Peter