Re: [glob2-devel] a->b->c (pathfinding with zwischenstop)

[Leo Wandersleb]

Hi Kai

Thanx for taking your time to think it over but i guess there are some
misunderstandings.

> 1. The first thing that comes into my mind is:
> when deciding in which direction to go, try a field that reduces the
> distance to the nearest resources and if possible the distance to the
> building that controls the worker too (or at least doesn't increase
> it).  Maybe consider a small disk instead of just the next field.
> For a start this should weaken the problem in some cases.

The now used algorithm (gradient/wavefront) does not allow this approach.
Imagine it as a landscape with the special property to have no place that is
a local minimum without beeing 0 whereas 0 is the level of the searched
resource/building. You have such a landscape for each target
(corn/wood/stone/fruit1/fruit2/fruit3/every single building).
Now corn is found by walking down the corn-landscape to level 0 and then the
inn12 is found by walking down the inn12 landscape. if you mix 2 landscapes
you get local minima where the glob is closest to both corn and inn12 but
doesn't find neither the one nore the other.

HA! Idea!
Bad idea, i think :( 
Walk down the Inn12+corn gradient to a local minimum(/saddle point) and then
procede with the normal algo. unfortunately this local min needn't be a
global min. also the combined gradient might be const on wide areas. :( also
the direct path to the shortest path between inn and corn would be an
improvement it is far from beeing optimal.

> 2. When a worker gets a job for a new building-resource,
> you could use the gradients to determine the resource the worker
> is heading to. (Well this works not in constant time, but it is fast
> since you know each step.  Combine this with 1. to get a promising
> resource.)
> Then you can compare the distances:
> worker-this_resource-building
> with
> worker-building-nearest_resource-building
> and dicide if resource or building should be the target.

?? if i got you right, you take the resource that's closest to the building
in consideration. that resource doesn't need to be reachable by the glob at
all.

> 3. If the worker hands over its first delivery to the building, it could
> be let to the part of the building that is nearest to a needed
> resource - only if that is not to far off and a considerable improvement.
> (For example using a small gradient initiated from that field)
> I think the actual improvement would be small, but the globs might
> look smarter this way.

again: if the spot is reachable, this could help.

> 4. Globs could go to the building before they start out for the resource.
> Ok, this is ugly, but fast to calculate and never worse then 2 times
> the optimal route.

no way! that's the worst of all possibilities as a remote suply-inn would
never get a single corn.

> 5. Make globulish behaviour part of race customization and let
> the user worry about it ;-)

??

> > C
> > C
> > CHHG
> > CHH
> > CII
> > CII
> > Cx
> > C
> >
> > G runs around H again and again rather than sitting at x and handing
> > in the C.
> 
> I guess here you are looking at two different inns.
> The upper right inn and the lower left - is that correct?

no. inns are 2x2. so it is just one inn.

> Kai Antweiler

Leo Wandersleb