Upstream/Paper
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2024-11-05 10:20:53 +01:00
Code Issues Projects Releases Wiki Activity
61a6d011d9
Paper/Spigot-Server-Patches/0338-Restore-custom-InventoryHolder-support.patch

47 lines
2.0 KiB
Diff
Raw Normal View History

Update upstream & fix some chunk related issues (#2177) * Updated Upstream (Bukkit/CraftBukkit) Upstream has released updates that appears 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: 45690fe9 SPIGOT-5047: Correct slot types for 1.14 inventories CraftBukkit Changes: 4090d01f SPIGOT-5047: Correct slot types for 1.14 inventories e8c08362 SPIGOT-5046: World#getLoadedChunks returning inaccessible cached chunks. d445af3b SPIGOT-5067: Add item meta for 1.14 spawn eggs * Bring Chunk load checks in-line with spigot As of the last upstream merge spigot now checks ticket level status when returning loaded chunks for a world from api. Now our checks will respect that decision. * Fix spawn ticket levels Vanilla would keep the inner chunks of spawn available for ticking, however my changes made all chunks non-ticking. Resolve by changing ticket levels for spawn chunks inside the border to respect this behavior. * Make World#getChunkIfLoadedImmediately return only entity ticking chunks Mojang appears to be using chunks with level > 33 (non-ticking chunks) as cached chunks and not actually loaded chunks. * Bring all loaded checks in line with spigot Loaded chunks must be at least border chunks, or level <= 33
2019-06-14 04:27:40 +02:00
From d184b27d1561696d6e5e307a58bb3953158007da Mon Sep 17 00:00:00 2001
Restore custom InventoryHolder support Upstream removed the ability to consistently use a custom InventoryHolder, However, the implementation does not use an InventoryHolder in any form outside of custom inventories. We can take that knowledge and apply some expected behavior, if we're given an inventory holder, we should use it and return a custom inventory with the holder, otherwise, create an inventory backed by the intended inventory, as per upstream behavior. This provides a "best of both worlds" scenario: plugins with InventoryHolder's will always work as intended in the past, those without will create implementation based inventories.
2018-11-05 05:57:31 +01:00
From: Shane Freeder <theboyetronic@gmail.com>
Date: Mon, 5 Nov 2018 04:23:51 +0000
Subject: [PATCH] Restore custom InventoryHolder support
Upstream removed the ability to consistently use a custom InventoryHolder,
However, the implementation does not use an InventoryHolder in any form
outside of custom inventories.
We can take that knowledge and apply some expected behavior, if we're given
an inventory holder, we should use it and return a custom inventory with the
holder, otherwise, create an inventory backed by the intended inventory, as
per upstream behavior.
This provides a "best of both worlds" scenario: plugins with InventoryHolder's
will always work as intended in the past, those without will create implementation
based inventories.
diff --git a/src/main/java/org/bukkit/craftbukkit/inventory/util/CraftInventoryCreator.java b/src/main/java/org/bukkit/craftbukkit/inventory/util/CraftInventoryCreator.java
Updated Upstream (CraftBukkit) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing CraftBukkit Changes: 17543ecf SPIGOT-5035: Error Using Virtual Merchant GUI 0fc6922b SPIGOT-5028: Villager#setVillagerExperience() doesn't work bdbdbe44 SPIGOT-5024: Fox error - Unknown target reason
2019-06-06 17:36:57 +02:00
index 9957ed0402..ae280dd40b 100644
Restore custom InventoryHolder support Upstream removed the ability to consistently use a custom InventoryHolder, However, the implementation does not use an InventoryHolder in any form outside of custom inventories. We can take that knowledge and apply some expected behavior, if we're given an inventory holder, we should use it and return a custom inventory with the holder, otherwise, create an inventory backed by the intended inventory, as per upstream behavior. This provides a "best of both worlds" scenario: plugins with InventoryHolder's will always work as intended in the past, those without will create implementation based inventories.
2018-11-05 05:57:31 +01:00
--- a/src/main/java/org/bukkit/craftbukkit/inventory/util/CraftInventoryCreator.java
+++ b/src/main/java/org/bukkit/craftbukkit/inventory/util/CraftInventoryCreator.java
more 1.14 stuffs yay!
2019-05-05 13:12:32 +02:00
@@ -39,10 +39,20 @@ public final class CraftInventoryCreator {
Restore custom InventoryHolder support Upstream removed the ability to consistently use a custom InventoryHolder, However, the implementation does not use an InventoryHolder in any form outside of custom inventories. We can take that knowledge and apply some expected behavior, if we're given an inventory holder, we should use it and return a custom inventory with the holder, otherwise, create an inventory backed by the intended inventory, as per upstream behavior. This provides a "best of both worlds" scenario: plugins with InventoryHolder's will always work as intended in the past, those without will create implementation based inventories.
2018-11-05 05:57:31 +01:00
}
public Inventory createInventory(InventoryHolder holder, InventoryType type) {
+ // Paper start
+ if (holder != null) {
+ return DEFAULT_CONVERTER.createInventory(holder, type);
+ }
+ //noinspection ConstantConditions // Paper end
return converterMap.get(type).createInventory(holder, type);
}
public Inventory createInventory(InventoryHolder holder, InventoryType type, String title) {
+ // Paper start
+ if (holder != null) {
+ return DEFAULT_CONVERTER.createInventory(holder, type, title);
+ }
+ //noinspection ConstantConditions // Paper end
return converterMap.get(type).createInventory(holder, type, title);
}
--
Correct patches
2019-05-05 13:32:20 +02:00
2.21.0
Restore custom InventoryHolder support Upstream removed the ability to consistently use a custom InventoryHolder, However, the implementation does not use an InventoryHolder in any form outside of custom inventories. We can take that knowledge and apply some expected behavior, if we're given an inventory holder, we should use it and return a custom inventory with the holder, otherwise, create an inventory backed by the intended inventory, as per upstream behavior. This provides a "best of both worlds" scenario: plugins with InventoryHolder's will always work as intended in the past, those without will create implementation based inventories.
2018-11-05 05:57:31 +01:00
Reference in New Issue Copy Permalink