While BlockType is still marked as internal, it mirrors the already
paper-deprecated method #isInteractable.
The commit marks said method as deprecated if/when BlockType becomes
experimental/non-internal.
The launch API on LivingEntity only respected the WindCharge type, not
its near-clone BreezeWindCharge.
This commit correctly accounts for BreezeWindCharge in
CraftLivingEntity.
The Bukkit#getRegistry(Class) method contract specifies that it returns
null for unknown registry types. The current implementation however
requires the passed class to be mappable to a known registry key.
For types like Material, which have a SimpleRegistry in bukkit's
Registry interface, no server side registry exists and such the type
cannot be mapped to a registry key.
The commit correctly returns null for types that are not mappable to a
registry key instead of throwing a NullPointerException.
Spigot still maintains some partial implementation of "tick skipping", a
practice in which the MinecraftServer.currentTick field is updated not
by an increment of one per actual tick, but instead set to
System.currentTimeMillis() / 50. This behaviour means that the tracked
tick may "skip" a tick value in case a previous tick took more than the
expected 50ms.
To compensate for this in important paths, spigot/craftbukkit
implements "wall-time". Instead of incrementing/decrementing ticks on
block entities/entities by one for each call to their tick() method,
they instead increment/decrement important values, like
an ItemEntity's age or pickupDelay, by the difference of
`currentTick - lastTick`, where `lastTick` is the value of
`currentTick` during the last tick() call.
These "fixes" however do not play nicely with minecraft's simulation
distance as entities/block entities implementing the above behaviour
would "catch up" their values when moving from a non-ticking chunk to a
ticking one as their `lastTick` value remains stuck on the last tick in
a ticking chunk and hence lead to a large "catch up" once ticked again.
Paper completely removes the "tick skipping" behaviour (See patch
"Further-improve-server-tick-loop"), making the above precautions
completely unnecessary, which also rids paper of the previous described
incompatibility with non-ticking chunks.
* Only mark decorations dirty if a removal actually occurs
Vanilla calls this method blindly inside of a loop which erroniously marks
map data files as being dirty even if nothing has actually changed.
* Merge into existing patch
---------
Co-authored-by: Bjarne Koll <lynxplay101@gmail.com>
In the recent upstream update, the paper player profile was updated to
correctly return null for both name and id if constructed as such. This
change however broke the serialisation logic, as it depended on the name
never being null.
The commit moves the checks over to the newly introduced emptyName/UUID
fields that track if the profile was constructed with a null name or
uuid to differentiate it against an empty string or the NIL_UUID.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
1fc1020a PR-1049: Add MenuType API
8ae2e3be PR-1055: Expand riptiding API
cac68bfb SPIGOT-7890: AttributeModifier#getUniqueId() doesn't match the UUID passed to its constructor
7004fcf2 SPIGOT-7886: Fix mistake in AttributeModifier UUID shim
1ac7f950 PR-1054: Add FireworkMeta#hasPower
4cfb565f SPIGOT-7873: Add powered state for skulls
CraftBukkit Changes:
bbb30e7a8 SPIGOT-7894: NPE when sending tile entity update
ba21e9472 SPIGOT-7895: PlayerItemBreakEvent not firing
0fb24bbe0 SPIGOT-7875: Fix PlayerItemConsumeEvent cancellation causing client-side desync
815066449 SPIGOT-7891: Can't remove second ingredient of MerchantRecipe
45c206f2c PR-1458: Add MenuType API
19c8ef9ae SPIGOT-7867: Merchant instanceof AbstractVillager always returns false
4e006d28f PR-1468: Expand riptiding API
bd8aded7d Ignore checks in CraftPlayerProfile for ResolvableProfile used in profile components
8679620b5 SPIGOT-7889: Fix tool component deserialisation without speed and/or correct-for-drops
8d5222691 SPIGOT-7882, PR-1467: Fix conversion of name in Profile Component to empty if it is missing
63f91669a SPIGOT-7887: Remove duplicate ProjectileHitEvent for fireballs
7070de8c8 SPIGOT-7878: Server#getLootTable does not return null on invalid loot table
060ee6cae SPIGOT-7876: Can't kick player or disconnect player in PlayerLoginEvent when checking for cookies
7ccb86cc0 PR-1465: Add FireworkMeta#hasPower
804ad6491 SPIGOT-7873: Add powered state for skulls
f9610cdcb Improve minecart movement
Spigot Changes:
a759b629 Rebuild patches
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
* Item serialization as json
* Add ItemStackAdapter for Gson
* A javadoc note at #serialize() and #deserialize()
* Rebase
* Move serialize closer to deserialize
* Add explaining comment about SERIALIZE_CUSTOM_AS_SNBT usage
* Apply lynxplay requests
* Forgot `@NotNull`
* Very important diff was removed
* Rebase
* Javadocs
---------
Co-authored-by: Bjarne Koll <lynxplay101@gmail.com>
* wip tags
* use generics in tag registrars
* comment out varargs methods for now
* split up patch
* cache loaded service provider
* finish renames
* use builderWithExpectedSize
* finalize
The updated velocity native compilation pipeline seems to emit binaries
that are not compatible with alpine.
The commit temporarily reverts the natives included until a proper
solution is found.
In the case where multiple messages from different players are being processed in parallel, there was a potential race condition where the messages would be sent to the client in a different order than the message signature cache was updated. However, the cache relies on the fact that the client and server get the exact same updates in the same order. This race condition would cause the caches to become corrupted, and any future message received by the client would fail to validate.
This also applies to the last seen state of the server, which becomes inconsistent in the same way as the message signature cache and would cause any messages sent to be rejected by the server too.
