Minecraft 1.13: API Preview 3

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

  1. in the test server commands isn't hidden for insufficient permissions?
     
  2. md_5

    Administrator Developer

    Essentials doesn’t define permissions properly

    E: this is no different to typing /<tab> in 1.12
     
  3. Okay.
    But on my 1.12 server the tab-completion is set to -1 for hide the bukkit/plugins commands.
    The new command suggestion is will support for tab-completion -1 option for disable the commands show?
     
  4. md_5

    Administrator Developer

    Yes (already stated above)
     
    • Like Like x 1
  5. [​IMG]
     
    • Funny Funny x 5
  6. MiniDigger

    Supporter

    you mean the extra ~2k lines of bloat to support outdated plugins?

    speaking about that, since bukkit had a bad track record of handling deprecations, will this be different this time?
    like, will that be removed in 1 year or after 2 major updates or something like that? I don't think bukkit should be clustered with deprecations that are there indefinitely.
     
    • Agree Agree x 4
  7. Uh, might have already been fixed but I noticed this

    upload_2018-1-14_13-24-21.png
     
    • Friendly Friendly x 2
  8. Maximvdw

    Benefactor

    I suspect this temp API diff does not take the removal of team prefix/suffix into account yet seeing there are no changes? Or will it internally do something with the new longer names?
     
  9. I would use it for shop type plugins. So if a player 'searched' by the material name, I would be able to validate whether it can be represented as an item to be bought/sold.
    Another use case would be for inventory interfaces (chest gui's). As block only materials do no generate an itemstack - I suppose a plugin could abuse that the item turns into Air?
    A third example would be any command that would wants to identify a Material from a string parameter; for similar purpose as above - to search for that item or generate the item to give to a player/inventory.

    The reason I mention it now with 1.13; is that vanilla generates this list for the /give command. I do not know what that code looks like, but if it can be conveniently hooked into - I think it would be a nice addition.
    Otherwise, this same task can be accomplished at the plugin level by manually sorting the materials like is done for the .isBlock() method.
     
  10. Thanks md. Now time to ensure that my plugins will work on 1.13
     
  11. Could this be something which could be solved by tags? Seems like all of those isSomething() checks in the Material class should be implemented by vanilla as tags. We have no control over what Mojang implements as tags, and I am pretty sure they separate out blocks/items internally.

    Speaking of which.
    [​IMG]
    The parameter name/docs should probably be altered to encompass the generality of the object being checked (vanilla includes items, blocks, and functions). Unfortunately I am at a loss for a better name. The word Item, to me, is immediately connected with ItemStack. Maybe something general and boring and then elaborate in the above documentation.
    If a better replacement does not exist for 'item', the parameter name could stay, but I think the docs should indicate this point.

    Edit: personally, I would have preferred an API solution which split up items and blocks into something like a BlockMaterial class. so .setType methods would reliably take a type of material which would always work, so one does not have to rely on the knowledge of the inner mechanics of Minecraft. I think the legacy implementation would still be possible alongside this. I acknowledge this would be a more significant breakage, so I classify this purely as my opinion.
     
    #53 chickeneer, Jan 14, 2018
    Last edited: Jan 14, 2018
  12. 2008Choco

    Resource Staff

    Funny you say that because I was all over that method last night in the IRC when I first saw it
    Code (Text):
    <Choco> :O. Lightable#isLit()
    <Choco> <insert 100 emoji, crying laughing face, fire and "okay" fingers>
    ... later ...
    Code (Text):
    <Choco> md_5, would you be opposed to adding the following emojis to Lightable#isLit(). <insert 100 emoji, crying laughing face, fire and "okay" fingers>
    <Choco> I believe they would be a beneficial addition to the Javadocs
    <LaxWasHere> vouch
    <LaxWasHere> most useful thing choco said all year
    <Choco> Thank you, my good sir
    But alas...
    Code (Text):
    <md_5> Choco: I tried
    <md_5> Netbeans didnt like it
    <Choco> Damn :c
    <md_5> I was gonna change the param name to fire
    Looks like Javadocs don't support emojis, but at least an attempt was made!

    Spigot wouldn't let me paste emojis on the forums :c FeelsBadMan
     
    • Funny Funny x 5
    • Winner Winner x 2
  13. No that area of code was a waste of time. I wish we could say we do not allow plugins that don't support the new API.
     
  14. Phoenix616

    Resource Staff

    I had a similar idea when I saw the additions to these switches but I'm not sure what I think about using tags. I would feel that an enum (e.g. MaterialType.SOLID or something) would be a bit better and faster than relying on Mojang's tag system. (I wrote a similar comment in #spigot-dev) Imo. defining the type (?) of a Material in the enum definition would be a lot cleaner and easier to manage/update than having extremely long switches.

    And a part of me still hopes that Mojang will add vanilla tags for all the different categories. Then we could just use these ;D
     
  15. [​IMG]
    [​IMG]
     
    • Funny Funny x 6
    • Winner Winner x 1
  16. md_5

    Administrator Developer

    Thanks, will fix
    I’ve kept them for compatibility, they just wrap either side of the display name.
    hell of a lot more than 2000 lines. The reason the Bukkit API changes slowly is people expect their 1.8 plugin to work on 1.12, and that’s a major reason why bukkit has been so successful as an api, otherwise people would just use forge.
     
    • Agree Agree x 4
    • Like Like x 1
    • Informative Informative x 1
  17. Maximvdw

    Benefactor

    Only display name or also playlistname?

    Currently how team prefix behaves:
    1) If playerlistname is equal to the name the prefix/suffix would be shown in tab
    2) if playerlistname is not equal to the name the prefix/suffix would not show

    so maybe only add a prefix/suffix to the playerlistname when it is equal to the player name?

    Understand it is a hackjob that will 'in the end' require plugins to use the display/list name instead. Just giving some ideas
     
  18. Fantastic frontpage news to read. Wonderful work as always, and things are looking promising.
    Developers, engage!
     
    • Agree Agree x 2

Share This Page