131b67c38a
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.
183 KiB
183 KiB