Instead of overriding add within the queue, never add runnables to the
queue if the light queue is disabled.
This change is made to make timings reports and stacktraces less
confusing for administrators, who prior to this change, would have seen
the lighting queue referenced in both, regardless of whether or not it
was enabled.
This change should not affect performance, nor is it made with the
intent to.
This allows plugins that give players the ability to apply the experience
points to the Item Mending formula, which will repair an item instead
of giving the player experience points.
Both an API To standalone mend, and apply mending logic to .giveExp has been added.
Fired when the server is about to merge 2 experience orbs
Plugins can cancel this if they want to ensure experience orbs do not lose important
metadata such as spawn reason, or conditionally move data from source to target.
This ensures that enchants are never added in inconsistent order.
The client shows the enchants in a sorted order already
This will auto fix previously created items too on load.
Spigot, by default, disables several mechanisms around how chunks are
lit, if ever, which has forced them to always send chunks before vanilla
would consider them ready to send, causing for lots of issues around
lighting glitches.
Shamefully, the amount of work to relight chunks can be detremental
to some servers, meaning that forcibily disabling light updates can
cause major performance issues.
as such, we make a compromise; if this "feature" is disabled, we will
only send chunks which are actually ready to be sent, otherwise, we
will always send chunks.
Let plugins be able to control tab completion of commands and chat async.
This will be useful for frameworks like ACF so we can define async safe completion handlers,
and avoid going to main for tab completions.
Especially useful if you need to query a database in order to obtain the results for tab
completion, such as offline players.
Also adds isCommand and getLocation to the sync TabCompleteEvent
In 1.12, Spigot improved their blockstate implementation to take a full
copy of the TE, this allows for a much better snapshot in that it will
actually retain all of the TE's state, it is a much more expensive
implementation. This is also implicated with their backwards compat
for inventories meaning that accessing of a snapshots inventory of a
placed block will actually access the inventory of the live TE, making
creation of a snapshot redundant if the only intent is to interact with
the TEs inventory.
Hoppers are a horrible hit, every attempt to transfer an ItemStack will
result in two TileEntity snapshots, with two hoppers and a double chest
ontop, I managed to log 380 cases per second where a snapshot would have been
taken in cases where the snapshot is redundant.
Prior to this change, if a player was ever set to have a negative view
distance, an attempt to set them back to the default would fail, leading
to them appearing to be stuck in that state.
Now we just interpret that negative value as a "reset" to default.
Thankfully I randomly think about code and randomly wondered if I used <= or < here, and caught this!
This would of missed some chunks for the structure at the highest X/Z
Improves performance by keying every chunk thats part of a structure to a hashmap
instead of only the first one.
This allows us to avoid iterating the entire structures value set to see
if a block position is inside of a structure.
This should have pretty decent performance improvement to any standard world
that has been around for a whilewith lots of structures due to ineffeciencies
in how MC stores structures (even unloaded chunks has structured data loaded)
In some environments, the 2.20.1 version of the maven surefire plugin
can cause builds to fail due to changes in surefire in how it detects
that the forked JVM used for testing is still alive or not.
Entity AI tasks are initialized earlier in recent versions
of MC, this means that the fromMobSpawner has not been set
at the point where AI tasks are initilazed and so the goalFloat
will never be populated.
To rectify this, we can rely on the entity tick checking if
the mob is from a spawner each tick, and just initialize the
field should the paper option be enabled. This saves us from
having to modify the call chain in order to pass the fact that
it was created by a mobSpawner earlier.
HashSet sometimes uses compareTo() instead of equals() and this breaks the comparison of net.minecraft.server.NextTickListEntry (the only place where HashTreeSet is used).
In this cases duplicate entries could be added to the HashSet of HashTreeSet, because NextTickListEntry.compareTo() does not return 0, even if NextTickListEntry.equals() returns true.
ObjectOpenHashSet never uses compareTo(), so the inconsistencies of NextTickListEntry cause no problems.
Fixes https://github.com/PaperMC/Paper/issues/588
Port of 303a775fc3
Will display a list of all entities in a world, as well as which chunks
they are in. Hopefully, this will make tracking down chunks with lots of
entities easier.
Only real change from the forge version is that instead of dimension
IDs, we accept world names in the form of a string.
/paper entity list - Lists all entities in the player's current world
/paper entity list minecraft:zombie - Lists all zombies in the player's
current world
/paper entity list * world_nether - Lists all entities in the nether
/paper entity list minecraft:ghast world_nether - Lists all ghasts in
the nether
This commit removes two patches from spigot:
please review the patch messages for more information, however;
"Allow Disabling of Random Lighting Updates" potentially leaves chunk light maps in an invalid state, with
how often the server looks at these anyways, this patch really serves a questionable nature, the work is
going to be done, only it's being delayed and allowing the light map to be left in a potentially outdated
state.
"Fix some chunks not being sent to the client" sends chunks before their lighting has been calculated, this
means that the client will recieve chunks before they lighting has been calculated which can cause rendering
artifacts. The original issue around this patch appears to have already been fixed years ago.
In 1.12.2, Mojang moved the processing of PacketPlayInKeepAlive off the main
thread, while entirely correct for the server, this causes issues with
plugins which are expecting the PlayerQuitEvent on the main thread.
In order to counteract some bad behavior, we will post handling of the
disconnection to the main thread, but leave the actual processing of the packet
on the main thread.
http://openjdk.java.net/jeps/223
Java decided to change their versioning scheme and in doing so modified the
java.version system property to return $major[.$minor][.$secuity][-ea], as
opposed to 1.$major.0_$identifier we can handle pre-9 by checking if the "major"
is equal to "1", otherwise, 9+
of course, it really wouldn't be all that simple if they didn't add a quirk, now would it.
valid strings for the major may potentially include values such as -ea to deannotate a pre release
Some plugins bypass the plugin logger and add the plugin prefix
manually to the log message. Since they use other logger names
(e.g. qualified class names) these would now also appear in the
log. Disable the logger prefix for these plugins so the messages
show up correctly.
SLF4J is a commonly used abstraction for various logging frameworks
such as java.util.logging (JUL) or Log4j. Currently, plugins are
required to do all their logging using the provided JUL logger.
This is annoying for plugins that target multiple platforms or when
using libraries that log messages using SLF4J.
Expose SLF4J as optional logging API for plugins, so they can use
it without having to shade it in the plugin and going through
several layers of logging abstraction.
Log4j2 provides an optimized implementation of PrintStream that
redirects its output to a logger. Use it instead of a custom
implementation for minor performance improvements and some fixes.
With the old implementation, each call to System.print()
results in a separate line, even though it should not result in
a line break. Log4j's implementation handles it correctly.
Refactored 0229-Fix-this-stupid-bullshit in order to prevent merge conflicts
when spigot decides to update the timer and to provide some form of hint in the
console/log on startup.
FixesPaperMC/Paper#883 same issue as MinecraftForge/MinecraftForge#4386
A more detailed anaylsis of what is probably going on, courtesy of
@bs2609 and the MCForge Issue Tracker is:
When a chunk is unloaded, the entities and tile entities it contains are
marked for removal. The actual removal (from the world) occurs later,
when the world ticks its entities.
Conversely, when a chunk is loaded, it generally adds its entities to
the world promptly, without queuing.
Here's the normal sequence of events:
Chunk unloaded
Old entities removed
Chunk loaded
New entities added
However, what can happen:
Chunk unloaded
Chunk loaded
New entities added
Old entities removed
This occurs when an unloaded chunk is reloaded before its corresponding
entities have been removed.
Fixes falling dragon eggs in lazy chunks fall to the block below the last empty block and replacing that block with them.
See also https://bugs.mojang.com/browse/MC-94186
Spigot is manipulating the Travel Agents canCreatePortal, but forgot to reset it on cancel
This causes nether portals to not be generated if the event is ever cancelled
Gets the Display name as seen in the Client.
Currently the server only supports the English language. To override this,
You must replace the language file embedded in the server jar.
This will take a Bukkit ItemStack and run it through any conversions a server process would perform on it,
to ensure it meets latest minecraft expectations.
Not all horses with Saddles have armor. This lets us break up the horses with saddles
and access their saddle state separately from an interface shared with Armor.
In Java 8u141 (1.8.0_141-b15) and newer, the
com.sun.management.HotSpotDiagnostic::dumpHeap API has changed and now
requires all heap dumps to end with the .hprof file extension.
Before this change, servers running 8u141 would be unable to perform a
heap dump.
For more information, please see the official release notes of Java 8
Update 141, linked below.
http://www.oracle.com/technetwork/java/javase/8u141-relnotes-3720385.html
To dump the server heap, run the following command:
`/paper heap`
This is added with the intent that it is useful for administrators and
developers to more easily identify and resolve memory leaks. Both by examining
these dumps themselves and by more easily allowing them to send them to
knowledgable parties.
This is a nearly line-for-line port of the same Sponge feature. So all
credit for the idea and implementation belongs to the that team.
Specifically the following commits:
be08be04b05e10a1b795
763827668e
Was done incorrectly and is now causing level desyncs to client.
Always send current level to the client, and instead make setWindowProperty set the level.
Messages written to System.out are automatically redirected to the
root logger by CraftBukkit. However, before the messages reach the
logger, they are encoded and later decoded again using the standard
system encoding.
On some systems (e.g. FreeBSD), the standard system encoding is
US-ASCII by default, which doesn't support the section sign (§) that
is used for the color codes. Consequently, they will never reach
the formatter that translates them into ANSI escape codes.
There is no reason to write these messages to System.out - it just
adds additional overhead and the encoding problems. We can just log
the messages directly with the root logger.
Adds a Pre Lookup Event and a Post Lookup Event so that plugins may prefill in profile data, and cache the responses from
profiles that had to be looked up.
There is usually no reason to stop reading from the console, so
preventing console input after EOT can be extremely confusing.
To prevent this, we can simply ignore the exception thrown by
JLine and continue reading normally.
It was originally added in Bukkit/CraftBukkit@6aafe7c5a1 as a
workaround for BUKKIT-4956 to fix console output on Windows.
I believe the original issue was related to LOG4J2-965 and fixed
in apache/logging-log4j2@d04659c. Minecraft 1.12 finally updated
the Log4J version so this issue is no longer present.
Console output is still working fine on Windows after removing this.
Rewrite console improvements (console colors, tab completion,
persistent input line, ...) using JLine 3.x and TerminalConsoleAppender.
New features:
- Support console colors for Vanilla commands
- Add console colors for warnings and errors
- Server can now be turned off safely using CTRL + C. JLine catches
the signal and the implementation shuts down the server cleanly.
- Support console colors and persistent input line when running in
IntelliJ IDEA
Other changes:
- Update JLine to 3.3.1 (from 2.12.1)
- Server starts 1-2 seconds faster thanks to optimizations in Log4j
configuration
When enabled, Parrots will not fly off of a player's shoulder everytime
they change Y level, touch water, sneeze, etc.
Instead, a player must toggle shift to "shake" the parrots off.
CraftBukkit removed their implementation that caused this issue,
switching to Mojang's implementation which doesn't appear to share it. I
already removed the important bit in the last upstream merge, this is
just unused and unnecessary now. So we remove it.
Spigot has patched this issue inside MapIcon, meaning that we no longer need to maintain this patch; Spigots patch also fixes#668 in that it will verify the length of the array, as well as protect against a negative type value being fetched from the array. Only real change is that Spigots patch returns a MapIcon.Type.PLAYER, instead of the RED_MARKER as originally PR'd by Aikar.
Currently, when a player dies they are not automatically ejected from the entity they are riding, which allows
for the ridden entity to affect the players location on respawn (we're still riding it for a part of a tick), as well as allows a dupe to occur with the ridden entity teleporting to the new world with the player
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.
