PathFinder status

[worktycho]

I'd keep the pathfinder as a separate class. That way it can be made in to a static member of the mobs classes and the setup only needs to be done once per mob type rather than once per mob. As for access to the world, could we make it so that the class passed to the pathfinder does not have to be a cWorld so the the pathfinder is testable? Either by templating the pathfinder class or by using an interface class?

[LogicParrot]

The interface has no idea where to do the pathfinding. You need to get a cChunk instance in it somehow so that it can query blocks. Note that you don't normally have access to a cChunk object unless you do a cWorld::DoWithChunk() - so your interface should get a cWorld instance, call DoWithChunk() on it internally and then do the actual pathfinding. See the cLineBlockTracer for a similar example (didn't I write this already?)

Also the usage of the class is somewhat unintuitive now - if you want to do pathfinding, you first create an instance, feed a few params to it, and then call one of its methods, only to destroy the instance afterwards. Can't it all be wrapped into a static function that would create the instance internally with all the data it needs?

Hold on! The instance does not get destroyed after you use it to create a single path! If it were that way, I would have created a static class.

The idea here is that a mob is supposed to store his Pathfinder instance for as long as the mob exists. Why? Because that saves lots of memory allocations. internally, the instance will be reusing stuff when generating different paths. I hope to achieve zero dynamic allocations after the first path is generated.

Edit: I still haven't added the cChunk thing, yet.

Edit2: Well, not exactly zero. The cPath which is spat out will have some size.

[xoft]

Then the cPathfinder constructor can actually receive a reference to the cPath object (that will be stored in the cMonster as well) so that it will not need another param, can pre-allocate the path etc.

[LogicParrot]

Then the cPathfinder constructor can actually receive a reference to the cPath object (that will be stored in the cMonster as well) so that it will not need another param, can pre-allocate the path etc.

Your proposal breaks the idea of a "dumb device". How will you handle static paths?

I think the current way it's done is the most flexible because it covers all the use cases, here's an example:

Case 1, a zombie, always chasing the player

Upon spawning, create a cPathfinder instance, and create a cPath instance.
Always call the cPathfinder::findPath and pass on cPath. cPath is reused and memory is saved.

Case 2, a custom mob - a patrolling zombie.

Upon spawning, create a cPathfinder instance, create a cPath instance for chasing the player, and a cPath array for the static patrol routes.
For each cPath in the array, call cPathfinder::findPath only once and pass on that cPath.
When chasing the player, forget the array and switch to a regular zombie behavior and use the cPath reserved for chasing.

---

Another approach would be merging the two classes. Wanna chase the player? No problem, just create a single "MergedThing" instance and call findPath. Want 3 static routes? create 3 of that instance and call findPath for each. The disadvantage here is that each of the different instances of MergedThings will make some allocations that would have been made only once if one had create a single Pathfinder and derived the paths from it. So the current interface is still better in this regard.

[LogicParrot]

Interface V6 pushed and partially implemented. I hope this one is final. Comments welcome and encouraged.

Edit: Interface undo, now using V5.

[LogicParrot]

I'm afraid I will no longer update my branch until later this year (Perhaps November).
Keep the comments coming though, I will read them thoroughly when I get back.

[archshift]

Can I call functions using the game's chat?
e.g. typing /hello 12 2915 calls foo(12,2915)
I would like to use that for debugging.

http://en.wikipedia.org/wiki/Eval#Lua

Obviously, this should never be used in production.

[xoft]

archshift, that's only usable in Lua plugins, but not for C++ functions that are not exported to Lua API.

[wudles]

Has any of this work been rolled into general production? I don't see any of these classes and I'm looking at making mobs find paths to safety, villagers and players for interaction.

[LogicParrot]

No, it has not. I had to stop development. I plan to resume in March / April.
The related Github issue is here: https://github.com/mc-server/MCServer/issues/1391

There's little code yet, though.