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.
Added code that refreshes the player's skin by sending packets with a special order, telling the client to respawn the player and re-apply the game profile
Added code that refreshes the player's skin by sending packets with a special order, telling the client to respawn the player and re-apply the game profile
The removal of `ServerConnection.this.h.add(networkmanager);` got
lost in the 1.13 update, causing network managers to be registered
twice.
Fixes "handleDisconnection() called twice" warning spam in console.
Some of the fields in the anonymous class are named the same as the
surrounding method's parameters, which caused the fields to be
initialized incorrectly.
That way it keeps returning the same block position, resulting
in an infinite loop during chunk generation.
* master:
Don't process despawn if entity is in a chunk scheduled for unload
Fix Squids corrupting the entire servers entity randomness....
Fix placement of chunk tracking - Fixes#1199
This won't happen anyways if the user has
"skip ticking for entities in chunks scheduled for unload" turned on,
but if they don't, protect from this instant killing the entity to
keep it vanilla in behavior
a player may teleport away, and trigger instant despawn
Spigot had code that returned early in chunk add/remove methods.
This was causing our code added to set current chunks and counts to
be skipped over if the entity was default not persistent but made persistent.
This was the source of many issues
Fixes#1208
When interacting with entities with an item, the client will assume
the interaction is successful, and update the held item on the
client. However, if the interaction is cancelled on the server side,
the client will still mistakenly remove/replace the item in hand.
Examples for this are milking cows with a bucket or dyeing sheep.
The bucket is replaced with milk and the dye removed from inventory.
Refresh the player inventory when PlayerInteractEntityEvent is
cancelled to avoid this problem.
The adjacent blocks of doors, double plants, pistons and beds need
to be updated manually from the server when cancelling a block break
from a player, as it otherwise causes the other parts to disappear
on the client.
This is already done for doors but only for the BlockBreakEvent,
not for PlayerInteractEvent. Move the code to a common method
and also handle the other blocks in similar ways.
The extra buffer used to decode the strings sent by the client
in the legacy ping protocol was never released. However, creating
an extra copy of the buffer just to decode it to a string isn't
actually necessary: We can just call toString() directly on the
original buffer.
Additionally, free the buffer in handlerRemoved() to handle cases
where the client never sends enough bytes to form a valid legacy
ping request.
Closes#1197
While this really undoes a lot of the desired performance gains avoiding chunk lookups,
we sadly have to accept this because we are seeing lots of bugs with entities.
Allows you to increase how far to check for a safe place to respawn
a player near their bed, allowing a better chance to respawn the
player at their bed should it of became obstructed.
Defaults to vanilla 1.
In many places where we simply want the current chunk the entity
is in, instead of doing a hashmap lookup for it, we now have access
to the object directly on the Entity/TileEntity object we can directly grab.
Use that local value instead to reduce lookups in many hot places.
This enables us a fast reference to the entities current chunk instead
of having to look it up by hashmap lookups.
We also store counts by type to further enable other performance optimizations in later patches.
This is the best way to get an entity when the world and its UUID are known.
It is faster than Server.getEntity(UUID) because it does not have to iterate all worlds
This fixes a CRITICAL missing part of the Bukkit API due to mistakes on upstream
refusing to implement the Sentient NPC baseclass of all NPC's.
Until now, the Bukkit API has not provided a way for accessing and setting
a non creature entities target.
Although Flying, Slime, Ambient, and Water mobs all supported targets internally,
you were unable to get/set it.
Now with the SentientNPC API and these API's moved down, every sentient NPC has
access to target data.
This only impacted people who used our useSnapshots new API in a plugin,
which obviously was no one as the data result was completely broken.
Merged the NPE check patch into mine since it has to handle it too.
This event is called when an entity receives knockback by another entity. The knockback can be modified in the event. If the event is cancelled the entity is not knocked back.
Also renames patch file to better express what it's doing.
It is presumed that those using this config option intend for
suffocation checks to be disabled in all instances. In doing so, they
inherently assume the advantages and issues associated with removing
said safety check.
If the community expresses a desire for more specific options regarding
the handling of this safety feature, we can investigate providing them.
Fixes GH-1149
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.
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 :)
hashCodes are not allowed to change, however bukkit used a value
that does change, the entityId.
When an entity is teleported dimensions, the entity reference is
replaced with a new one with a new entity ID.
For hashCode, we can simply use the UUID's hashCode to keep
the hashCode from changing.
equals() is ok to use getEntityId() because equals() should only
be true if both the left and right are the same reference.
Since entity ids can not duplicate during runtime, this
check is essentially the same as this.getHandle() == other.getHandle()
However, replaced it too to make it clearer of intent.
To teleport an entity between dimensions, the server makes a copy
and puts the copy in the new location, and marks the old one dead.
If this method got called for the same world in the same tick,
the entity would not have been removed from the UUID map, and the
world readd would fail.
This can be triggered even with a plugin if the entity is teleported
twice in the same tick, from world A to B, then back from B to A.
The re-add to A will fail to add the entity to the world. It will
actually be there, but it will not be visible on the client until
the server is restarted to re-try the add to world process again.
This bug was unlikely to be seen by many due to the double teleport
requirement, but plugins (such as my own) use this method to
trigger a "reload" of the entity on the client.
This improves plugins like Citizens that rely on direct instance of Yggdrasil implementations.
Instead of wrapping, directly extend and override the methods.
Went ahead and wrapped all of the services in prep in the base patch, then features modify what they need
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.
This adds a new Builder API which is much friendlier to use.
Players are able to use alt accounts and enderpearls to travel
long distances utilizing the pearls in unloaded chunks and loading
the chunk later when convenient.
This disables that by not saving the thrower when the chunk is unloaded.
This is mainly useful for survival servers that do not allow freeform teleporting.
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.
Resolves#1101
reporter of this issue was incorrect and did not verify vanilla logic
vanilla logic only skips ticks if the flag is set
spigots change causes bugs as it now skips ticking and processing
chunk teleportation, which was a bug I fixed many many years ago...
Prior to this change the server would crash when attempting to load a
chunk from a region with bad data.
After this change the server will defer back to vanilla behavior. At
this time, that means attempting to generate a chunk in its place
(and occasionally just not generating anything and leaving small
holes in the world).
Should Mojang choose to alter this behavior in the future, this change
will simply defer to whatever that new behavior is.
It is often difficult to diagnose new issues server admins get when
upgrading to a new server version because the only information they are
able to tell us regarding the server version they are running is
"latest". This commit attempts to mitigate this by keeping track of the
previous version of Paper they were running, which is then reported by
the `/version` or `/paper version` command. This gives us a better idea
of the commits included in the upgrade, which may help diagnose new
issues easier.
This change by spigot ensures that many interactins with chunks,
e.g. getting a list of TEs will cause the chunk to be marked for not
unloading and will block their unload. This is especially true for
servers using Timings (it needs to access the TE list of chunks), or
any plugins which need to access entity/TE lists periodically.
At the time this was re-added, there was concern around how the JIT
would handle the system property that enabled it.
This shouldn't be a problem, and as such we no longer need to block
access to it.
The Vanilla Method Profiler will not provide much to most users however
there is no harm in providing it as an option. For most users, the
recommended and supported method for determining performance issues with
Paper will continue to be Timings.
In some enviroments, the channel limit set by spigot can cause issues,
e.g. servers which allow and support the usage of mod packs.
provide an optional flag to disable this check, at your own risk.
* Make the legacy ping handler more reliable
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
* Add legacy ping support to PaperServerListPingEvent
Add a new method to StatusClient check if the client is a legacy
client that does not support all of the features provided in the
event.
