Adds /paper command for reloading the paper config.
Closes GH-639
Per-world config logging has been removed in favor of all or nothing
logging for all paper settings. I don't believe it was used enough to
warrant maintaining. If this is not the case it should be possible to
re-add it.
Also add "commands" to Tab Completion
Note: This required a signature change to Bukkit#reloadCommandAliases() so that it returns a boolean based on if the command aliases reloaded or not.
Someone wrote some horrible code that throws a world accessing task
onto the HTTP DOWNLOADER Thread Pool, for an activity that is not even
heavy enough to warrant async operation.
This then triggers async chunk loads!
What in the hell were you thinking?
I have not once ever seen this system help debug a crash.
One report of a suspected memory leak with the system.
This adds additional overhead to asynchronous task dispatching
Finally made timings accept "Callback style" reports, so plugins
can listen for when the report is done.
Added new Util interfaces, MessageCommandSender and BufferedCommandSender
This restores and improves using RCON to generate timings reports
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.
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.
Many protection plugins would unintentionally trigger chunk loads
by calling .getToBlock() on an unloaded chunk, killing performance.
Simply skip the event call. as CraftBukkit blocks changing the block
of unloaded chunks anyways.
This keeps behavior consistent, vs inconsistent flowing based on plugin triggered loads.
Fires when an Entity decides to start moving to a location.
This is not the same as a move event. This only fires when an entity chooses
to start moving to a location, and allows cancelling that pathfind.
Additionally, only get is supported for now. Unsure if changing target location
is safe to do.
Vanilla stores how long a chunk has been active on a server, and dynamically scales some
aspects of vanilla gameplay to this factor.
For people who want all chunks to be treated equally, you can disable the timer.
These events will give plugins a reliable way to track every entity that is added
or removed from a world, so that one may always ensure they are in a desired state.
Not sure of any reason a plugin would need to act on a Physics event
for redstone. There is a BlockRedstoneEvent that plugins can also use
for accessing redstone activity.
Defaulting this to false will provide substantial performance improvement
by saving millions of event calls on redstone heavy servers.
The lighting queue spreads out the processing of light updates across
multiple ticks based on how much free time the server has left at the end
of the tick.
getting a loaded chunk is one of the most hottest pieces of code in the game.
Often, getChunkAt is called for the same chunk multiple times in a row, often
from getType();
Optimize this look up by using a Last Access cache.
should be fully working now as I pretty much fell back to existing
methods so anything touching the unloadQueue set should behave correctly.
And maintained NMS Reflection safe change too
While the previous logic was logically correct, some CB API's before
would request a chunk without removing it from the unload queue.
While this is logically wrong, some plugins seem to be causing unload issues.
This change will make anything using that one API that use to not remove from
queue, no longer remove from queue.
Hopefully other activities on the server will touch the chunk if it REALLY is in use.
Use an optimized method to test if a block position meets a desired light level.
This method benefits from returning as soon as the desired light level matches.
Also Optimize Grass more
Mojang included some sanity checks on arguments passed to the BlockData.
This code results in the Hash look up occuring twice per call, one to test if it exists
and another to retrieve the result.
This code should ideally never be hit, unless mojang released a bad build. We can discover bugs with this as furthur code that never expects a null
would then NPE, so it would not result in hidden issues.
This is super hot code, so removing those checks should give decent gains.
Removing chunks from the unload queue when performing chunk lookups is a costly activity.
It drastically slows down server performance as many methods call getChunkAt, resulting in a bandaid
to skip removing chunks from the unload queue.
This patch optimizes the unload queue to instead use a boolean on the Chunk object itself to mark
if the chunk is active, and then insert into a LinkedList queue.
The benefits here is that all chunk unload queue actions are now O(1) constant time.
A LinkedList will never need to resize, and can be removed from in constant time when
used in a queue like method.
We mark the chunk as active in many places that notify it is still being used, so that
when the chunk unload queue reaches that chunk, and sees the chunk became active again,
it will skip it and move to next.
First, Enchantment order would blow away seeing 2 items as the same,
however the Client forces enchantment list in a certain order, as well
as does the /enchant command. Anvils can insert it into forced order,
causing 2 same items to be considered different.
This change makes unhandled NBT Tags and Enchantments use a sorted tree map,
so they will always be in a consistent order.
Additionally, the old enchantment API was never updated when ItemMeta
was added, resulting in 2 different ways to modify an items enchantments.
For consistency, the old API methods now forward to use the
ItemMeta API equivalents, and should deprecate the old API's.
If the server lags out and skips multiple ticks, Furnace cooking behavior would not
cook in the expected amount of time as the cook time was not decremented correctly.
This patch ensures that furnaces cook to the correct wall time expectation.
Metadata is not meant to persist reload as things break badly with non primitive types
This will invalidate metadata on reload so it does not crash everything if a plugin uses it.
Under previous behavior, plugins were not able to check if a player had a permission
if it was defined in permissions.yml. there is no clean way for a plugin to fix that either.
This will change the order so that by default, permissions.yml loads BEFORE plugins instead of after.
This gives plugins expected permission checks.
It also helps improve the expected logic, as servers should set the initial defaults, and then let plugins
modify that. Under the previous logic, plugins were unable (cleanly) override permissions.yml.
A config option has been added for those who depend on the previous behavior, but I don't expect that.
Sometimes a chunk region file is closed prematurely, resulting in a "Stream Closed" error on chunk saving.
Ultimately there is a race condition that causes it, but re-trying the save will avoid the issue.
Retry the save 5 times to try our best to avoid rollbacks due to chunk save failures.
Entities collision is checking for scoreboards setting.
This is very heavy to do map lookups for every collision to check
this setting.
So avoid looking up scoreboards and short circuit to the "not on a team"
logic which is most likely to be true.
I don't know what the person who wrote that code was smoking, but I
don't think it was good.
Gets rid of the WeakHashMap that mojang was abusing purely to be lazy
on clean up, and handles registering and deregistering navigation
upon world add/remove operations.
People are able to abuse the way Bukkit handles teleportation across worlds since it provides a built in teleportation safety check.
To abuse the safety check, players are required to get into a location deemed unsafe by Bukkit e.g. be within a chest or door block. While they are in this block, they accept a teleport request from a player within a different world. Once the player teleports, Minecraft will recursively search upwards for a safe location, this could eventually land within a player's skybase.
Example setup to perform the glitch: http://puu.sh/ng3PC/cf072dcbdb.png
The wanted destination was on top of the emerald block however the player ended on top of the diamond block. This only is the case if the player is teleporting between worlds.
