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. I was thinking Material.RED_WOOL.getBase/CommonMaterial() could return Material.WOOL. And unique blocks just return self.

    Though a trait system could be nice too, I think reducing Materials to a common material would solve everyone's desire and require much less effort to resolve.
    • Agree Agree x 5
  2. All these posts about what is better, easier to remember, handier to use, etc..
    It doesn't matter. Mojang will change it to what they want it to be and Spigot will be as it is.
    Developers can adjust or die in the void of old plugins. T'is that simple.

    Looking forward to some serious updates to Spigot and the plugins.
    • Agree Agree x 2
    • Like Like x 1
  3. Well this should be interesting. I may hold off on development until after 1.13 comes out then. Thank you for your hard work.
  4. @md_5 Do you have any plans about 1.14?
    That will be interesting to implement and support in API.
    As then it looks more like that water is just a state of block, so maybe this is air block but with water state, as it will be kind of weird to see fence block type in on place, but water block type in another where both blocks have water.

    I think that new block api should also be ready for such weird changes.
    #104 GoToFinal, Dec 6, 2017
    Last edited: Dec 6, 2017
  5. Maximvdw


    Any insight on if those objective displayname changes fall under "altered, deprecated or removed"?
  6. Maximvdw


    API changes are inspired upon the NMS way of handling things - while keeping it compatible with older API versions. I'm fairly sure its too early to have an answer to that.
    Seeing that is a prototype they most likely hacked something together to show on their "big event".

    For all we know it may just be a few changes such as two new fields that indicate if a block has passThrough of water and if it actually contains water
    • Like Like x 1
  7. First of all, thank you for all the hard work on this update so far.

    Alright so 17w49a (post) is out and they have this new kind thing called "tags" which will make it easier to check for multiple blocks at once. From the post: "For example, checking if a block is "wool" with a command needs to actually test for every wool-like block individually. Now you can test if it matches the tag minecraft:wool, instead." We can create tags ourselves: "Inside data packs, you can create a file at data/(namespace)/tags/blocks/foo.json to make a block tag called namespace:foo, which contains a list of blocks that should be tagged with namespace:foo." There are also default ones: "There's not many default tags (both item & block have minecraft:planks and minecraft:wool currently, that's it). We're migrating things over to it, still." And tags can be used in recipes: "Recipes can now refer to a tag instead of an item." (all quotes are from the post by Mojang)

    I know this is a really new thing, but can we expect proper API support for this? Cause it seems like it's a pretty big deal.
    • Informative Informative x 3
  8. Could we expect anything similar to a Transfer packet being added?
  9. I find block titles (diamond_sword) harder to remember than block ids (276) as sometimes you go to do something like pumpkin_block then find out its just pumpkin or similar. Just my opinion :p
  10. Looking forward to this update, which is the first in a long time.
  11. But while we see it as a specific slot, there is no slot in the server side impl unless craftbukkit breaks away from what vanilla currently does and basically reworks it. Tab entries are just strings of player names, sent to the client (granted, sent with skin & ping & uuid) and then sorted 1-9A-Z via the client.
  12. I'd kinda prefer to have a release like 1.12, with dev snapshot builds. Really helps to understand the update, and prepare plugins.
    • Agree Agree x 2
  13. I would really like Vanilla to have an attitude adjustment. Sometimes I want to do things in command block "wool, irrespective of color" or "stone or *-ite" block. Perhaps some form of tagging for groups of blocks can be implemented.
  14. To quote my own post:
    They added exactly that.
    • Like Like x 1
  15. Wow! Amazing that this post came so quickly and super thanks for "warning" the community. Keep up the good work guys! :D
  16. They are also 100% unsupported at this time, and using them leaves you open to security risks and major bugs.
    • Agree Agree x 3
  17. Aka everything old is going to break and I haven’t even finished updating to 1.12 XD

    Gosh dang it mojang updates WAY to fast XD
    • Agree Agree x 1
  18. [​IMG] Amazing 80% eh 30% of servers that are on 1.8/1.7... Keep in mind that does not contain ViaVersion 1.8 servers, where also 1.9+ plays are playing... But yea lets try to keep 3-4 year old unsupportet and dead versions alive...
  19. MiniDigger


    the tags in the datapacks definitely seem to fix the issue of not being able to tell if a block is wool. this is how such a tag file looks like:
    Code (Text):
      "values": [
    the new block data api should support these tags, then its extremely easy to check if a block is part of a larger group of blocks.
    • Agree Agree x 6

  20. My thoughts exactly, i remember the 1.7 to 1.8 change.
Thread Status:
Not open for further replies.

Share This Page