Let's say you want to summon a sheep that glows. You'd probably go for /summon minecraft:sheep ~ ~ ~ {Glowing:1b}. And hey-ho, it works as expected. Glowing sheep.

Then to screw around some more and find out about data types, you try for {Glowing:2b}. The sheep still glows, so like other languages booleans actually work more like 0 and not 0. So for further screwing around—ahem, 'testing'—you change 2b to 2. No change. So the game works with straight integers when it's expecting bytes. What if we exceed the range of a byte?

{Glowing:127}, glowing sheep. {Glowing:128}... still a glowing sheep? The number doesn't end up wrapping around to 0 until 256. Forcing it into a byte, it wraps to 0 at 128b and -129b. Further testing with coloured sheep confirms the unmarked number is unsigned.

The page on this on the Official Minecraft Wiki doesn't show any unsigned data types. Does anyone have some insight?

  • Nice, questions like these are why I follow the "minecraft" tag and endure all the bad questions in between. Also, I wanted to give a main source (apart from "my general game knowledge and a bit of trial and error") in the answer, but it's exactly the wiki page that you already linked. :D – Fabian Röling Jan 23 '19 at 21:55

When entering NBT, the provided data type mostly doesn't matter. It gets converted to the correct type for that field automatically.

Regular numbers become ints, so entering e.g. 3000000000 results in the value overflowing and becoming negative, even if it then gets converted to a long.

Numbers with decimal points become doubles, including .0 and 0..

Just a . seems to be accepted as a number, but I wasn't able to figure out what type. It plays along with other numbers labeled "i", but that shouldn't be a number suffix. Strange.

In arrays (like Motion) only one number type is accepted, even if they are compatible for conversion. So [1.0,2.,3d] is accepted, but [0.0,0.0,0.0f] is not.

Apparently arrays don't convert from whole number types to floating point types. Summoning an entity with Motion:[1,0,0] does not give it motion.

The remaining types are trivial: Array, compound and string. They don't have type suffixes.

Now to the other side of things: When reading NBT, you do have to match the correct type. Because your input gets implicitly converted to int or double if you provide no format suffix and only then it's compared with the existing NBT, it often fails.
So even if you summon an entity with Motion[0.0f,0.0f,0.0f], you still can't test for it with Motion[0.0f,0.0f,0.0f], you need Motion[0.0d,0.0d,0.0d].

  • When appying an integer to a TAG_Byte, why is the overflow cap at 256? – Jove Rogers Jan 25 '19 at 1:01
  • Because it can overflow again when being converted to a byte. Byte=8 bit=256 combinations – Fabian Röling Jan 25 '19 at 7:07
  • 1
    I've greatly progressed in my computer science education since posting this question, and I'd like to add on something that would have been useful back in January. A byte, as Fabian says, can count to decimal 256. The breadth of my experience was mostly C programming, a language in which compilers assume integers of all sizes are signed unless otherwise stated, hence why 127+1 would become -128. Signed integers utilise numbers 128–255 to represent negative numbers. Simply put, a sheep's {Glowing} tag can be 255 because it's assumed to be an unsigned byte, which can count that high. – Jove Rogers Sep 2 '19 at 17:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.