Mob status

[LogicParrot]

@xoft: The "field data" would become stale once the mob moves a bit. So, essentially, whenever the mob picks a single place to go to, it has to throw away the field and calculate a new one. That essentially takes us back to the current implementation.

---

The problem is that you need ~800KB of information per mob.

800KB per mob? What? Who? How?

---

Perhaps the main interface problem is that the PathFinder is a "dumb machine" which knows nothing except spitting out the Path from A to B. This leaves the management stuff to Monster.cpp. One option would be creating a PathFinder wrapper which offloads the Pathfinding logic from Monster.cpp

[worktycho]

48 * 48 * 48 * 4 = ~800,000. I think a PathFinder wrapper would be the way to go if we find we need more options than just give me the path from a to b.

[LogicParrot]

48 * 48 * 48 * 4 = ~800,000. I think a PathFinder wrapper would be the way to go if we find we need more options than just give me the path from a to b.

We do have a more sophisticated logic, but it's ugly tight coupling right inside monster.cpp.

What's the 48 and the 4?

[LogicParrot]

I figured out your numbers.

A naive implementation would indeed reach this. But a well-written Dijkstra/Astar is much more efficient, because it won't scan the whole area, it will only scan walkable areas. So, for a 1x1x1 chicken on a plane, only the ground plane will be scanned, that would be 48 * 48 * 4 = 9216. A typical mob is bigger than 1x1x1 and the world isn't always a plane, so I'd roughly estimate that the memory demand is 48 * 48 * 4 * x where x is somewhere between 1 and 5.

Note, that the idea of a reversed Dijkstra (a field around each player) would mean that memory is consumed per *player* and not per *mob*.

[worktycho]

It goes up to 36K, because you need to store the coordinates the cost is associated with. Thats less than 800K, but still a considerable amount of memory per mob, but I agree that per player, it would be a good thing to have.

[jan64]

Per player pathfinding would be nice, but a dumb path finding code should be available too (for plugin devs, and other future uses).

[LogicParrot]

I don't think it's really needed though (per player Path field). There isn't a significant performance issue, and JPS should boost performance if it's ever needed.
I think we just need a wrapper around cPath to remove some responsibilities from cMonster.
@jan64: Agreed, cPath should still be available on its own.

[Jammet]

^^ That wasn't me -- I understand nothing of this process, but it sure sounds like magic to me, if you know the quote.

[LogicParrot]

Meant jan

[xoft]

Yeah, I didn't crunch the numbers when I wrote that, I was just brainstorming out loud