Mob status

[LogicParrot]

I'd like to thank Jammet for getting me a Mojang account

[Jammet]

No problem ^^.

[LogicParrot]

Wolves should be better now.

[Jammet]

The players will love it! And I'm glad because it was a real hassle getting them from A to B recently . Thanks!

[LogicParrot]

I updated the post. I added the Enderman to the list, among other things.

---

The players will love it! And I'm glad because it was a real hassle getting them from A to B recently . Thanks!

You're welcome

[bearbin]

Here's a list of all the aggressive mobs that need to be completed:

http://minecraft.gamepedia.com/Category:Aggressive_mobs

[LogicParrot]

Here's a list of all the aggressive mobs that need to be completed:

http://minecraft.gamepedia.com/Category:Aggressive_mobs

Thanks

[LogicParrot]

Skeleton diagnosis:
The Skeleton is immobile because the mobs' pathfinding will stop when mobs reach their final destination. The function which determines if the mob reached the final destination is cMonster::ReachedFinalDestination, and that function simply returns whether the target in range or not. For melee units, Target in range <=> Reached final destination. But for ranged units, that is not the case. The target may be in range regardless of whether or not the final destination was reached. This causes the skeleton to wrongly believe it reached the final destination, this is why it is immobile.

One easy fix is checking the line of sight inside ReachedFinalDest, but that's sphagetti, and I feel parts the TickPathfinding function is also sphagetti. As a quick fix, I'll make ReachedFinalDestination compare distance to some small constant, and not to the actual mob attack range. On the longer run, I'll rewrite some of cMonster's pathfinding code and clean it.

[xoft]

The more this is discussed, the more I start believing that we've gone the wrong path with pathfinding.

It might have been better to have each mob have an "AStarField" that has a cube of predefined size (mob sight) around the mob with calculated A* cells, and then be able to construct paths out of this field, with questions like "Get path to point B", "Get path to the point nearest to point B", "Get the point nearest to point B that is reachable" etc. It would be much easier to write the mob AI with these methods.
Also, updating the field would be necessary only when the mob moves out of its current block coords, which is very cheap for slow mobs, zero cost for mobs that are currently stationary and still cheap enough even for fast mobs. I don't have any mob speed data, but I'd guess the speed to be less than 4 blocks per second, which would make the maximum recalculation rate some 6 times per second (moving along a diagonal). Given that the field's size is rather small, it should be possible to just update the field in a single step, rather than dividing the work across multiple ticks.
My assumption is that the mob sight is rather limited, some 24 blocks, which means the field would be sized 48 * 48 * 48 blocks, with normal worlds being more on the 2D side of things, so something like N * 48 * 48 ~~ N * 2000 cells to be expanded per recalculation.
We could also have a lazy recalculation - when the first pathfinding request comes, put the field in a "to-update" list, out of which only constant amount of work is done in each tick; the pathfinder would simply return a "NotNow" response. The AI would retry the task on next tick, and only after the field is recalculated, it will receive a positive response and could act accordingly. This could make the server quite robust against entity CPU overload.

[worktycho]

@xoft I can't tell whether you're describing cached Dijkstra's algorithm. It would work so long as you didn't have two many mobs and it was never used for pathfinding beyond a certain distance. The problem is that you need ~800KB of information per mob. If you're just caching the cells that are evaluated, then it would be better to move back to the original, cPathFinder/cPath interface. However I suspect that Safwat's planned reverse Dijkstra player field optimization would be more useful.