Minecraft 1.13: API Preview 4

Discussion in 'News and Announcements' started by md_5, Jan 14, 2018.

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

    Administrator Developer

    Because we would have to make up over a hundred unofficial ids that will be used by no one but spigot.
    Why do this when you can use the same Ids that every other Minecraft thing uses?
    • Agree Agree x 2
  2. With tab-completion, the text ID format is a lot faster to type. And you don't need to memorize random numbers, which will become undocumented for new blocks since spigot would need to make up its own numbers. It's a lot faster to type //replace co<tab>wa<tab> red<tab>; tab completion means that typing is a non-issue.

    No, the new format in fact uses a lot less disk space, because of the palette. And if spigot made its own format, that would break vanilla save compatibility, which is simply put not going to happen.

    You say (in a mangled form) that time is money. Implementing this would waste many hours of developer time, to support something that really doesn't need to exist. It'd probably waste more time than it'd take for you to learn how to use the supported format.
    • Agree Agree x 3
    • Informative Informative x 3
  3. Agree with you. Thanks
    • Friendly Friendly x 2
  4. Thanks for a good answer, I respect your points.
  5. I used names since the functionality was there.
    With worldedit it’s easy to use. Commands will complete very well. Look at the Mc commands it’s easier to use now. @R00t
    • Agree Agree x 1
  6. Plugins like WorldEdit will still be able to map old numeric IDs (and data values) to the new string IDs. They might even accept those values for commands.
    Using the string IDs will be easier in 1.13, because the IDs shown in the client will match the names in the Material enum.
  7. Personally I look forward to never seeing those old numeric IDs. They were/are a perfect example of an unsorted and illogically laid out enum that evolved over time. With that said, I completely understand why some folks are upset by its removal but for me, even though it will mean quite a bit of work, I say the time has come to move on.
    • Agree Agree x 5
  8. `git branch` only lists branches you've checked out, which will probably only include master. Run `git fetch` once (may not entirely be necessary), and then you can use `git checkout preview` to check out a copy of the preview branch. `git branch -a` lists all branches (including those on the upstream repo that haven't been checked out locally); you should see `remotes/origin/preview` listed and `git checkout preview` gets the corresponding branch.
    • Useful Useful x 1
  9. Optic_Fusion1

    Resource Staff

    Random number generator for x amount of ids and automate the process, however even then using the same ids that every other Minecraft thing uses is much better :p
  10. Thanks pokechu22! That's what I needed!
  11. md_5

    Administrator Developer

    It’s still in only because Mojang hasn’t touched the code.
    If damage code starts moving around then it’ll go.
  12. Sorry if this has been talked about before. Im just reading this thread on my phone in bed and can't see a mention of it.

    Does this release have, or will it have, full support for the new command system? Completion, types, all that stuff? I'm very excited to play with that.

    And thank you for your work on this update.
  13. As far as I know, there are unfortunately currently no plans to expose the new (brigadier-based) command system; the old system will still be used.
  14. MiniDigger


    It will most likely not, but you should check out acf (https://acfspigot.emc.gs), that will support bridagier.
  15. NathanWolf


    Is this still a good thread for discussing the upcoming API changes?

    I'm wondering about the Particle enum: https://hub.spigotmc.org/stash/proj...rg/bukkit/Particle.java?at=refs/heads/preview

    Firstly, it's missing the new particle types.

    Secondly, it seems like most other enums (at least Material and Art) have been updated to match Mojang conventions- are there any plans to also change this enum?

    I think it'd be cool if we could keep the existing names, maybe mark them @Deprecated, but then add names for particles that match the new Mojang 1.13 names, e.g. "DUST" instead of "REDSTONE", "ENTITY_EFFECT" instead of "SPELL_MOB", etc.
    • Like Like x 1
  16. Choco


    Would also be really nice if the data type weren't using the deprecated MaterialData class, but yes, I agree. I had already brought up the MaterialData thing to md_5 a couple months back. Not sure whether he made the change or not because that was post-pre-2
    • Agree Agree x 2
  17. NathanWolf


    Oh, yeah, I missed that too- I assume that BLOCK_CRACK, BLOCK_DUST and FALLING_DUST should all just use Material in 1.13.
    • Agree Agree x 1
  18. They aren't like that anymore, though. minecraft:block and minecraft:falling_dust both take a block state, minecraft:item takes a full itemstack, and minecraft:dust takes 3 colors and scale. (The data types for them got a lot nicer rather than being a varying number of ints).
    • Like Like x 1
Thread Status:
Not open for further replies.