+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Mob status (/thread-1895.html)
RE: Mob status - LogicParrot - 05-29-2015
@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.
(05-29-2015, 01:37 AM)worktycho Wrote: 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
RE: Mob status - worktycho - 05-29-2015
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.
RE: Mob status - LogicParrot - 05-29-2015
(05-29-2015, 02:26 AM)worktycho Wrote: 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?
RE: Mob status - LogicParrot - 05-29-2015
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*.
RE: Mob status - worktycho - 05-29-2015
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.
RE: Mob status - jan64 - 05-29-2015
Per player pathfinding would be nice, but a dumb path finding code should be available too (for plugin devs, and other future uses).
RE: Mob status - LogicParrot - 05-29-2015
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.
RE: Mob status - Jammet - 05-29-2015
^^ That wasn't me -- I understand nothing of this process, but it sure sounds like magic to me, if you know the quote.
RE: Mob status - LogicParrot - 05-29-2015
Meant jan
RE: Mob status - xoft - 05-29-2015
Yeah, I didn't crunch the numbers when I wrote that, I was just brainstorming out loud