Re: pathfinding refueling

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

On Fri, 19 Dec 2003, Peter Garrone wrote:

> this development that I am proposing does not preclude it, just doesnt
> automate it.

I understand this.

> > That is an assumption. Words like "generally" and "usually" are 
> > not the same as "always".
> 
> I am a native english speaker and I do understand what these words mean,
> thanks. For someone who doesnt want a flamewar, you sure know how to
> irritate. You will have to make your point more directly please.

Cool down, mate. I know that the .au flavo[u]r of English is not 
terribly different than my own.

I am not trying to be irritating. Like I said previously, I am 
simply seeking a technical discussion. If I know what to expect, 
I'll know better what to test (and what not to be apprehensive 
about) when I receive your patch, if I receive your patch.

All I was getting at is that you are making a solution aimed at 
what is perceived to be a majority of the cases, but it does not 
cover all of the cases.

> But that does not create the clickathon playability problem that I intend this
> code to address. I do not think it is the role of the pathfinding to
> address the strategic problem associated with lack of c.

Nor do I. I was simply pointing out that one fuel-material may be 
lower than another, even if the "full-tank" range of the lower 
fuel-material is greater.

> > No, I am saying that it is a sort of "fuel".
> 
> As I have pointed out elsewhere, the c problem does not create a
> playability problem because it gets resupplied at every turn, if within
> range, and aircraft do not ususally crash because they run out of c.

"If within range". Here is a key issue. Why should we assume that 
a unit will be within replenishment range at the end of its move?

> > But they could run out of "c".
> 
> But that is not a playability problem.

It's not? So a unit runs out of "c" and then can no longer move, 
and thus cannot refuel at least until the next turn (but possibly 
not then because of fuel attrition), __and that it is not a 
playability problem? Even though the automated movement got the 
unit into that situation?

> > As far as what "c" means: no, it does not have anything to do with 
> > loyalty. I would use the side opinion mechanism, if I wanted 
> > something like that. And it doesn't really mean attention span 
> > either. It is simply an abstract quantity of "command points".
> 
> Its irrelevant to the discussion.

Agreed. But it seemed that I needed to set the record straight.

> when making a point. Games do not generally have more than one
> fuel-material per unit. c is not a fuel-material because it does not
> require the player to move it to a refueling point to get more.

But, at times, it does. See above example.
It is consumed every movement that a unit makes, and thus I would 
regard it as a fuel based on that property alone.

> I am proposing to automate only one fuel-material per unit. The game
> designer is free to have more, just they will not be automated. But if

I understand this. It has been clear almost since the beginning of 
this discussion.

> For me range is the number of MP possible given full tanks.

OK.

> > So we don't try to calculate the entire path ab initio (which 
> > would require considering multiple fuel types and would be messy), 
> > but rather do it in segments....
> 
> I would regard this approach as a bit low-tech.

?

> The pathfinding has a set of open nodes, each node having position and
> fuel. At each step in the iteration, it gets the best current node, and
> generates all possible child nodes from it. Each child node would have
> less fuel than its parent, unless it was at a refueling point where it
> would refuel. If a child node runs out of fuel, it gets terminated.

OK. This gives me a much clearer picture into your thinking. 
Thanks.
>From a programmer's perspective, I sympathize with your approach. 
>From a player's perspective, I don't.

> What you dont seem to grasp is that it is necessary to guarantee at the
> end of a trip that the unit has the ability to travel to the nearest
> refueling point.

I understand this perfectly well. Indeed, I would rather say that 
it is one of the main points of this discussion.

> With multiple points for multiple fuels, we get an
> infinite loop. There are probably ways around this, but it gets too
> messy. 

I also said that for any one leg of the journey, only one 
resupply point for one material-fuel should be considered. I said 
that considering mutliple material-fuels at the same time would be 
messy. Where we seem to differ is that you wish to consider only 
one material-fuel for the entire journey, whereas I would prefer 
to break the journey up into legs depending on which material-fuel 
needs to be addressed, if any.

>It is only necessary to consider one fuel to achieve 100%
> automation.

I agree, if the players are willing to occasionally have their 
units 100% automatically stranded or suicided....

> Go for it. I dont endorse it, but thats irrelevant. I have better things
> to do.

I would rather not have two competing solutions to this problem; 
that is part of the reason I am trying to flesh things out with 
you.

Please understand that I am stating personal preferences on what I 
think the behavior of Xconq ought to be. My opinions are not 
necessarily shared by others who have the power to checkin a patch 
from you. Feel free to shop it around to them when you have it 
ready. I do not have any "veto" power, contrary to an assumption 
made by van Every.

I personally want to see us do what is best as possible within 
reasonable implementation complexity and CPU usage constraints. 
Something that would "usually" work in most cases may not be the 
best we can do....

After I get home from work, I will try to find some time to sit 
down and propose a number of scenarios to you. For each one, I 
will tell you how my proposed solution would deal with it, and 
then you can comment as you see fit.

  Cheers,
    Eric