Adds an option for maximum exp value when merging orbs
Adds ExperienceOrbMergeEvent
Fired when the server is about to merge 2 experience orbs
as entities. Plugins can cancel it if they want to ensure experience orbs do not lose important
metadata such as spawn reason, or conditionally move data from source to target.
Fixes an issue where the stacked count was not taking into account
for mending repairs and when merging with spigot's merge-on-spawn
logic
== AT ==
public net.minecraft.world.entity.ExperienceOrb count
Co-authored-by: Aikar <aikar@aikar.co>
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
== AT ==
public net.minecraft.world.entity.ai.gossip.GossipContainer$EntityGossips
public net.minecraft.world.entity.ai.gossip.GossipContainer$EntityGossips <init>()V
public net.minecraft.world.entity.ai.gossip.GossipContainer gossips
This notably fixes the newest "Donkey Dupe", but also fixes a lot
of dupe bugs in general around nether portals and entity world transfer
We also fix item duplication generically by anytime we clone an item
to drop it on the ground, destroy the source item.
This avoid an itemstack ever existing twice in the world state pre
clean up stage.
So even if something NEW comes up, it would be impossible to drop the
same item twice because the source was destroyed.
If the playerdata contains an invalid world (missing, unloaded, invalid,
etc.), spawn the player at the spawn point of the main world.
Co-authored-by: Wyatt Childers <wchilders@nearce.com>
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
For years, plugin developers have had to delay many things they do
inside of the PlayerJoinEvent by 1 tick to make it actually work.
This all boiled down to 1 reason why: The event fired before the
player was fully ready and joined to the world!
Additionally, if that player logged out on a vehicle, the event
fired before the vehicle was even loaded, so that plugins had no
access to the vehicle during this event either.
This change finally fixes this issue, fully preparing the player
into the world as a fully ready entity, vehicle included.
There should be no plugins that break because of this change, but might
improve consistency with other plugins instead.
For example, if 2 plugins listens to this event, and the first one
teleported the player in the event, then the 2nd plugin actually
would be getting a valid player!
This was very non deterministic. This change will ensure every plugin
receives a deterministic result, and should no longer require 1 tick
delays anymore.
== AT ==
public net.minecraft.server.level.ChunkMap addEntity(Lnet/minecraft/world/entity/Entity;)V
Will not run if:
Max entity cramming is disabled and the max collisions per entity is less than or equal to 0.
Entity#isPushable() returns false, meaning all entities will not be able to collide with this
entity anyways.
The entity's current team collision rule causes them to NEVER collide.
Co-authored-by: Owen1212055 <23108066+Owen1212055@users.noreply.github.com>
Fastutil maps are going to have a lower memory footprint - which
is important because we clone chunk data after reading it for safety.
So, reduce the impact of the clone on GC.
This can cause a nasty server lag the spawn chunks are not kept loaded
or they aren't finished loading yet, or if the world spawn radius is
larger than the keep loaded range.
By skipping this, we avoid potential for a large spike on server start.
== AT ==
public net.minecraft.server.level.ServerPlayer fudgeSpawnLocation(Lnet/minecraft/server/level/ServerLevel;)V
This adds config options for defining the spawn chance, spawn delay and
spawn start day as well as toggles for handling the spawn delay and
start day per player. (Based on the time played statistic)
When not per player it will use the Vanilla mechanic of one delay per
world and the world age for the start day.
Removing the try catch and generally reducing ops should make it
faster on its own, however removing the try catch makes it
easier to inline due to code size
This allows you to solve an issue in vanilla behavior where:
* On easy difficulty your villagers will NEVER get infected, meaning they will always die.
* On normal difficulty they will have a 50% of getting infected or dying.
This patch adds a tool to find calls to getChunkAt which would load
chunks, however it must be enabled by setting the startup flag
-Dpaper.debug-sync-loads=true
- To get a debug log for sync loads, the command is
/paper syncloadinfo
- To clear clear the currently stored sync load info, use
/paper syncloadinfo clear
Adds bool parameter to play world effect on block break
Adds bool parameter to drop xp from blocks
Fixes fluid-logged blocks not leaving fluid behind if
broken
Handles special cases for ice and turtle eggs
== AT ==
public net.minecraft.world.level.block.TurtleEggBlock decreaseEggs(Lnet/minecraft/world/level/Level;Lnet/minecraft/core/BlockPos;Lnet/minecraft/world/level/block/state/BlockState;)V
Co-authored-by: William Blake Galbreath <Blake.Galbreath@GMail.com>
Item entities only have their gravity ticked every 4 ticks when on ground.
Fix that and also remove Spigot's arbitrary tick skipping. It's a terribly
cheap way of getting extra performance that doesn't really work at all.
Hoppers call this to I guess "get the primary side" of a double sided chest.
If the double sided chest crosses chunk lines, it causes the chunk to load.
This will end up causing sync chunk loads, which will unload with Chunk GC,
only to be reloaded again the next tick.
This of course is undesirable, so just return the loaded side as "primary"
and treat it as a single chest if the other sides are unloaded
Due to a bug in 2e29af3df0
which was added all the way back in March of 2016, it was unknown (potentially not at the time)
that an entity might actually change the seed of the random object.
At some point, EntitySquid did start setting the seed. Due to this shared random, this caused
every entity to use a Random object with a predictable seed.
This has caused entities to potentially generate with the same UUID....
Over the years, servers have had entities disappear, but no sign of trouble
because CraftBukkit removed the log lines indicating that something was wrong.
We have fixed the root issue causing duplicate UUID's, however we now have chunk
files full of entities that have the same UUID as another entity!
When these chunks load, the 2nd entity will not be added to the world correctly.
If that chunk loads in a different order in the future, then it will reverse and the
missing one is now the one added to the world and not the other. This results in very
inconsistent entity behavior.
This change allows you to recover any duplicate entity by generating a new UUID for it.
This also lets you delete them instead if you don't want to risk having new entities added to
the world that you previously did not see.
But for those who are ok with leaving this inconsistent behavior, you may use WARN or NOTHING options.
It is recommended you regenerate the entities, as these were legit entities, and deserve your love.
This patch adds an option "disable relative projectile velocity", which, when
enabled, will cause projectiles to ignore the shooter's current velocity,
like they did in Minecraft 1.8 and prior.
If a player is falling, for example, their shooting range will be drastically
reduced, as a downwards velocity is applied to the projectile. This prevents
players from saving themselves from falling off floating islands, for example,
as a thrown ender pearl will not make it back to the island, while it would
have in 1.8.
While this could easily be done with plugins, too, there are multiple problems:
P1) If multiple plugins cancel the velocity by subtracting the shooter's velocity
from the projectile's velocity, the projectile's velocity would be different.
As there's no way to detect whether the projectile's velocity has already been
adjusted to ignore the player's velocity, plugins can't not do it if it's not
necessary.
P2) I've noticed some inconsistencies, e.g. weird velocity when shooting while
using an elytra. Checking for those inconsistencies is possible, but not as
efficient as just not applying the velocity in the first place.
P3) Solutions for 1) and especially 2) might not be future-proof, while this
server-internal fix makes this change future-proof.
This resolves the super common complaint about mobs not spawning.
This was ultimately a flaw in the vanilla count algorithim that allows
spawners and other misc mobs to count against the mob limit, which are
not bounded, and can prevent the entire world from spawning new.
I believe Bukkits changes around persistence may of actually made it
worse than vanilla.
This should fully solve all of the issues around it so that only natural
influences natural spawns.
== AT ==
public net.minecraft.world.level.BaseSpawner isNearPlayer(Lnet/minecraft/world/level/Level;Lnet/minecraft/core/BlockPos;)Z
public net.minecraft.world.level.BaseSpawner delay(Lnet/minecraft/world/level/Level;Lnet/minecraft/core/BlockPos;)V
public net.minecraft.world.level.BaseSpawner setNextSpawnData(Lnet/minecraft/world/level/Level;Lnet/minecraft/core/BlockPos;Lnet/minecraft/world/level/SpawnData;)V
upstream was doing a containsKey/get pattern, and always doing it at that.
that scenario is only even valid if were in the middle of a block place.
Optimize to check if the captured list even has values in it, and also to
just do a get call since the value can never be null.
Expose an entities spawn reason on the entity.
Pre existing entities will return NATURAL if it was a non
persistenting Living Entity, SPAWNER for spawners,
or DEFAULT since data was not stored.
Additionally, add missing spawn reasons.
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
Co-authored-by: Doc <nachito94@msn.com>
modified clients can send more data from the client
to the server and it would get stored on the sign as sent.
Mojang has a limit of 384 which is much higher than reasonable.
the client can barely render around 16 characters as-is, but formatting
codes can get it to be more than 16 actual length.
Set a limit of 80 which should give an average of 16 characters 2
sets of legacy formatting codes which should be plenty for all uses.
This does not strip any existing data from the NBT as plugins
may use this for storing data out of the rendered area.
it only impacts data sent from the client.
Set -DPaper.maxSignLength=XX to change limit or -1 to disable
Adds AsyncPlayerSendCommandsEvent
- Allows modifying on a per command basis what command data they see.
Adds CommandRegisteredEvent
- Allows manipulating the CommandNode to add more children/metadata for the client
This adds a custom pool inorder to make sure that they are closed
without much though, as it doesn't matter if the client is not sent
commands if the server is restarting. Using the default async pool caused issues to arise
due to the shutdown logic generally being much later.
Adds an event for when the server is going to destroy a current block,
potentially causing it to drop. This event can be cancelled to avoid
the block destruction, such as preventing signs from popping when
floating in the air.
This can replace many uses of BlockPhysicsEvent
Currently OfflinePlayer#getLastPlayed could more accurately be described
as "OfflinePlayer#getLastTimeTheirDataWasSaved".
The API doc says it should return the last time the server "witnessed"
the player, whilst also saying it should return the last time they
logged in. The current implementation does neither.
Given this interesting contradiction in the API documentation and the
current defacto implementation, I've elected to deprecate (with no
intent to remove) and replace it with two new methods, clearly named and
documented as to their purpose.
This event is invoked when a player has disconnected. It is guaranteed that,
if the server is in online-mode, that the provided uuid and username have been
validated.
The event is invoked for players who have not yet logged into the world, whereas
PlayerQuitEvent is only invoked on players who have logged into the world.
The event is invoked for players who have already logged into the world,
although whether or not the player exists in the world at the time of
firing is undefined. (That is, whether the plugin can retrieve a Player object
using the event parameters is undefined). However, it is guaranteed that this
event is invoked AFTER PlayerQuitEvent, if the player has already logged into
the world.
This event is guaranteed to never fire unless AsyncPlayerPreLoginEvent has
been called beforehand, and this event may not be called in parallel with
AsyncPlayerPreLoginEvent for the same connection.
Cancelling the AsyncPlayerPreLoginEvent guarantees the corresponding
PlayerConnectionCloseEvent is never called.
The event may be invoked asynchronously or synchronously. As it stands,
it is never invoked asynchronously. However, plugins should check
Event#isAsynchronous to be future-proof.
On purpose, the deprecated PlayerPreLoginEvent event is left out of the
API spec for this event. Plugins should not be using that event, and
how PlayerPreLoginEvent interacts with PlayerConnectionCloseEvent
is undefined.
== AT ==
public net.minecraft.server.network.ServerLoginPacketListenerImpl$State
public net.minecraft.server.network.ServerLoginPacketListenerImpl state
Entities must be dismounted before teleportation in order to avoid
multiple issues in the server with regards to teleportation, shamefully,
too many plugins rely on the events firing, which means that not firing
these events caues more issues than it solves;
In order to counteract this, Entity dismount/exit vehicle events have
been modified to supress cancellation (and has a method to allow plugins
to check if this has been set), noting that cancellation will be silently
surpressed given that plugins are not expecting this event to not be cancellable.
This is a far from ideal scenario, however: given the current state of this
event and other alternatives causing issues elsewhere, I believe that
this is going to be the best soultion all around.
Improvements/suggestions welcome!
Splits time updates into incremental updates as well as does
the updates per world, so that we can re-use the same packet
object for every player unless they have per-player time enabled.
Use a simple executor since Fork join is a much more complex pool
type and we are not using its capabilities.
Set thread priorities so main thread has above normal priority over
server threads
Allow usage of a single thread executor by not using ForkJoin so single core CPU's
and reduce worldgen thread worker count for low core count CPUs.
== AT ==
public net.minecraft.Util onThreadException(Ljava/lang/Thread;Ljava/lang/Throwable;)V
Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
Use a proper teleport for teleporting to entities in different
worlds.
Implementation improvements authored by Spottedleaf <Spottedleaf@users.noreply.github.com>
Validate that the target entity is valid and deny spectate
requests from frozen players.
Also, make sure the entity is spawned to the client before
sending the camera packet. If the entity isn't spawned clientside
when it receives the camera packet, then the client will not
spectate the target entity.
Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
== AT ==
public net.minecraft.world.entity.animal.Turtle getHomePos()Lnet/minecraft/core/BlockPos;
public net.minecraft.world.entity.animal.Turtle setHasEgg(Z)V
public net.minecraft.world.entity.animal.Turtle isGoingHome()Z
public net.minecraft.world.entity.animal.Turtle setGoingHome(Z)V
public net.minecraft.world.entity.animal.Turtle isTravelling()Z
public net.minecraft.world.entity.animal.Turtle setTravelling(Z)V
This adds a separate event before an entity is spawned by a spawner
which contains the location of the spawner too similarly to how the
SpawnerSpawnEvent gets called instead of the CreatureSpawnEvent for
spawners.
Fixed an issue where a furnace's cook-speed multiplier rounds down
to the nearest Integer when updating its current cook time.
== AT ==
public net.minecraft.world.level.block.entity.AbstractFurnaceBlockEntity getTotalCookTime(Lnet/minecraft/server/level/ServerLevel;Lnet/minecraft/world/level/block/entity/AbstractFurnaceBlockEntity;)I
Co-authored-by: Eric Su <ericsu@alumni.usc.edu>
Implements Pathfinding API for mobs
== AT ==
public net.minecraft.world.entity.ai.navigation.PathNavigation pathFinder
public net.minecraft.world.level.pathfinder.PathFinder nodeEvaluator
public net.minecraft.world.level.pathfinder.Path nodes
This adds the ability to cancel the death events and to modify the sound
an entity makes when dying. (In cases were no sound should it will be
called with shouldPlaySound set to false allowing unsilencing of silent
entities)
It makes handling of entity deaths a lot nicer as you no longer need
to listen on the damage event and calculate if the entity dies yourself
to cancel the death which has the benefit of also receiving the dropped
items and experience which is otherwise only properly possible by using
internal code.
== AT ==
public net.minecraft.world.entity.LivingEntity getDeathSound()Lnet/minecraft/sounds/SoundEvent;
public net.minecraft.world.entity.LivingEntity getSoundVolume()F
This is specifically aimed at fixing #471
Using a ConcurrentHashMap because thread safety
The performance benefit of Map over ConcurrentMap is negligabe at best in this scenaio, as most operations will be get and not add or remove
Even without considering the use-case the benefits are still negligable
Original ideas for the system included an expiration policy and/or handler
The simpler solution was to use a computeIfPresent in the get method
This will simultaneously have an O(1) lookup time and automatically expire any values
Since the get method (nor other similar methods) don't seem to have a critical need to flush the map to disk at any of these points further processing is simply wasteful
Meaning the original function expired values unrelated to the current value without actually having any explicit need to
The h method was heavily modified to be much more efficient in its processing
Also instead of being called on every get, it's now called just before a save
This will eliminate stale values being flushed to disk
Modified isEmpty to use the isEmpty() method instead of the slightly confusing size() < 1
The point of this is readability, but does have a side-benefit of a small microptimization
Detect when the server has been hung for a long duration, and start printing
thread dumps at an interval until the point of crash.
This will help diagnose what was going on in that time before the crash.
Addresses two issues:
- MC-135506: Experience should save as Integers
- Allay duplication cooldown is saved and exposed as a long, but loaded as an int
Due to the changes in 1.13, clients will send a tab completion request
for all bukkit commands in order to factor in the lack of support for
brigadier and provide backwards support in the API.
Craftbukkit, however; has moved the chat spam limiter to also interact
with the tab completion request, which while good for avoiding abuse,
causes 1.13 clients to easilly be kicked from a server in bukkit due
to this. Removing the spam limit could cause issues for servers, however,
there is no way for servers to manipulate this without blindly cancelling
kick events, which only causes additional complications. This also causes
issues in that the tab spam limit and chat share the same field but different
limits, meaning that a player having typed a long command may be kicked from
the server.
Splitting the field up and making it configurable allows for server owners
to take the burden of this into their own hand without having to rely on
plugins doing unsafe things.
Normally the JVM can inline virtual getters by having two sets of code, one is the 'optimized' code and the other is the 'deoptimized' code.
If a single type is used 99% of the time, then its worth it to inline, and to revert to 'deoptimized' the 1% of the time we encounter other types.
But if two types are encountered commonly, then the JVM can't inline them both, and the call overhead remains.
This scenario also occurs with BlockPos and MutableBlockPos.
The variables in BlockPos are final, so MutableBlockPos can't modify them.
MutableBlockPos fixes this by adding custom mutable variables, and overriding the getters to access them.
This approach with utility methods that operate on MutableBlockPos and BlockPos.
Specific examples are BlockPosition.up(), and World.isValidLocation().
It makes these simple methods much slower than they need to be.
This should result in an across the board speedup in anything that accesses blocks or does logic with positions.
This is based upon conclusions drawn from inspecting the assenmbly generated bythe JIT compiler on my microbenchmarks.
They had 'callq' (invoke) instead of 'mov' (get from memory) instructions.
Add Entity as a Source capability, and add more API choices, and on Location.
Co-authored-by: Esoteric Enderman <90862990+EsotericEnderman@users.noreply.github.com>
Co-authored-by: Bjarne Koll <git@lynxplay.dev>
Called when a player is firing a bow and the server is choosing an arrow to use.
Plugins can skip selection of certain arrows and control which is used.
Adds missing call to Illagers and also adds Arrow ItemStack to skeletons
== AT ==
public net.minecraft.world.entity.projectile.AbstractArrow getPickupItem()Lnet.minecraft.world.item.ItemStack;
Rewrites the Vanilla luck application formula so that luck can be
applied to items that do not have any quality defined.
See: https://luckformula.emc.gs for data and details
-----------
The rough summary is:
My goal was that in a pool, when luck was applied, the pool
rebalances so the percentages for bigger items is
lowered and smaller items is boosted.
Do this by boosting and then reducing the weight value,
so that larger numbers are penalized more than smaller numbers.
resulting in a larger reduction of entries for more common
items than the reduction on small weights,
giving smaller weights more of a chance
-----------
This work kind of obsoletes quality, but quality would be useful
for 2 items with same weight that you want luck to impact
in varying directions.
Fishing still falls into that as the weights are closer, so luck
will invalidate junk more.
This change will result in some major changes to fishing formulas.
-----------
I would love to see this change in Vanilla, so Mojang please pull :)
Adds ability to control who receives it and who is the source/sender (vanish API)
the standard API is to send the packet to everyone in the world, which is ineffecient.
Adds an option to control the force mode of the particle.
This adds a new Builder API which is much friendlier to use.
Fires an event anytime an enderman intends to teleport away from the player
You may cancel this, enabling ranged attacks to damage the enderman for example.
The Minecraft server often fails to respond to old ("legacy") pings
from old Minecraft versions using the protocol used before the switch
to Netty in Minecraft 1.7.
Due to packet fragmentation[1], we might not have all needed bytes
available when the LegacyPingHandler is called. In this case, it will
run into an error, remove the handler and continue using the modern
protocol.
This is unlikely to happen for the first two revisions of the legacy
ping protocol (used in Minecraft 1.5.x and older) since the request
consists of only one or two bytes, but happens frequently for the
last/third revision introduced in Minecraft 1.6.
It has much larger, variable packet sizes due to the inclusion of
the virtual host (the hostname/port used to connect to the server).
The solution[2] is simple: If we find more than two matching bytes,
we buffer the remaining bytes until we have enough to fully read and
respond to the request.
[1]: https://netty.io/wiki/user-guide-for-4.x.html#wiki-h3-11
[2]: https://netty.io/wiki/user-guide-for-4.x.html#wiki-h4-13
This seems completely pointless, as packet dispatch uses .writeAndFlush.
Things seem to work fine without explicit flushing, but incase issues arise,
provide a System property to re-enable it using improved logic of doing the
flushing on the netty event loop, so it won't do the flush on the main thread.
Renable flushing by passing -Dpaper.explicit-flush=true
GUIs are opened on the client, meaning that the server cannot block them from opening,
However, it is possible to close these GUIs from the server.
Flower pots are also not updated on the client when interaction is cancelled, this patch
also resolves this.
Allows plugins to populate profile properties from local sources to avoid calls out to Mojang API
to fill in textures for example.
If Mojang API does need to be hit, event fire so you can get the results.
This is useful for implementing a ProfileCache for Player Skulls
Adds an event to fire before an Entity is created, so that plugins that need to cancel
CreatureSpawnEvent can do so from this event instead.
Cancelling CreatureSpawnEvent rapidly causes a lot of garbage collection and CPU waste
as it's done after the Entity object has been fully created.
Mob Limiting plugins and blanket "ban this type of monster" plugins should use this event
instead and save a lot of server resources.
See: https://github.com/PaperMC/Paper/issues/917
This event can be used for when you want to exclude a certain player
from triggering monster spawns on a server.
Also a highly more effecient way to blanket block spawns in a world
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
Co-authored-by: Aikar <aikar@aikar.co>
This allows you to get a BlockState without creating a snapshot, operating
on the real tile entity.
This is useful for where performance is needed
also Avoid NPE during CraftBlockEntityState load if could not get TE
If Tile Entity was null, correct Sign to return empty lines instead of null
When modifying the world, CB will store a copy of the affected
blocks in order to restore their state in the case that the event
is cancelled. This change only modifies the collection of blocks
in the world by normal means, e.g. not during tree population,
as the potentially marginal overheads would serve no advantage.
CB was using a CraftBlockState for all blocks, which causes issues
should any block that uses information beyond a data ID would suffer
from missing information, e.g. Skulls.
By using CBs CraftBlock#getState(), we will maintain a proper copy of
the blockstate that will be valid for restoration, as opposed to dropping
information on restoration when the event is cancelled.
This patch intends to bump up the time that a client has to reply to the
server back to 30 seconds as per pre 1.12.2, which allowed clients
more than enough time to reply potentially allowing them to be less
tempermental due to lag spikes on the network thread, e.g. that caused
by plugins that are interacting with netty.
We also add a system property to allow people to tweak how long the server
will wait for a reply. There is a compromise here between lower and higher
values, lower values will mean that dead connections can be closed sooner,
whereas higher values will make this less sensitive to issues such as spikes
from networking or during connections flood of chunk packets on slower clients,
at the cost of dead connections being kept open for longer.
In 1.12.2, Mojang moved the processing of ServerboundKeepAlivePacket 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
off the main thread.
also adding some additional logging in order to help work out what is causing
random disconnections for clients.
Disable the 15 second sleep when the server jar hasn't been rebuilt within a period of time.
modified in order to prevent merge conflicts when Spigot changes/disables the warning,
and to provide some level of hint without being disruptive.
Establishes base extension of profile systems for future edits too
== AT ==
public org.bukkit.craftbukkit.profile.CraftProfileProperty
public org.bukkit.craftbukkit.profile.CraftPlayerTextures
public org.bukkit.craftbukkit.profile.CraftPlayerTextures copyFrom(Lorg/bukkit/profile/PlayerTextures;)V
public org.bukkit.craftbukkit.profile.CraftPlayerTextures rebuildPropertyIfDirty()V
public org.bukkit.craftbukkit.profile.CraftPlayerProfile toString(Lcom/mojang/authlib/properties/PropertyMap;)Ljava/lang/String;
public org.bukkit.craftbukkit.profile.CraftPlayerProfile getProperty(Ljava/lang/String;)Lcom/mojang/authlib/properties/Property;
public org.bukkit.craftbukkit.profile.CraftPlayerProfile setProperty(Ljava/lang/String;Lcom/mojang/authlib/properties/Property;)V
They block. On network I/O.
If enough tasks are submitted the server will eventually stall
out due to a sync load, as the worldgen threads will be
stalling on profile lookups.
Makes parrots not fall off whenever the player changes height, or touches water, or gets hit by a passing leaf.
Instead, switches the behavior so that players have to sneak to make the birds leave.
I suspect Mojang may switch to this behavior before full release.
To be converted into a Paper-API event at some point in the future?
== AT ==
public net.minecraft.world.entity.player.Player removeEntitiesOnShoulder()V
The watchdog thread calls the server restart function asynchronously. Prior to
this change, it attempted to do several non-safe operations from the watchdog
thread, rather than the main. Specifically, because of a separate upstream change,
it causes player entities to be ticked asynchronously, among other things.
This is dangerous.
This patch moves the old handling into a synchronous variant, for calls from the
restart command, and adds separate handling for async calls, such as those from
the watchdog thread.
When calling from the watchdog thread, we cannot assume the main thread is in a
tickable state; it may be completely deadlocked. In order to handle this, we mark
the server as stopping, in order to account for situations where the server should
complete a tick reasonbly soon, i.e. 99% of cases.
Should the server not enter a state where it is stopping within 10 seconds, We
will assume that the server has in fact deadlocked and will proceed to force
kill the server.
This modification does not force restart the server should we actually enter a
deadlocked state where the server is stopping, whereas this will in most cases
exit within a reasonable amount of time, to put a fixed limit on a process that
will have plugins and worlds saving to the disk has a high potential to result
in corruption/dataloss.
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.
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.
This prevents Entities from trying to run outside of the World Border
TODO: This doesn't prevent the pathfinder from using blocks outside the world border as nodes. We can fix this
by adding code to all overrides in:
NodeEvaluator:
public abstract BlockPathTypes getBlockPathType(BlockGetter world, int x, int y, int z);
to return BLOCKED if it is outside the world border.
* Only send global sounds to same world if limiting radius
* respect global sound events gamerule
Co-authored-by: Evan McCarthy <evanmccarthy@outlook.com>
Co-authored-by: lexikiq <noellekiq@gmail.com>
Co-authored-by: Aikar <aikar@aikar.co>
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"
== AT ==
public org.bukkit.craftbukkit.block.CraftBlockEntityState getTileEntity()Lnet/minecraft/world/level/block/entity/BlockEntity;
public org.bukkit.craftbukkit.block.CraftLootable setLootTable(Lorg/bukkit/loot/LootTable;J)V
public org.bukkit.craftbukkit.entity.CraftMinecartContainer setLootTable(Lorg/bukkit/loot/LootTable;J)V
For servers with multiple IP's, ability to bind to a specific interface.
== AT ==
public net.minecraft.server.dedicated.Settings getStringRaw(Ljava/lang/String;)Ljava/lang/String;
Remove Debug checks as these are super hot and causing noticeable hits
Before: http://i.imgur.com/nQsMzAE.png
After: http://i.imgur.com/nJ46crB.png
Optimize redundant converting of static fields into an unsigned long each call by precomputing it in ctor
A general purpose patch that includes config options for the tick rate
of a variety of blocks that are random ticked.
Co-authored-by: MrPowerGamerBR <git@mrpowergamerbr.com>
Adds the PlayerUseUnknownEntityEvent to be used by plugins dealing with
virtual entities/entities that are not actually known to the server.
Co-authored-by: Nassim Jahnke <nassim@njahnke.dev>
RegionFileCache prior to this patch would close every single open region
file upon reaching a size of 256.
This patch modifies that behaviour so it closes the the least recently
used RegionFile.
The implementation uses a LinkedHashMap as an LRU cache (modified from HashMap).
The maximum size of the RegionFileCache is also made configurable.
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 chose a fixed value.
This allows to fine-tune vanilla gameplay.
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.
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.
Properly split up the chat and command handling to reflect the server now
having separate packets for both, and the client always using the correct packet. Text
from a chat packet should never be parsed into a command, even if it starts with the `/`
character.
Add a missing async catcher and improve Spigot's async catcher error message.
== AT ==
public net.minecraft.server.network.ServerGamePacketListenerImpl isChatMessageIllegal(Ljava/lang/String;)Z
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
Co-authored-by: SoSeDiK <mrsosedik@gmail.com>
The process of determining an entity's exposure from explosions can be
expensive when there are hundreds or more entities in range.
This patch adds a per-tick cache that is used for storing and retrieving
an entity's exposure during an explosion.
Improves how the catchup buffer is handled, allowing it to roll both ways
increasing the effeciency of the thread sleep so it only will sleep once.
Also increases the buffer of the catchup to ensure server stays at 20 TPS unless extreme conditions
Previous implementation did not calculate TPS correctly.
Switch to a realistic rolling average and factor in std deviation as an extra reporting variable
Removes Spigot's mcstats metrics in favor of a system using bStats
To disable for privacy or other reasons go to the bStats folder in your plugins folder
and edit the config.yml file present there.
Please keep in mind the data collected is anonymous and collection should have no
tangible effect on server performance. The data is used to allow the authors of
PaperMC to track version and platform usage so that we can make better management
decisions on behalf of the project.
Rewrite console improvements (console colors, tab completion,
persistent input line, ...) using JLine 3.x and TerminalConsoleAppender.
Also uses the new ANSIComponentSerializer to serialize components when
logging them via the ComponentLogger, or when sending messages to the
console, for hex color support.
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:
- Server starts 1-2 seconds faster thanks to optimizations in Log4j
configuration
Co-Authored-By: Emilia Kond <emilia@rymiel.space>
== AT ==
public net.minecraft.network.chat.HoverEvent$ItemStackInfo item
public net.minecraft.network.chat.HoverEvent$ItemStackInfo count
public net.minecraft.network.chat.HoverEvent$ItemStackInfo components
public net.minecraft.network.chat.contents.TranslatableContents filterAllowedArguments(Ljava/lang/Object;)Lcom/mojang/serialization/DataResult;
Co-authored-by: zml <zml@stellardrift.ca>
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
== AT ==
public net.minecraft.server.level.ServerChunkCache mainThread
public net.minecraft.server.level.ServerLevel chunkSource
public org.bukkit.craftbukkit.inventory.CraftItemStack handle
public net.minecraft.server.level.ChunkMap getVisibleChunkIfPresent(J)Lnet/minecraft/server/level/ChunkHolder;
public net.minecraft.server.level.ServerChunkCache mainThreadProcessor
public net.minecraft.server.level.ServerChunkCache$MainThreadExecutor
public net.minecraft.world.level.chunk.LevelChunkSection states
== AT ==
public org.spigotmc.SpigotWorldConfig getBoolean(Ljava/lang/String;Z)Z
public org.spigotmc.SpigotWorldConfig getDouble(Ljava/lang/String;)D
public org.spigotmc.SpigotWorldConfig getDouble(Ljava/lang/String;D)D
public org.spigotmc.SpigotWorldConfig getInt(Ljava/lang/String;)I
public org.spigotmc.SpigotWorldConfig getInt(Ljava/lang/String;I)I
public org.spigotmc.SpigotWorldConfig getList(Ljava/lang/String;Ljava/lang/Object;)Ljava/util/List;
public org.spigotmc.SpigotWorldConfig getString(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
public net.minecraft.server.dedicated.DedicatedServerProperties reload(Lnet/minecraft/core/RegistryAccess;Ljava/util/Properties;Ljoptsimple/OptionSet;)Lnet/minecraft/server/dedicated/DedicatedServerProperties;
public net.minecraft.world.level.NaturalSpawner SPAWNING_CATEGORIES
== AT ==
public net.minecraft.server.packs.VanillaPackResourcesBuilder safeGetPath(Ljava/net/URI;)Ljava/nio/file/Path;
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
The size of chunks in the region format is overdetermined. In particular their size on disk is indicated by both a sector count in the header, and actual size in the body.
If their size would overflow the header field (>= 255 sectors), it can just be read directly from the body instead.
This code/concept was adapted from MinecraftForge.
By: md_5 <git@md-5.net>
This patch adds world configuration options for max-tick-time.entity / max-tick-time.tile which allows setting a hard cap on the amount of time (in milliseconds) that a tick can consume. The default values of 50ms each are very conservative and mean this feature will not activate until the server is well below 15tps (minimum). Values of 20ms each have been reported to provide a good performance increase, however I personally think 25ms for entities and 10-15ms for tiles would give even more significant gains, assuming that these things are not a large priority on your server.
For tiles there is very little tradeoff for this option, as tile ticks are based on wall time for most things, however for entities setting this option too low could lead to jerkiness / lag. The gain however is a faster and more responsive server to other actions such as blocks, chat, combat etc.
This feature was commisioned by Chunkr.
By: md_5 <git@md-5.net>
This gives a per-world control on how much TNT will be processed per-tick,
preventing a massive TNT detonation from lagging out the server.
By: Aikar <aikar@aikar.co>
This flag contains the same message as eula.txt (albeit with proper grammar for 3rd person plural). By setting this flag you are agreeing to the terms listed in the message printed upon setting this flag, which are no different from those agreed to by any other method.
This feature only exists for hosting companies and people who manage servers in bulk who wish to agree to the terms by setting a flag in a script.
By: md_5 <git@md-5.net>
Because NetworkManagers are registered before they get their channel in
channelActive, the ServerConnection would remove them sometimes because
it thought they were disconnected. This commit fixes this by introducing
a 'preparing' variable that is true while the NetworkManager is not
initialized. The ServerConnection does not remove NetworkManagers with
this flag.
By: Jonas Konrad <me@yawk.at>
This issue stems from the fact that Bukkit's API only allows a UUID to be banned, but Minecraft requires both a UUID and name. To fix this we modify the code to require a UUID or a name, or both. The correct fix would be expanding the API to be able to provide a name, however this would require plugin changes.
By: md_5 <git@md-5.net>
If we are online mode and the only copy of player data we can find is the player's offline mode data, we will attempt a once off conversion by reading this data and then renaming the file so it won't be used again.
By: md_5 <git@md-5.net>
This brings back the option that the Spigot version of netty saw. By default Netty will try and use cores*2 threads, however if running multiple servers on the same machine, this can be too many threads. Additionally some people have 16 core servers. If 32 Netty threads are allowed in this setup, then the lock contention, and thus blocking between threads becomes much greater, leading to decreased performance.
By: md_5 <git@md-5.net>
This will let you configure how far to track entities in range from players, so that the entity does not render on the client if out of this range.
This has multiple benefits:
1) Less bandwidth. Not sending update packets for entities that are not even close to a player, or even close enough to clearly see.
2) Less lag by maps in item frames - Default range is 160 blocks... Many players can track that item frame and cause lag and not even see it.
3) Less lag in general - Less work for the server to do
4) Less client lag - Not trying to render distant item frames and paintings and entities will reduce entity count on the client, which is major for shop/town worlds which may use tons of item frames.
By: Aikar <aikar@aikar.co>
This feature gives 3 new configurable ranges that if an entity of the matching type is outside of this radius of any player, will tick at 5% of its normal rate.
This will drastically cut down on tick timings for entities that are not in range of a user to actually be "used".
This change can have dramatic impact on gameplay if configured too low. Balance according to your servers desired gameplay.
By: Aikar <aikar@aikar.co>
Changes the mob spawning algorithm to properly account for view distance and the range around players.
Needs better documentation.
By: md_5 <git@md-5.net>
This allows the merging of Experience orbs, as well as the configuration of the merge radius of items. Additionally it refactors the merge algorithm to be a better experience for players.
By: md_5 <git@md-5.net>
