core
/
testserver
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
testserver/Spigot-Server-Patches/0305-Allow-chests-to-be-pla...

35 lines
1.6 KiB
Diff
Raw Normal View History

Move version command update checking to the implementation This makes it easier for downstream projects (forks) to replace the version fetching system with their own. It is as simple as implementing an interface and overriding the default implementation of org.bukkit.UnsafeValues#getVersionFetcher() It also makes it easier for us to organize things like the version history feature. Lastly I have updated the paper implementation to check against the site API rather than against jenkins.
2019-05-27 09:13:41 +00:00
From 93f8bc143c52867231425ae8a296a420305d5c4c Mon Sep 17 00:00:00 2001
Allow chests to be placed with NBT (#1425) This restores vanilla behavior of allowing placed chests to retain any Block Entity Tag data. Upstream added filtering to chests, breaking vanilla behavior, and preventing use of loot table chests as a reward mechanism. Upon review, we can find no security risk in allowing players to place a chest with NBT data, as Spawn Eggs, Minecarts, command blocks etc all have their own checks. Additionally, survival mode players, non op players can not create these items anyways. If a player has Creative or Op, they already have high levels of access. Plus, Chests aren't the only inventory that could have free form items, so this filter was insufficient anyways.
2018-09-09 16:53:23 +00:00
From: BillyGalbreath <Blake.Galbreath@GMail.com>
Date: Sat, 8 Sep 2018 18:43:31 -0500
Subject: [PATCH] Allow chests to be placed with NBT data
Fix cancelled lootables (#1510)
2018-09-30 01:57:59 +00:00
diff --git a/src/main/java/net/minecraft/server/ItemStack.java b/src/main/java/net/minecraft/server/ItemStack.java
Move version command update checking to the implementation This makes it easier for downstream projects (forks) to replace the version fetching system with their own. It is as simple as implementing an interface and overriding the default implementation of org.bukkit.UnsafeValues#getVersionFetcher() It also makes it easier for us to organize things like the version history feature. Lastly I have updated the paper implementation to check against the site API rather than against jenkins.
2019-05-27 09:13:41 +00:00
index 2d83c9e79..dec589463 100644
Fix cancelled lootables (#1510)
2018-09-30 01:57:59 +00:00
--- a/src/main/java/net/minecraft/server/ItemStack.java
+++ b/src/main/java/net/minecraft/server/ItemStack.java
More patches for 1.14
2019-05-05 08:33:44 +00:00
@@ -235,6 +235,7 @@ public final class ItemStack {
Fix cancelled lootables (#1510)
2018-09-30 01:57:59 +00:00
enuminteractionresult = EnumInteractionResult.FAIL; // cancel placement
// PAIL: Remove this when MC-99075 fixed
placeEvent.getPlayer().updateInventory();
Improve Cancelled Block Place Tile Entity discardment We bandaided this logic on a case by case basis before with Loot Tables and Chests, but that is not the correct fix. Ultimately we just needed to clear out the captured tile entity list so that the update calls did not process the tile entity that is no longer even valid. This solution will ensure ALL placed tile entities data is ignored and not just the few cases we previously had filters for.
2019-04-06 14:23:05 +00:00
+ world.capturedTileEntities.clear(); // Paper - clear out tile entities as chests and such will pop loot
Fix cancelled lootables (#1510)
2018-09-30 01:57:59 +00:00
// revert back all captured blocks
for (BlockState blockstate : blocks) {
blockstate.update(true, false);
Allow chests to be placed with NBT (#1425) This restores vanilla behavior of allowing placed chests to retain any Block Entity Tag data. Upstream added filtering to chests, breaking vanilla behavior, and preventing use of loot table chests as a reward mechanism. Upon review, we can find no security risk in allowing players to place a chest with NBT data, as Spawn Eggs, Minecarts, command blocks etc all have their own checks. Additionally, survival mode players, non op players can not create these items anyways. If a player has Creative or Op, they already have high levels of access. Plus, Chests aren't the only inventory that could have free form items, so this filter was insufficient anyways.
2018-09-09 16:53:23 +00:00
diff --git a/src/main/java/net/minecraft/server/TileEntityChest.java b/src/main/java/net/minecraft/server/TileEntityChest.java
Move version command update checking to the implementation This makes it easier for downstream projects (forks) to replace the version fetching system with their own. It is as simple as implementing an interface and overriding the default implementation of org.bukkit.UnsafeValues#getVersionFetcher() It also makes it easier for us to organize things like the version history feature. Lastly I have updated the paper implementation to check against the site API rather than against jenkins.
2019-05-27 09:13:41 +00:00
index 85b450c05..efc153de5 100644
Allow chests to be placed with NBT (#1425) This restores vanilla behavior of allowing placed chests to retain any Block Entity Tag data. Upstream added filtering to chests, breaking vanilla behavior, and preventing use of loot table chests as a reward mechanism. Upon review, we can find no security risk in allowing players to place a chest with NBT data, as Spawn Eggs, Minecarts, command blocks etc all have their own checks. Additionally, survival mode players, non op players can not create these items anyways. If a player has Creative or Op, they already have high levels of access. Plus, Chests aren't the only inventory that could have free form items, so this filter was insufficient anyways.
2018-09-09 16:53:23 +00:00
--- a/src/main/java/net/minecraft/server/TileEntityChest.java
+++ b/src/main/java/net/minecraft/server/TileEntityChest.java
Check property exists before playing chest close sound There is an artificial delay added to chest close sounds (of 10 ticks) to make them "feel" more true to vanilla. The problem is that because of this delay it is possible for the block to be removed by the time the sound plays. With 1.14 in the state it is the timing necessary to encounter this issue has increased. The correct fix is to just return early if the property checked for in the TileEntityChest sound method does not exist for the block at the current location. Fixes GH-2074
2019-05-27 04:36:37 +00:00
@@ -309,7 +309,7 @@ public class TileEntityChest extends TileEntityLootable { // Paper - Remove ITic
Allow chests to be placed with NBT (#1425) This restores vanilla behavior of allowing placed chests to retain any Block Entity Tag data. Upstream added filtering to chests, breaking vanilla behavior, and preventing use of loot table chests as a reward mechanism. Upon review, we can find no security risk in allowing players to place a chest with NBT data, as Spawn Eggs, Minecarts, command blocks etc all have their own checks. Additionally, survival mode players, non op players can not create these items anyways. If a player has Creative or Op, they already have high levels of access. Plus, Chests aren't the only inventory that could have free form items, so this filter was insufficient anyways.
2018-09-09 16:53:23 +00:00
// CraftBukkit start
@Override
public boolean isFilteredNBT() {
- return true;
+ return false; // Paper
}
// CraftBukkit end
}
--
Correct patches
2019-05-05 11:32:20 +00:00
2.21.0
Allow chests to be placed with NBT (#1425) This restores vanilla behavior of allowing placed chests to retain any Block Entity Tag data. Upstream added filtering to chests, breaking vanilla behavior, and preventing use of loot table chests as a reward mechanism. Upon review, we can find no security risk in allowing players to place a chest with NBT data, as Spawn Eggs, Minecarts, command blocks etc all have their own checks. Additionally, survival mode players, non op players can not create these items anyways. If a player has Creative or Op, they already have high levels of access. Plus, Chests aren't the only inventory that could have free form items, so this filter was insufficient anyways.
2018-09-09 16:53:23 +00:00