PathFinder status

[worktycho]

As for caching, it would probably be faster to cache the state as it getting a block involves acquiring two locks.

[LogicParrot]

Caching reduced block querying by a bit more than 10x
I am still not able to compile MCServer though, I'm doing all the tests externally in Irrlicht. I am considering switching to Jessie.

[LogicParrot]

Click for an image.
We never ask cWorld about the same block twice.
Thin yellow: cached air
Big yellow: cached solid
Thin red: closed list
Thin green: open list
Big green: final path

[jan64]

Looks nice, however unfortunately vanilla does handle half-slabs during path finding - they can go through the small cavity between a half slab and a solid block above (and this is used in cave spider farms).

[NiLSPACE]

Yes, they can go through them, but do they also walk through them by themselves?

[LogicParrot]

Seriously, this is awesome It's werid to say, but I can't wait until the first zombie is chasing me ^^

Me too!

Me 3

---

Just realized there's a neat side effect to the current interface: The further away the mob is from the destination, the less often the path is calculated, because isCalculationFinished will be called more times till the path calculation is done.

[LogicParrot]

Tomorrow I'm planning to attempt to integrate the algorithm with MCServer, it should be a "plug n play" operation because the only thing I'll need to modify is the function which queries the world for blocks (Currently it queries Irrlicht, I should make it query cWorld). @xoft and others, any changes needed to the interface?

---

Regarding half-slabs: It doesn't matter much right now. I'd rather start simple, anything is better than the brainless zombies. Partial blocks are in the roadmap and I have an idea in mind, but I'd rather neglect them for now to get this thing faster into MCServer.

[xoft]

The interface looks good enough, maybe a few small tweaks such as returning a const reference to (an internal) cPath object, rather than a naked ptr to it; those can be done as we go.

I'm just afraid that if you write your code the way you wrote the interface, you're in for a hell lot of restyling to match MCS's code style and make it past the CheckBasicStyle.lua script. We use a_CamelCase for params, CamelCase for function names, m_CamelCase for member variables; there needs to be a space after each comma ("param1, param2"), on both sides of math operators ("a = b + c") and pointer and reference declarations ("cClass & a_Param"). We use tabs for indenting, and continuation lines should have one single level of indent more than the parent line (not vertical alignment). Closing braces should be on the same indent level as the opening braces, both standing on separate lines; if a closing parenthesis is on a separate line, it should be on the same level as the line it's closing. Comments need to have at least two spaces in front of them and one space after the double-slash, and should start with a capital letter.

[LogicParrot]

I followed all the practices you just mentioned and I also made sure the lua script is not complaining. I also added Doxygen-compatible documentation to PathFinder.h

I finally have GCC 4.9, but I am having trouble integrating the class into MCServer, my main trouble is the Vector3d class, I'm not sure how to include MCServer's Vector3d in PathFinder.h, including the Vector3d.h header directly spawns some weird LUA errors.

I am trying to get the code to compile without errors.
The code is now at https://github.com/wiseoldman95/MCServer...dingReborn

Help regarding Vector3d is appreciated.

[LogicParrot]

It seems I confused between Vector3 and Vector3d, I'll keep you updated.