Limit a single entity to colliding a max of configurable times per tick.
This will alleviate issues where living entities are hoarded in 1x1 pens
This is not tied to the maxEntityCramming rule. Cramming will still apply
just as it does in Vanilla, but entity pushing logic will be capped.
You can set this to 0 to disable collisions.
Spigot rebrought this back after it was removed for years due to the performance hit.
It is unknown if the JIT will optimize it out as effeciently with how it was
added, so we do not want any risk of performance degredation.
Paper has a proper Timings system that makes the Vanilla Method profiler obsolete and inferior.
We have long been receiving feedback about our warning messages when
excessive velocities are set on entities. We have, for the most part,
ignored much of this feedback because these warnings can be vital in
identifying the cause of a watchdog crash. These crashes would otherwise
be more difficult to identify without this information.
However, in many cases these warnings are unnecessarily verbose as the
server handles these excessive sets itself without user intervention.
As a compromise, we will only warn the user as part of a watchdog crash
log, and we will only include the most recent occurrence. This commit
represents a first effort on this front. It may need to be tweaked later
to provide more relevant information, such as the time it occurred,
and/or not printing the warning at all if the occurrence was a certain
time period ago.
The client is improperly sending Item Name Packets to the server BEFORE
the click event. This causes the server to reset before the click event is processed
This breaks the ability to rename more than 1 item at a time.
See: https://bugs.mojang.com/browse/MC-111699
Spigot did not copy our version, and their version is not 100% correct.
The current state results in item meta and damage data value conversions clashing for control
For example on a horse egg, on itemstack creation, the 100 Damage is converted to 0 and sets EntityTag
SetItemMeta then drops the previous NBTTagCompound and makes a new one, which has no EntityType associated
to it as the previous stack had no metadata.
This change makes it so that itemstack conversion is delayed until after meta applies
Pretty much restores our previous implementation before Spigot tried to resolve it.
player.getVehicle() was returning null during the event. Paper had added lots of code to
cause the player to remount the entity on cancel.
I've simplified the diff and made player.getVehicle() work during the event by setting the
vehicle back during the event, and only set it to null if the event is not cancelled.
Take same approach we did for chunks, and only save player if its been X time since last save,
instead of doing it all in 1 tick.
This is even more helpful considering Player Saving is done sync for File IO.
per: 01cf3186bd (commitcomment-20268968)
The break may of been skipping attempts at valid chunks. I thought break was the right abort, but maybe it is not.
Missed diff from old patch file was causing lava to always move at the
faster 'nether' speed, ignoring the slower overworld speed entirely.
This is why we use obfuscation helpers now.
Fixes GH-521
Every call to .isEmpty() made a horribly wasteful map lookup just to get the
reference to the Air Item for checking.
We will now cache a copy of that item
Allow configuring for cartographers to return the same map location
Also allow turning off treasure maps all together as they can eat up Map ID's
which are limited in quantity.
Make it so a Treasure Map does not target a structure outside of the
World Border, where players are not even able to reach.
This also would help the case where a players close to the border, and one
that is outside happens to be closer, but unreachable, yet another reachable
one is in border that would of been missed.
Ultimately they should be unnecessary now that upstream's fix has been
in place for a while. Removing this reduces our own footprint, and gets
rid of any possible unintended behavior.
The default limit is possible to hit with 50 page books with color codes, causing clients to disconnect.
Bump the limit up a hair to above currently seen sizes.
ItemMeta apply is a destructive process that expects to be the authority on
what the items NBT data is.
When CraftItemStack.asNMSCopy was called, the conversion ran, potentially setting
the converted data into the ItemStacks tag.
Then if that item had ItemMeta, it would completely undo that conversion by
erasing the NBT Tag.
On copy, run conversion post ItemMeta apply.
Makes Auto Save Rate setting configurable per-world. If the auto save rate is left -1, the global bukkit.yml value will be used.
Process auto save every tick instead of once per auto tick interval, so that chunk saves will distribute over many ticks instead of all at once.
Re-introduce a cap per tick for auto save (Spigot disabled the vanilla cap) and make it configurable.
More appropriately aligns ourself with the no team option, because the
collideRule team is only a team because it has to be, not because we want
anyone to have any sort of gameplay based relationship.
Also block any options from being set on this team to further enforce that
it is not a persistent team and should not be treated as such.
Servers behind a bungeecord proxy in offline mode
will now properly pull offline mode UUIDs and data
when this setting is set to false. Default is unchanged.
While the option remains a powerful tool we recommend everyone use, 30s is
proving to be a bit much for certain gametypes and many admins are confused
that after updating they are now facing extreme loaded chunk counts.
We do recommend experienced users configure this value as needed, but we
cannot keep it as a default option given the variety of gametypes, the
potential inexperience of new users, and previous users upgrading and
now facing extreme chunk counts that offer little benefit.
1) Sign loading code was trying to parse the JSON before the check for oldSign.
That code could then skip the old sign converting code if it triggers a JSON parse exception.
2) New Mojang Schematic system has Tile Entities in the new converted format, but missing the Bukkit.isConverted flag
This causes Igloos and such to render broken signs. We fix this by ignoring sign conversion for Defined Structures
Vanilla will double add Spider Jockeys to the world, so ignore already added.
Also add debug if something else tries to, and abort before world gets bad state
Some pretty micro optimizations, but this is the hottest method in the server....
This will drastically reduce number of operations to perform getType
the 2 previous patches was squashed into 1
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.
