PathFinder status
#41
We do have The ComponentRewrite branch but it's more then a 1000 commits behind.
Reply
Thanks given by:
#42
Oh, it's April already!
Well then, Here's a teaser Wink
I'll explain it all tomorrow.

https://imgur.com/1sL3WeA
Reply
Thanks given by: NiLSPACE
#43
Alright, yesterday I've decided to resume work on this. and it worked quite well! I have edited the original post, please check it out.
Reply
Thanks given by: NiLSPACE
#44
I'd say that the wiggling is a pretty serious issue, it signifies that something is actually wrong with the algorithm.
Reply
Thanks given by:
#45
I am debugging that right now.

The algorithm seems fine, it takes the "general shortest path", but it wiggles along the way.
Reply
Thanks given by:
#46
Still debugging. In the meanwhile, what do you think of this interface?

I recall you wanted a "dumb device" which receives coordinates are spits out a path. Ideally, this would have been a static class with a single function "getPath".
But I had to make instances because:
  • MCserver is threaded, a static function seemed dangerous to me
  • A mob might want to spread the load of calculating a path across several ticks, this is impossible with a single static function. A single static function would have to be blocking.

I'd love to hear if you have a better proposal.

    cPathFinder(
            double a_boundingBoxWidth,  // The character's boundingBox Width. (Currently preset to 1, parameter will be ignored)
            double a_boundingBoxHeight, // The character's boundingBox Height. (Currently preset to 2, parameter will be ignored)
            int a_maxUp,                // What is the highest wall this character can climb / jump? (Currently preset to 1, parameter will be ignored)
            int a_maxDown               // How far down is the character willing to fall? TODO more flexibility here.  (Currently preset to 1, parameter will be ignored)
            );

    ~cPathFinder();
    void findPath(int a_maxSearch, const Vector3d &a_startingPoint, const Vector3d &a_endingPoint);
    bool isCalculationFinished();
    cPath* getPath();

interface usage example:

//When a zombie is born...
m_pathFinder=pathFinder(1,2,1,1); //The parameters do nothing because they are not implemented yet
...
//When a zombie wants to attack someone.
pathFinder.findPath(100,myLocation,theirLocation);

//Every tick...
if (pathFinder.isCalculationFinished())
{
     myPath=pathFinder.getPath();
     //now walk that path.
}
Reply
Thanks given by:
#47
Wiggle fixed.
Reply
Thanks given by: NiLSPACE
#48
Seriously, this is awesome Smile It's werid to say, but I can't wait until the first zombie is chasing me ^^
Reply
Thanks given by:
#49
I just keep thinking, do we even need the non-integral math? Can't we base this on full or empty voxels? How much would we lose? I think all monsters can attack you when they're closer than 1 block away from you, so it doesn't matter, if they pathfind to an integral coord. And the entity bounding boxes don't matter much for pathfinding, just round them up to the nearest whole block, good enough.
Reply
Thanks given by:
#50
@xoft, what about half slabs, etc?

By the way, the current algorithm is exactly as you describe, I was planning to add non-int stuff when reaching the "Deal with partial blocks" step.
Reply
Thanks given by:




Users browsing this thread: 5 Guest(s)