Re: Major problem with the path code

[Eric McDonald <mcdonald@phy.cmich.edu>]

Hi Peter,

On Thu, 27 Nov 2003, Peter Garrone wrote:

> My apologies. I am still learning this system to an extent, and have
> been focused on getting this pathfinding doing.

No apologies necessary. I was painting with a fairly broad brush 
when I made those comments. I'm sure you have much more specific 
knowledge of the action/task/plan taxonomy than I do, since my 
only real exposure to it came while I was looking through the 
create/build code some time ago.

> The supply should conform to definite simple rules though.

The point-to-point movement, yes, I agree.

> But it should take account of enemy zoc, and terrain. 

I believe that support is already in the kernel, but I might have 
read somewhere that it wasn't working too well and so it was 
disabled. I haven't looked what the actual status of it is yet.

>I suppose an
> algorithm that first flags each hex for enemy zoc, then moves out from
> each supply unit looking for units to supply and taking terrain into
> account might seem like ai. But it should conform to definite well
> specified rules would be my main concern. 

Agreed.

>But task/plans/doctrine is fuzzy ai
> behavior, so should not be in the "server".

Yes. Agreed.

> because its "ai" does not necessarily mean it should not be in the
> server. However there are other good reasons why it shouldnt be there.
> But a decent supply algorithm would look a lot like the astar algorithm
> of course.

I would also call your pathfinding code "AI". But I would call it 
"helper AI" rather than "machine player AI".

I've thought more about the supply code and the semantics of 
resupply since I wrote my earlier email to you. I think that I 
would now agree that doing cluster analysis and acting according 
to that would constitute a "helper AI" activity, rather than a 
core activity. I still have a concern that if we end up with an 
architecture where we do have separate client and server 
processes, then having a client's "helper AI for resupply" request 
materials movement by the server/referee could generate lots of 
traffic....

> We are in heated agreement here. 

:-)   Which is a nice change from the battlefield scene that the 
list became in the past few weeks.

>I hope I am not rehashing too much old
> ground.

I don't know. I haven't looked at the list archives in this 
regard. But, I personally think it is good to have this 
discussion, since it seems that we have both the will and the 
ability to act on it quite soon.

> recognise that such separation is a significant effort, so should wait
> for now.

For now. But if you're up to the task in the next release cycle, I 
am definitely willing to help.

  Best regards,
    Eric