Minecraft 1.13: What to expect

Discussion in 'News and Announcements' started by md_5, Dec 6, 2017.

Thread Status:
Not open for further replies.
  1. md_5

    Administrator Developer

    Not planned for the initial implementation, Vanilla is very opiniated that these are different blocks.
    It might be possible to eventually add some sort of trait system, maybe in time for release.
    • Like Like x 1
    • Informative Informative x 1
  2. So MaterialData will be removed entirely, or only the byte data concept within? There is a Material.newMaterialData method which I use very frequently for basically anything ever. Its needed to read the direction of signs, to the shape of rails, to the power state of redstone. Removing the byte data for MaterialData is expected, but is it really needed to completely do away with it? Its very well possible to rewrite the MaterialData API to use a mapping like internally used by NMS of key:value pairs instead of a byte.

    If that is in the planning, then I better hurry up to get my own BlockData API up to date to support reading state information like direction from it. It's kind of essential to all my mechanics-based plugins they can read such information.

    Keep up the good work though, this will be a tough one :)

    Oh and if you can use some help, I'm willing to help with the design process of the new block data API. I basically already wrote something for within a library and could help set the foundations. If it's properly implemented in Bukkit then I don't have to rewrite my own mirror of it at least.
  3. Can't wait to see and try 1.13's snapshots/official builds, expecting plugin breakages of which I'm using and maybe it would prevent me updating to 1.13 due to plugins which are dead/unsupported (only allowing 1.13 versions on 1.12)
  4. MiniDigger


    if you know that you use dead plugins which will break with 1.13, you should start to search for replacements right now.
    • Agree Agree x 1
  5. md_5

    Administrator Developer

    The problem is the existing MaterialData (for the like 50% of Materials it covers anyway) doesn't map super well to what Minecraft currently looks like, and is completely built upon the concept of having a byte value - grabbing the byte value from when you are done with it is in many cases the only way to actually use it.

    Given that most plugins will need updating one way or another, I don't particularly see the benefit trying to make it work ontop of the existing (let's face it, broken API). Maybe once the new API is actually implemented it will be easier to see if its practical to do some migration, but really I envisage two operating modes:
    • Plugins using the old API with compatability measures
    • Plugins using only the new API - i.e. no mix and match
    I'm not sure why that's necessary?
    I'll keep that in mind.
  6. At the moment its necessary for various reasons. The list of problems that forced me to write my own BlockData api are:
    • Performance. For Maplands for example, Im iterating millions of blocks when generating the map. I cannot use expensive lookup operations or use temporary Block objects for this kind of thing. Bukkit did two read calls, type and data separately, both doing a chunk lookup. For data its worse, because it also does some data -> legacy Id thing. This can only be addressed if Bukkit adds a function like 'Blockdata World::getData(x, y, z)' which returns an immutable object storing the block's full state. (type + data key/value pairs). The implementation should store the Block/IBlockData as used by the server. It that doesn't exist, I'm forced to create my own mapping anyway.
    • Lacking API methods for opacity, emission, 'suffocates' and many others
    • Lacks common block methods (destroy, step on, etc.).
    • Lacks API methods for reading JSON-serialized 'state' information. (I call them "BlockRenderOptions") This is required for correct rendering in 3D, since the models use these properties to define various switches. (rotation, lit/unlit, fence connected sides, etc)
    • Lacks an interface to the underlying NMS (Bukkit Material has no backing craftbukkit implementation storing the matching IBlockData). This is required to interface with pretty much 100% of the server methods, since the only parameters in use for working with blocks are nms.Block and nms.IBlockData.
    I honestly can't and don't expect even half of these to become implemented within the server. To maintain functionality, which heavily relies on the server and not so much Bukkit, I'm forced to have my own mirror of the BlockData/BlockState api used by Mojang.

    Considering how much trouble it is to add an interface for NBT thats generic enough, there is no way render options will ever make it to Bukkit unfortunately. :(

    Of course the more gets implemented in Bukkit the better. It's less maintenance for me. :p I'd love to see a method that returns type and data in one immutable object, that isn't a performance drain, at the very least. :D
    #67 TeamBergerhealer, Dec 6, 2017
    Last edited: Dec 6, 2017
    • Agree Agree x 1
  7. I am looking forward for some older developers to pop their head up again and say "I am excited to release a new version just for 1.13 and up".
    Hey.. can't blame me for being optimistic.. all those old awesome plugins seem to just die out these days.
    But I can't say most replacements are really worthy replacements.
    • Agree Agree x 3
  8. MiniDigger


    thats the cool thing about open source plugins and why you should always prefer a open source plugin over proprietary stuff:
    anybody just can go alone and update it, not just the original author. so if there is a demand for updates, there will be updates (essentials or worldedit are prime examples of this)
    • Agree Agree x 1
  9. For now i guess we can do some hacky stuffs like: Material.RED_WOOL.name().endsWith("_WOOL"); But idk, it should work tho
  10. md_5

    Administrator Developer

    Yeah that would work
    • Winner Winner x 1
  11. Would you like to publish a spigot version for the pre release version like 1.12?
  12. I'd search for them when 1.13's spigot build gets released or else if they break, it would not be possible because there's no replacement for it I guess :/
  13. Thanks for sharing this. Will definitely miss block ids as an end user. lol.
  14. md_5

    Administrator Developer

    /give 238
    /give light_blue_t<tab> or /give light_<scroll><click>
    • Agree Agree x 2
    • Like Like x 1
    • Winner Winner x 1
    • Optimistic Optimistic x 1
  15. Just as I suspected, a lot of changes and a lot of broken plugins if people don't make the necessary changes.

    I've got some (very simple, Skript hype) changes to make - I plan to release these by Christmas :)
  16. Finally, great!
    Is it similar for all the different potions?
  17. md_5

    Administrator Developer

    No, potions have already an advanced PotionMeta API.

    Spawn eggs are different items now though
  18. The block IDs have been deprecated (at least backwards compatible) for 4 years. People who still use them are only self to blame when their plugins break.
    • Like Like x 1
    • Agree Agree x 1
  19. thanks for the great work md_5 and spigot team! <3 <3
Thread Status:
Not open for further replies.

Share This Page