PathFinder status

[LogicParrot]

Thank you all for the valuable info.
I would like to get some feedback regarding my initial header file before actually implementing anything.

https://github.com/wiseoldman95/MCServer...thfinder.h

[SamJBarney]

Hmmmm.... I think its a good start, but I don't think it will allow for a lot of configuration.
For instance, what if we want to make Cobwebs considered passable or unpassable? Or have pathing allow movement underwater or over the top?

What if someone in the future want to make a mob AI that avoid grass if possible, or can climb up vines?

[sphinxc0re]

SamJBarney has his point. Your code is all in all very constant. But MCServer/Cuberite has the feature of being extremely flexible and customizable.

[LogicParrot]

A blacklist parameter can be later added, that parameter can have any block type, such as water, grass, or cobweb.
A "ladder-list" can also be added.

I think that these things are trivial to add once the algorithm is in place.

[jan64]

It'd be nice to have ability to override path finding completely for particular mobs from lua (rideable dragons, for example).

[LogicParrot]

It'd be nice to have ability to override path finding completely for particular mobs from lua (rideable dragons, for example).

As xoft put it, the pathfinder will a "dumb device" which receives two points and spits a path.

AI's are free to use/ not use it.

[LogicParrot]

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.

[xoft]

Not really. It could be done, but there's so much glue code you'd need to write that it wouldn't be worth it. Console commands could be a bit easier - the server implements a few built-in, so if you look at the cServer::ExecuteConsoleCommand() function, you should be able to get something done with it.

[LogicParrot]

Thank you. I would like to know whether the current interface requires any changes.

[xoft]

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?