05-08-2015, 10:32 PM
It'd be great if anyone can have some benchmarks:
Have lots of chickens, compare Master to LowTicks to Vanilla.
Have lots of chickens, compare Master to LowTicks to Vanilla.
PathFinder status
|
05-08-2015, 10:32 PM
It'd be great if anyone can have some benchmarks:
Have lots of chickens, compare Master to LowTicks to Vanilla.
05-08-2015, 10:33 PM
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.
05-08-2015, 11:00 PM
(This post was last modified: 05-08-2015, 11:02 PM by LogicParrot.)
(05-08-2015, 10:33 PM)xoft Wrote: It all depends on the AI. The vanilla AI mostly does this in a loop: 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.
Mobs are not ticked if they are far away from a player, just as a point of information.
05-09-2015, 03:13 AM
05-09-2015, 11:14 PM
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.
Thanks given by: tonibm19
05-09-2015, 11:33 PM
That would require rewriting most of the mob code, as there is a lot of implicit assumptions about ticking
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.
05-24-2015, 01:35 AM
(This post was last modified: 05-24-2015, 02:16 AM by LogicParrot.)
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. Thanks given by: Jammet
05-24-2015, 02:41 AM
(05-24-2015, 01:35 AM)Safwat Wrote: Jammet: I'll check it out. 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. |
« Next Oldest | Next Newest »
|