-
Notifications
You must be signed in to change notification settings - Fork 88
Modern Material Enum #344
Comments
would break plugins unfortunately. |
It most likely wouldn’t break plugins, but either way the Material enum in 1.8 depends on block ids, and different types of wood are different data ids for logs |
Wouldn't it break plugins that are using say Material.WOOD and now it has to use the specific ones instead? |
if you want new materials and items, use latest paper :) |
NachoSpigot isn't made to add breaking api changes
|
I like the idea, could just make a secondary material class called ModernMaterial or MMaterial |
it is possible without breaking the plugins as @HeathLoganCampbell said. we can add a new class, where there would be all items already with MaterialData provided public class DarkOakWood extends MaterialData {
public DarkOakWood() {
super(Material.LOG_2, (byte) 1);
} something like that |
I've designed a modern block data system in PacketEvents. It allow stuff like https://github.com/retrooper/packetevents/blob/2.0/api/src/main/java/com/github/retrooper/packetevents/protocol/world/states/WrappedBlockState.java Unsure how relevant this is, but it works on 1.8 and I like it better than 1.8's system. |
Describe the feature
For example Material.SPRUCE_WOOD or Material.DARK_OAK_WOOD ..etc
instead of weird stuff to get the different wood type
Technical implementation
No response
Other
No response
Agreements
The text was updated successfully, but these errors were encountered: