Re: Major improvement to the Xconq kernel

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

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

> over-keen perhaps. I dont really know how the building setup works on
> this game.

Both the RPM and Windows installer builds are fairly trivial and 
don't consume much time. The only problem I have with releasing 
several times in a couple of days is that I have to boot into 
Windows to make the installer program.

> I think I probably suppressed my own observations of a
> few of these reported problems. Its easy to do.

Well, I think it was good to bring the code forward when you did. 
With more eyes looking at it and how it behaves, we can track and 
fix things quicker than you could by yourself.

  Regards,
    Eric