Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-206118

"type" in loot table number providers is not optional anymore

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: 20w46a, 20w48a, 20w49a, 20w51a
    • Fix Version/s: 21w03a
    • Confirmation Status:
      Confirmed
    • Category:
      Commands, Data Packs
    • Mojang Priority:
      Important

      Description

      The bug

      Before 20w46a, when "type" was not specified, it would default to "minecraft:uniform", now it throws an error which breaks existing loot tables.

      How to reproduce

      1. Add this loot table to a data pack
        {
          "pools": [
            {
              "rolls": {
                "min": 1,
                "max": 4
              },
              "entries": []
            }
          ]
        }
      2. Reload
      3. You get the following error in the output log
        Couldn't parse loot table test:uniform
        com.google.gson.JsonSyntaxException: Missing type, expected to find a string
        	at afm.h(SourceFile:111)
        	at dbh$c.deserialize(SourceFile:76)
        	at com.google.gson.internal.bind.TreeTypeAdapter.read(TreeTypeAdapter.java:69)
        	at com.google.gson.Gson.fromJson(Gson.java:887)
        	at com.google.gson.Gson.fromJson(Gson.java:952)
        	...

      Original description

      Loot tables that have worked for a few major versions (1.12 and before) now are incompatible across the board (as far as I can tell...feel free to comment with any exceptions).

       

      According to user Alex Lecuyer on another similar but not quite the same bug report:

      Datapack coder here, I'm having the same validation errors with the parser for loot tables compatible in 20w45a and prior but incompatible with 20w46a, and the issue seems to be that the "set_count" function expects an "add" parameter instead of defaulting to "false", which invalidates most datapack loot tabes. Is this intended behaviour or will this be looked at to allow for backwards compatibility?

      Update: I'd like to correct myself! The problem isn't the "add" parameter, but rather that distributions require a specified "type" (like "type": "minecraft:uniform"), whilst previously this was only true for "set_count". In other words, "set_damage", "looting_enchant", etc. all have new requirements.

      Nowhere in the changelog does it say that this was added. This took a long time to figure out and even longer to fix my packs.

       

      So is 1.17 intended to be incompatible with everything that came before in datapack history? Or is this a bug?

       

      EDIT: to be clear, the behavior I was expecting was that if the new fields were left out the game would assume the defaults were the intended values. The changelog for 20w46a listed perfectly sensible default values for the new fields.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              boq [Mojang] Bartosz Bok
              Reporter:
              Tokes Tokes
              Votes:
              6 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                CHK: