mojira.dev
MC-310648

Suspected Conversion Issue with SNBT to JSON

Numeric types other than Byte don’t seem to be recognised in JSON.
I’ve got an example Advancement that triggers when a player is holding an item with custom data.

{
  "display": {
    "icon": "minecraft:diamond",
    "title": "Test Advancement",
    "description": "",
    "frame": "task",
    "show_toast": true,
    "announce_to_chat": true
  },
  "criteria": {
    "trigger": {
      "trigger": "minecraft:tick",
      "conditions": {
        "player": {
          "type": "minecraft:entity_properties",
          "entity": "this",
          "predicate": {
            "minecraft:equipment": {
              "mainhand": {
                "items": "minecraft:stick",
                "predicates": {
                  "minecraft:custom_data": {
                    "test": 1
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

If I use any of the following commands, it triggers fine:

/give @p stick[custom_data={test:1b},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1B},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1

If I use any of these, it fails:

/give @p stick[custom_data={test:1},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1.0},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1L},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1l},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1I},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1i},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1D},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1d},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1F},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1f},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1S},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1
/give @p stick[custom_data={test:1s},custom_name={"color":"white","italic":false,"text":"Example Stick"}] 1

Linked issues

Attachments

Comments 7

Thank you for your report!
After consideration, the issue is being closed as Working as Intended.

Please note, that mechanics of the game may change between updates.
Things such as graphics, sounds, world creation, biomes, redstone, villagers, and animals may not work the same in current versions.

Full Version History – Snapshot Version History – The official Minecraft feedback site

Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki

See comment in MC-304242 for explanation.

@slicedlime, that’s not the issue though. INT isn’t recognised as INT. You can’t tell me that’s expected behaviour…

/give @p stick[custom_data={test:1}]

^ That gives you a stick with a value of 1 with no way of checking for it in files. 1b conversion to 1 works, and “1” string comparison works, but nothing else. Are you saying that we can’t store numbers in custom_data unless we stringify them?

There is a way to account for both cases, by checking against SNBT (e.g. "minecraft:custom_data": "{test:1}"`) and using an any_of predicate. I made a simple test datapack which does this: [mediaInline]. I don’t like this and wish it wasn’t necessary, but at least it is an option.

Surely that confirms its buggy nature, no?

Mojang may have decided that any attempt to address this issue would have the potential to meaningfully impact performance and/or maintainability in the long run, so they opted to foist more work onto datapack developers instead. In that respect it’s similar to this comment on MC-121807. I personally would still like to see Mojang use Won’t Fix more liberally but will accept these cases as the logical limit of the Works as Intended resolution.

Sobekan

(Unassigned)

Confirmed

26.3 Snapshot 6

Retrieved