+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: PathFinder status (/thread-1571.html)
RE: Implementing Pathfinding - LogicParrot - 04-23-2015
I finally got the PathFinder to compile as part of MCServer!
The issue was that MCServer's Vector3 had no hash function. I had to modify Vector3.h, I added this.
namespace std
{
template <>
struct hash<Vector3d>
{
std::size_t operator()(const Vector3d & v2) const
{
return(v2.x + v2.y + v2.z); // TODO this is not the best hash out there
}
};
}
This is obviously a primitive hash function, I'm going to change it into a Z-order curve, but it made the code compile.
Next steps:
- Z-order curve for Vector3
- Make the class query cWorld / cChunk
- Make a zombie pathfind
RE: Implementing Pathfinding - jan64 - 04-23-2015
About cave spiders: they do use these sorts of paths (the design i mentioned earlier is basically a hole in the wall that they have to climb to)
RE: Implementing Pathfinding - LogicParrot - 04-23-2015
Just realized a Zcurve is overkill in this case. There are simpler hash functions that do the job.
RE: Implementing Pathfinding - worktycho - 04-24-2015
A couple of points regarding cPath. If you are transferring ownership with the return from getPath, you should return a unique_ptr. But since it's such a small type why not make it a value type? Also since the client shouldn't mutate the path why not return a const cPath?
RE: Implementing Pathfinding - LogicParrot - 04-24-2015
@worktycho:
Regarding const: you're probably right, in fact, there are many stuff in the interface that should be const and they aren't, I'll change that.
Regarding returning cPath as a value type: cPath has an internal dynamic allocation of a vector, wouldn't it be messy to return it that way?
Progress:
Vector3d hash: I implemented a simple Vector3d hash function which concatenates the first byte of each of the x,y,z values after they're casted to ints. The result is a hash function which guarantees no hash collisions in any 128x128x128 area, more than enough for pathfinding.
Checking for solids: I've been looking at LineBlockTracer to try to understand how to query the world for block status, I realized my class is missing a cWorld. I assume the mobs need to pass their m_World to the PathFinder, is that correct?
RE: Implementing Pathfinding - LogicParrot - 04-24-2015
Is it possible to somehow fetch the cWorld of the current World?
RE: Implementing Pathfinding - xoft - 04-24-2015
I don't understand your question. You either have a cWorld instance and that is your current world, or you don't have and then you don't have any world.
RE: Implementing Pathfinding - LogicParrot - 04-24-2015
I may be making some wrong assumptions, I never dealt with this before. So help me ask the right question:
- I don't have a cWorld in PathFinder.cpp and I need one for fetching block status (Correct?)
- This means that the mobs who are interesting in PathFindeing should pass the cPathFinder a cWorld instance (Correct?)
- Currently, I don't want to deal with mobs, so I asked if I can fetch the cWorld of the overworld without them.
RE: Implementing Pathfinding - worktycho - 04-24-2015
If you're just using it for testing you can use cRoot::GetDefaultWorld().
RE: Implementing Pathfinding - xoft - 04-24-2015
Let the mob pass a cWorld instance to the pathfinder via a special function that will be called whenever the mob's world changes (mob goes through a portal); this function should also reset all the pathfinding progress so far etc.
EDIT: Note that you can't pass the cWorld instance through the constructor, because at the time of construction the mob has no world assigned to it yet. The world is assigned in the cMonster::Initialize() function.