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. Your doing a great job here! keep it op thanks for information us!!!!
  2. 1.14 will be implemented in 1.13
  3. md_5
    Administrator Developer

    My only fear is that MC 1.12 will become a similar experience to MC 1.7 and people will never update because "it breaks things" :\

    I'm excited for a suitable API replacement for data values!

    This update will make for a good API / Plugin cleanse.
  4. Legoman99573


    That is the point of major updates. Expecting things to break major and/or minor.

    Some things can be fixed easily (for plugins not using block ids, but need to use the new block names), some things cant (plugins still using block ids, which had almost 4 years to update to using block names).

    Now 1.7 upgrading to 1.12.2 will be a mess as there are soo many API changes between versions. How to avoid it? Stay up to date with the latest version and not use viaversion to support up to 1.12, which was never the intention of the plugins use in the 1st place. Viaversion was meant as a temporary bandaid until plugins update or find alternatives because some are unmaintained.
    • Winner Winner x 2
    • Agree Agree x 1
  5. Celebrimbor


    Careful now. You might trigger some of the “1.8-for-life” servers. ;)

    I 100% agree with your mindset on the matter. Wish more did too.
    • Agree Agree x 3
    • Like Like x 1
    • Informative Informative x 1
  6. Legoman99573


    If they get triggered over using 1.12.2 and protocolsupport for 1.8 kiddies to join, not my problem. I didnt ask for someone, with a higher chance, to crash my server ;)

    I do use viaversion as a bandaid for the next major update until i am ready to push to the next major protocol and remove viaversion again ;)
  7. I have done similar stuff before and just faked normal blocks and items for the vanilla client. I am pretty confident that this update allows for the same but without major performance loss. I definitely will be able to reuse some code from back then making it even easier. I am totally up for this! I would come back to Minecraft modding just for this :>

    If you find some other devs are excited about this we can definitely start am open source fork doing this. I cannot really do it on my own because studying physics at uni takes up time.

    I can definitely help out with nms so if someone is interested, but not very confident in the nms environment don't worry.
    #627 sirati97, Feb 19, 2018
    Last edited: Feb 19, 2018
  8. 1.13 ("The flattening") wont do anything to support custom blocks, but it lays the groundwork.

    Number of block IDs have become infinite for all practical purposes, each chunk can now have up to 4096 different types of blocks in it. Each mod could have its own space of IDs or have them reassigned on the fly.

    For now, all it does is make a massive headache for devs and break every single world editor, anvil/mca editor, nbt editor and map tool.

    @Empire92 Do you (or anyone else?) intend on updating the FAWE Anvil API for 1.13, or is it a "when we have time/feel like it/figure out how to" sort of thing?
  9. md_5

    Administrator Developer

    Number of IDs has always been that high (see - forge) - vanilla just never went above 255 for ????? reasons
  10. Yes, this is however exactly what I need to implement custom blocks efficiently. (given that the Minecraft client does not mind two or more different ids in a chuck pointing to the same block material)
  11. I think the motivation was that it keeps chucks smaller because of compression. at least thats what I read in a forge forum about why common world gen blocks should get an id smaller than 255
  12. Yeah, the way it worked before was that there was an optional "Add" nybble that was only used when you had blocks with IDs >= 256, which let you use IDs from 256 to 4095 (or rather, when considering block ID + metadata combos, block state IDs from 4096 to 65535). But using that in general would be more expensive because it's an extra amount of data for each chunk.

    The flattened chunk format uses a palette, so you'll have at max 4096 different block state IDs in a 16x16x16 chunk section. Plus you can have an arbitrary number of block states for each block, rather than being limited to 16 "real" states due to metadata (the flattening also separately got rid of a lot of blocks with block states, for internal consistency reasons -- but that does cause confusion when you hear "getting rid of metadata" and see the split wool blocks; the block state system still exists but is just used for more specific cases). Of course neither of these things really help with adding custom blocks without client modifications, but they are beneficial to mods and vanlila.

    Of that list: NBT editors should not be broken. NBTExplorer was broken, but that's because they hadn't implemented a tag that was added a while back (long array, from around 1.11 or 1.12). That has been fixed, so just download the most recent version from their GitHub page. Everything else is accurate though.

    This is something interesting that I haven't really thought much about. That should be legal over the network (in either version -- the current network chunk format already uses a palette), but is a somewhat strange use. I don't know how well it would work on disc, as I haven't researched that yet. Also not too sure how well it would work internally; 1.12 already supports (and in fact mandates) having multiple block states map to the same state ID (that's how e.g. different redstone orientations work) although that's no longer going to be used in 1.13. But it's a neat idea to experiment with.
  13. Number of IDs was at most 4096 for the entire server and all mods in existence, unless they let you manually edit IDs. See the fairly well-known "portal biome" error with BoP and thaumcraft(? - maybe it was ars magica).

    This will avoid conflicts between mods by letting a mod reserve a hundred or a thousand IDs as it pleases, without conflicts.
  14. md_5

    Administrator Developer

    65k with metadata, but even 4k is 16x as many blocks as vanilla used
  15. Maximvdw


    My bet is that block IDs are being removed for mod compatibility in the api that will prob never come ( to avoid Id conflicts)
  16. I am very willed to explore this idea. Server side this should be no problem as for the server such new blocks would just be normal blocks. Only when sent to the client a palette (or some other translation) would be used to send blocks the client actually understands. This should be possible to do we no overhead hopefully. Otherwise, the overhead can hopefully be limited to <1%.

    I made this thread to find some devs who want to explore this idea and are interested to make a spigot fork that would support that.

    I have done similar things for items in the past although I never got to release it because of DMCA and not knowing how to modify the build tool.
  17. Songoda


    Totally agree, its honestly a huge improvement over the old system.
  18. Legoman99573


    Most of it has to do that mojang cant implement new blocks because minecraft was close to hit the BlockID limit and going over would cause problems, which is why block ids were deprecated in 1.7.10 and replace with minecraft:blockname so once removed, they can implement new blocks in without causing issues, like for mods
  19. Maximvdw


    No reason to not extend block IDs. Fairly sure their is another reason apart from that
  20. MiniDigger


    Mod support (yes, I still believe that we will get a mod API, every Minecraft update brings us a bit closer).
    Easier to use for players.
    • Friendly Friendly x 1
Thread Status:
Not open for further replies.

Share This Page