Commit graph

2 commits

Author SHA1 Message Date
Aikar 9980f427db
Fix some logic on villager poi max attempts
Hopefully will help #3462
2020-05-28 20:45:36 -04:00
Aikar b0b54e4ef3
Optimize Villager Pathfinding - Massive Villager Improvement
This change reimplements the entire BehaviorFindPosition method to
get rid of all of the streams, and implement the logic in a more sane way.

We keep vanilla behavior 100% the same with this change, just wrote more
optimal, as we can abort iterating POI's as soon as we find a match....

One slight change is that Minecraft adds a random delay before a POI is
attempted again. I've increased the amount of that delay based on the distance
to said POI, so farther POI's will not be attempted as often.

Additionally, we spiral out, so we favor local POI's before we ever favor farther POI's.

We also try to pathfind 1 POI at a time instead of collecting multiple POI's then tossing them
all to the pathfinder, so that once we get a match we can return before even looking at other
POI's.

This benefits us in that ideally, a villager will constantly find the near POI's and
not even try to pathfind to the farther POI. Trying to pathfind to distant POI's is
what causes significant lag.

Other improvements here is to stop spamming the POI manager with empty nullables.
Vanilla used them to represent if they needed to load POI data off disk or not.

Well, we load POI data async on chunk load, so we have it, and we surely do not ever
want to load POI data sync either for unloaded chunks!

So this massively reduces object count in the POI hashmaps, resulting in less hash collions,
and also less memory use.

Additionally, unemployed villagers were using significant time due to major ineffeciency in
the code rebuilding data that is static every single invocation for every POI type...

So we cache that and only rebuild it if professions change, which should be never unless
a plugin manipulates and adds custom professions, which it will handle by rebuilding.
2020-05-27 01:35:36 -04:00