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
I believe we are getting data corruption by doing it in the middle of the tick, as I was seeing
really odd reports from automated ones vs command ones.
This will break issueing timings over rcon single command mode and getting the report link in the response back
But I will try to restore that (and make RCON no longer cause spikes) soon.
Reports will still generate, just because its async, the RCON connection
will drop if not in terminal mode before its done.
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.
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.
The Component based methods are not even safe to use, as it may result in invalid items being sent to the client.
The string based method we have added is the only safe way to send with the API.
The client is stricter about componenents being sent for this API, and does not accept children components.
The client is expecting a legacy string.
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.
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.
Require user to confirm the timings reset, warning them that they should not be doing this.
Also require Timings to have ran for 3 minutes before allowing the report command.
Also require 1 minute intervals between reports to stop report spam.
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.
Aikar