Now that the output log isn't getting flooded by command block errors, I realized why this problem was happening. For example, when you write a command that goes something like this:
/summon falling_block ~ ~ ~ {Time:1,BlockState:{Name:lever,Properties:{face:floor,powered:true}}}
Then the powered
part of it will fail due to being "unable to read the value" of that property, unless you surround the value with quotation marks. According to the log, it's apparently automatically converting the words true
and false
into 1b
and 0b
respectively, which aren't valid blockstates. This occurs for other true/false blockstate arguments as well, such as open
, and all of this also applies to the blocks being carried by endermen and minecarts.
I'm not sure if the auto-conversion is deeply-rooted and hard to fix, but that seems to be the only problem here. And as mentioned, quoting will allow the state to work properly, e.g. open:"true"
, so it's not too major of a problem.
It has to be a string, typing true/false without quotes makes it a byte, which cannot be type corrected to a string saying “true” or “false”, same with numeral states.