PathFinder status
It'd be great if anyone can have some benchmarks:
Have lots of chickens, compare Master to LowTicks to Vanilla.
Reply
Thanks given by:
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.
Reply
Thanks given by:
(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.
Reply
Thanks given by:
Mobs are not ticked if they are far away from a player, just as a point of information.
Reply
Thanks given by:
(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.
Reply
Thanks given by:
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.
Reply
Thanks given by:
That would require rewriting most of the mob code, as there is a lot of implicit assumptions about ticking
Reply
Thanks given by:
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.
Reply
Thanks given by:
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.
Reply
Thanks given by:
(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.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)