Cuberite Forum
PathFinder status - Printable Version

+- 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: PathFinder status (/thread-1571.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23


RE: PathFinder status - LogicParrot - 05-08-2015

It'd be great if anyone can have some benchmarks:
Have lots of chickens, compare Master to LowTicks to Vanilla.


RE: PathFinder status - xoft - 05-08-2015

It all depends on the AI. The vanilla AI mostly does this in a loop:
1. Stay at the same spot for a while
2. Pick a random spot in vicinity and move there
So when there are more entities, it could just make the time interval in step 1 longer.


RE: PathFinder status - LogicParrot - 05-08-2015

(05-08-2015, 10:33 PM)xoft Wrote: It all depends on the AI. The vanilla AI mostly does this in a loop:
1. Stay at the same spot for a while
2. Pick a random spot in vicinity and move there
So when there are more entities, it could just make the time interval in step 1 longer.

That's exactly what OUR AI does in its current form, so that optimization works here too. We can make step 1 interval proportional to the number of mobs in the area. Also, we can make idle mobs freeze if they don't see a player for a while.

(05-08-2015, 10:33 PM)xoft Wrote: ...it could just make the time interval in step 1 longer.

Added to the optimizations to-do.


RE: PathFinder status - tigerw - 05-09-2015

Mobs are not ticked if they are far away from a player, just as a point of information.


RE: PathFinder status - LogicParrot - 05-09-2015

(05-09-2015, 02:54 AM)tigerw Wrote: Mobs are not ticked if they are far away from a player, just as a point of information.

Oh, then no point in freezing anything.


RE: PathFinder status - NiLSPACE - 05-09-2015

Another option could be to not tick every mob at once if there are allot of mobs. Lets say there are 1000 mobs. MCServer ticks 250 mobs in one tick, in the next tick it does another 250, etc. Or instead of doing nothing with the mobs that are not ticked in the current tick only do the physics.


RE: PathFinder status - worktycho - 05-09-2015

That would require rewriting most of the mob code, as there is a lot of implicit assumptions about ticking


RE: PathFinder status - Jammet - 05-11-2015

Today that I noticed that tamed dogs follow you around at a snails pace, and they do not teleport back to you like they do on a Mojang server, so they get lost all the time if you take them for a walk. They were a lot faster a few weeks ago. Maybe one of the changes made is affecting that behaviour.


RE: PathFinder status - LogicParrot - 05-24-2015

Jammet: I'll check it out.

I am currently trying to implement bounding boxes, and I am getting the impression that the physics engine always assumes the mob width is 1, for instance: Spiders can move in 1-block wide corridors. Creating a spider and breaking the block beneath it makes it fall in a 1 block wide hole. Is my impression correct?

I believe what I stated above is correct. I forced the PathFinder to assume a bounding box width of 1, and all the problems I had with bounding boxes disappeared. Apparently the PathFinder and Physics engine were not in sync and forcing a width of 1 made them work in harmony.

The PathFinder PR I'm going to submit is capable of handling any int bounding box width, but because of the physics engine constraints I'll make the PathFinder assume a mob width of 1.

To be honest, the game is working perfectly fine even with that assumption, so fixing that aspect of the physics engine is low priority, and perhaps it should never be fixed because it needlessly complicates things. The only difference I can see is that spiders can fit in 1-block wide corridors.


RE: PathFinder status - Shadowraix - 05-24-2015

(05-24-2015, 01:35 AM)Safwat Wrote: Jammet: I'll check it out.

I am currently trying to implement bounding boxes, and I am getting the impression that the physics engine always assumes the mob width is 1, for instance: Spiders can move in 1-block wide corridors. Creating a spider and breaking the block beneath it makes it fall in a 1 block wide hole. Is my impression correct?

I believe what I stated above is correct. I forced the PathFinder to assume a bounding box width of 1, and all the problems I had with bounding boxes disappeared. Apparently the PathFinder and Physics engine were not in sync and forcing a width of 1 made them work in harmony.

The PathFinder PR I'm going to submit is capable of handling any int bounding box width, but because of the physics engine constraints I'll make the PathFinder assume a mob width of 1.

To be honest, the game is working perfectly fine even with that assumption, so fixing that aspect of the physics engine is low priority, and perhaps it should never be fixed because it needlessly complicates things. The only difference I can see is that spiders can fit in 1-block wide corridors.

Never be fixed? That would be saddening. Players use every aspect to MC to their advantage. You have no idea how many times the fact that spiders can't fit through 1 block holes has saved my life.