Re: Major improvement to the Xconq kernel

[Peter Garrone <pgarrone at acay dot com dot au>]

On Sun, Nov 16, 2003 at 03:33:32PM -0500, Eric McDonald wrote:
> On Sun, 16 Nov 2003, Peter Garrone wrote:
> 
> > Maybe we should delay just a little bit more, get the testing cirle a
> > bit wider, to avoid unnecessary rebuilds. 
> 
> Sure. I think I am going to delay at least another day. I do think 
> all of the known major issues have been addressed. There might be 
> a few minor things:
> 
> (1) Now that paths can be computed through unexplored hexes, the 
> question is what should the cost of an unexplored hex be? If the 
> cost is low like it is now, then paths through them will be 
> favored over known paths. This doesn't matter if a unit is 
> exploring the unknown, but if it is trying to get from known point 
> A to known point B, then we either need to favor the partially 
> unexplored path, or else avoid it. I'm not entirely sure which....

I'm working on a patch so that the unexplored part is 2 MP per hex.
Therefore if a unit gets
a command to explore a distant hex, it will preferentially travel over
known teritory before entering the black. If the destination is unknown,
then an exploring flag bit is set. If that bit is not set, it will not
travel in the black.

> (2) We need to make sure that a unit moving along a cached path 
> does not move into vanishes-on or wrecks-on terrain, if that 
> terrain was not visible when the path was first computed. We 
> should do so without peeking at the terrain during path 
> computation, otherwise it opens the door to cheating.... This 
> probably implies that a check is needed before each move along the 
> cached path, if a check does not already exist (I haven't looked 
> yet).

In my proposed patch a path node that was in the unknown has a special flag bit set.
If that bit is set, then the path is recalculated each hex. That
way an exploring unit will follow roads and avoid obstacles. It
should be reasonably efficient because searching in the black is cheap.


> (3) We need to make sure that a unit moving along a 
> cached path will stop following that path if it is low on 
> supplies. I have seen several instances of units getting stranded 
> (due to low supplies) when they pulled out of supply range while 
> heading to a remote destination. (This might not be strictly a 
> path-related problem.)

I have later plans to incorporate refueling behavior into the
pathfinding algorithm. The node state would be position and amount of
fuel. As a node runs out of fuel it becomes un-pathable, so to speak.
With care, it should be possible to transport aircraft across the board,
without needing to plan all the refueling stops.

I dont think the current behavior is different to the prior behavior,
so perhaps we should get to the prior functionality first.

Peter