This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Major problem with the path code
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Peter Garrone <pgarrone at acay dot com dot au>
- Cc: xconq7 at sources dot redhat dot com
- Date: Wed, 26 Nov 2003 18:37:21 -0500 (EST)
- Subject: Re: Major problem with the path code
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