Re: pathfinding refueling

[Hans Ronne <hronne at comhem dot se>]

>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.

>Obviously there are some extraordinary situations that would defeat
>this. Too many aircraft could such the carrier dry. The carrier could be
>sunk, or die somehow. But we only want something simple that mostly
>works.

Agreed. Accidents happen in real life, too.

>I dont think it is up to the pathfinding to ensure supply, otherwise it
>replicates the supply code. Rather the human or ai player should not
>send units on extended moveto tasks if running out. However the
>pathfinding could ensure that units skirt around local shortages of
>av-fuel, sea-oil, "c".

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

>> Assigning a new task is what I had in mind. A move-to task to the closest
>> point on the failed path. Which means that the path-finding code would have
>> to return that point to the AI when it fails.
>>
>> As for ships getting tasks that they cannot possibly reach, this is really
>> an AI problem. I would say that the best way to handle that is to let the
>> AI use the landsea_regions area layer to check if a possible destination is
>> reachable for a unit that cannot be ferried.
>
>No. If the pathfinding fails, then there really will be no way for that
>task to succeed, not even by developing the technology to build a ferry
>and by building a ferry. The ai would be better off selecting a completely
>different mission for that unit. The pathfinding means that the ai has
>much better ability to determine which missions have any chance and which
>have none.

I think getting closer to the enemy is generally  a good idea, even if you
cannot reach him. At least, you can perhaps stop him from invading you by
massing your troops on the beaches. However, finding a new plan is a good
alternative. The problem is that the AI will do neither. It will keep the
plan, typically a PLAN_OFFENSIVE which assigns the unit to hold an area
which it cannot reach, and then set the same move-to task resulting in the
same path failure over and over again.

This is what I meant when I said that it is really an AI problem rather
than a path-finding problem. The AI should check if a point is at all
reachable already at the plan level. This could be done by using the
landsea_regions area layer, path-finding, or a combination of both. If the
plan goal is not possible, the AI should replan instead of proceeding with
impossible tasks.

>> 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.

>> 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.

>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.

Hans