no obviousy bugs caused by this at the moment, but we may need to clean up process to be like
how I use to have it before vanilla did it, and we shouldn't leave this boolean in an invalid state.
While I can't think of any reason to do this except some REALLY weird workflow, I still added a config
to let you save them incase someone runs into issues.
Use at your own risk, we will not waste our time with support
if your server times out and you cant put 2+2 together to
figure out that its because you killed the watchdoge
Provides an API to control the loot table for an object.
Also provides a feature that any Lootable Inventory (Chests in Structures)
can automatically replenish after a given time.
This feature is good for long term worlds so that newer players
do not suffer with "Every chest has been looted"
API and Event added to control the Auto Replenish feature for players.
Maps used a modified version of rendering to support plugin controlled
imaging on maps. The Craft Map Renderer is much slower than Vanilla,
causing maps in item frames to cause a noticeable hit on server performance.
This updates the map system to not use the Craft system if we detect that no
custom renderers are in use, defaulting to the much simpler Vanilla system.
Additionally, numerous issues to player position tracking on maps has been fixed.
The Player View Distance patch has been screwing with the configured world view distance.
The world a player was created in would set the players view distance, which would be locked to that distance.
Then switching worlds would not give you an updated view distance.
This then caused issues with what view distance the player should have in the chunk map and did not send chunks to the client correctly during movement.
This patch has now been changed to use a -1 default for "default" and will not override view distance until someone has actually used the API to change it.
Allowing only non-zero BlockIterators breaks an API contract explicitly allowing them
(*eyeroll*)
And loading chunks earlier in the TP patch did not resolve the original issue, and now
that it is resolved, shouldn't actually provide any tangible benefits
By default, this logic would loop endlessly trying to fill the world
with entities until it hits the worlds spawn.
This patch will cap the # of attempts to so that the tick does not spend
extra long time on mob spawning
If a plugin hacks into NMS and triggers entity removal, it could
result in an entity being attempted to remove from the chunk twice.
The 2nd pass will return false, as it did not find the entity in the list.
We should not touch entity counts if the entity was not removed, to avoid
going negative.
Spigot drastically altered vanilla mob spawn logic and caused a few issues.
1) Used only spawnable chunks vs entire world for entity counting, resulting in ignoring
other entities in the world, and causing the world to go over its intended limit.
Specially with servers using smaller mob spawn ranges than view distance, as well as affects spawning API
2) Spigot was using 16x16 division instead of vanilla 17x17 division.
Issues got worse in 1.9 due to more chunks being loaded due to 1.9 changes, that fall out
of the monster spawn radius.
This patch returns mob counting to use all loaded chunks, and 17x17 division.
Previous fix for SPIGOT-1903 only applied to world changes, but many other
cases of players been teleporting can cause that same bug. So call it any time
setPosition is called to ensure we never falsely trigger "moved too quickly"
And this commit may be considered evil to some people.
Speaking with Amaranth, his point of his implementation was that most
of the lookups are on loaded chunks, so that code is optimized for that case.
While Long2Object should be faster as a general purpose map,
for MC uses, Amaranth's version should be faster. Will try to benchmark
the 2 at some future.
Should only happen for blocks on the edge that uses neighbors light level
(certain blocks). In that case, there will be 3-4 other neighbors to get a light level from.
Pathfinder objects are storing references to ChunkCache's, and never cleaning up.
These ChunkCache's then leak other entity objects. Those entity objects then have leaks to their
own chunk cache. A recursive problem....
Clean up the ChunkCache reference after it is done being used.
