When players are moving in the world, doing things such as building or exploring,
they will commonly go back and forth in a small area. This causes a ton of chunk load
and unload activity on the edge chunks of their view distance.
A simple back and forth movement in 6 blocks could spam a chunk to thrash a
loading and unload cycle over and over again.
This is very wasteful. This system introduces a delay of inactivity on a chunk
before it actually unloads, which is maintained separately from ChunkGC.
This allows servers with smaller worlds who do less long distance exploring to stop
wasting cpu cycles on saving/unloading/reloading chunks repeatedly.
Workaround for GH-189
Relocation breaks the lookup of a resource bundle, and this is easier than forking and maintaining our own version
AFAIK this should be fine to do. Guess we'll see
I misread the code and thought the code kept looping until the mob spawn cap was hit.
Upon furthur review, this is not true, so this patch doesn't do anything sane.
Behavior may be buggy or otherwise broken, testing with the option is needed.
`fix-cannons` has been removed in favor of `enable-old-tnt-cannon-behaviors`
Use -1 to represent vanilla/unlimited.
Updated PaperWorldConfig to also update the individual worlds limit if it was set
to the new default value.
Should hopefully help #235
Because Techable keeps complaining about how this isn't thread safe,
easier to do this than replace the entire thing.
Additionally, move Saving of the User cache to be done async, incase
the user never changed the default setting for Spigot's save on stop only.
may help #284
Cleans up the lighting queue system, reducing diff and improving implementation.
We no longer stop chunk unloads due to lighting updates, and instead simply flush the lighting queue.
The cost of forcing the chunk (and its neighbors!) to stay loaded waiting for its
lighting work to finish is much greater than simply taking the hit and doing the work.
This change also helps reduce the diff and avoid bugs with missed diffs by removing
duplicated logic.
Also switches to a more effecient data structure (ArrayDeque instead of LinkedList) for the queue itself.
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.
