Talk:Block states

From Minecraft Wiki
Jump to: navigation, search


Is there any particular reason this is sorted by the old numeric item ID? I think it should be sorted by the new id (alphabetically) instead. —F‌enhl 21:12, 4 August 2014 (UTC)

I'm not sure the headings should be ID names. Are we going to have a heading like minecraft:wooden_door, minecraft:spruce_door, minecraft:birch_door, minecraft:jungle_door, minecraft:acacia_door, minecraft:dark_oak_door, minecraft:iron_door? (stairs would have been too long to use as an example!) Or do they each get their own section?
I'd rather just say Door. And then, yes, sort headings alphabetically to give people some chance of finding things. —munin · Grid Book and Quill.png Grid Stone Pickaxe.png · 20:45, 21 September 2014 (UTC)


I propose this article gets rewritten to be more of the format of Data values, as many blocks use the same data field and different names, such as doors and torches. The sorting system we had on data values seemed to make sense. --KnightMiner (t|c) 04:28, 20 September 2014 (UTC)

Wood and Leaves[edit]

I am not sure how we are handling the wood and leaves. I have it currently so it's split between minecraft:log and minecraft:log2. I guess it depends on what purpose we are using these grids for. –Preceding unsigned comment was added by Sealbudsman (talkcontribs) at 15:34, 22 September 2014‎ (UTC). Please sign your posts with ~~~~

I think the format like used with rails should work fine, using subsection headers. --KnightMiner (t|c) 15:58, 22 September 2014 (UTC)

Cardinal direction order[edit]

We should probably pick some standard order for the cardinal directions as there are a few different ones on this page.

We also need an order for when up & down are also included, and possibly for other things too. --GufNZ (c: (talk) 23:44, 25 September 2014 (UTC)

I prefer colloquial ordering (north, south, east, west, up, down / true, false). It's easier to read and easier to remember (for example, even if there are just the four basic cardinal directions, if they're not in colloquial order you have to stop and think to check if they're all there or if something else got slipped in instead). But colloquial may not be universal (even if the wiki uses American english as the standard) so alphabetical would be my second choice. —munin · Grid Book and Quill.png Grid Stone Pickaxe.png · 02:38, 25 September 2014 (UTC)
Having put all the (non-transcluded) tables in alphabetical order, I do see what you're saying; down-east-north-south-up-west is pretty maddening to look at. Also, sorry for making this conversation even necessary. I'm up for changing it to whatever looks better. I vote for NSEW UD TF too.
I think the flowerpot table could stand to be organized better, too.
Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 14:44, 25 September 2014 (UTC)
Alphabetical is too illogical and arbitrary, since it will be different in every language translation of this page. I was thinking we could use the same ordering as the old data values, but Mojang was rather inconsistent in how they were used. Pistons, dispensers, and ladders are DU NS WE, torches, buttons and levers are D EW SN U, pumpkins and end portals are SWNE, repeaters are NESW, etc. The colloquial ordering mentioned above sounds good to me. -- Orthotopetalk 15:31, 25 September 2014 (UTC)
I agree to using colloquial ordering for directions. It does read easier.
Since it is on a similar topic, what about orderings for non-directional/non-boolean values? Numerical/alphabetical makes sense, but is not exactly being done, as it has not really been discussed.
Finally, should we note what would be the default value, as in if /setblock it without a damage value, what would be produced.
--KnightMiner (t|c) 16:10, 25 September 2014 (UTC)
I think noting the default value is a fine idea.
Is it fine to alphabetize the state names (except where n,s,e,w appear as state names), as opposed to their values ?
I would recommend 'upper' before 'lower', if only because that way 'upper' actually displays above 'lower'.
Is there a canonical 'tree' order, i.e. is it Oak, Spruce, Birch, Jungle, Acacia, Dark Oak? There seems to also be a well-established color order from White, Orange .. on through Black; I think they deserves preserving.
Also for things like Dirt, Prismarine, Sandstone etc, I think the base variant ought to come first no matter what.
I think that in the absence of an established 'colloquial' or other sort of order like color or tree type, we could, as Orthotope says, use the same ordering as the old data values, rather than alphabetical. That has the advantage of using a pre-existing Mojang-imposed ordering, so we don't have to worry about Flower type, Rail shape or Comparator mode values, that have no obvious ordering otherwise. But on the other hand, why use the data values; I thought the winds were blowing such that DVs are now subject to change, since they are moving away from them. Could we use the order of the states as ordered in Debug Mode of 1.8 (current version)?
Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 16:57, 25 September 2014 (UTC)
I like the idea of using the in-game/debug mode ordering for other named states. Numbered states should stay in numerical order. As for defaults, perhaps the name of the default state could be set in bold or italics. -- Orthotopetalk 17:06, 25 September 2014 (UTC)

All the block states should be in, now...[edit]

Going by what's available in the Debug world, I am pretty sure all the block states are now represented on this page. Thanks to people who have helped find those elusive fire and liquid states.

I had been adding different lists of block names, like "minecraft:nether_brick_stairs" and "minecraft:sandstone_stairs" here and there, to indicate what blocks all share that block state table. I'm not sure to what extent that's ultimately necessary; maybe that's been discussed already or maybe we should discuss it. It could be of help to include these names on each blocks' page, especially in cases like Piston where you have two blocks that make up the whole thing, but in other cases too I'm sure. Depends what we want to do.

Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 16:32, 29 September 2014 (UTC)

For the ID names, it would probably be useful to explain in the article why they're being listed. For example, "The block states below are used by blocks identified by the following ID names: …" or something. —munin · Grid Book and Quill.png Grid Stone Pickaxe.png · 17:35, 29 September 2014 (UTC)

Could use improvement / clarification:[edit]

Fire: what do 'age', 'alt', 'flip' and 'upper' indicate?

Piston Head: when is 'short' ever 'true'?

Skull: when is 'facing' ever 'down'?

Stairs: what does 'outer_left' etc mean -- 'left' and 'right' seem to mean different things, for different orientations of the stair. I was unable to describe it simply in terms of a sentence like "when facing=north, and facing this stair looking north, this is an outer stair that rises on the left", or something like that, because left and right seemed to be used inconsistently. I think this is good now – Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 19:53, 6 October 2014 (UTC)

TNT: what it means for 'explode' to be 'true'? thanks

Tripwire: what does it mean for a tripwire to be 'disarmed' versus not 'powered'? thanks

Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 16:42, 29 September 2014 (UTC)

Fire: age is how long the fire was in the world. It randomly increases like plants. The fire will randomly disappear based on some factors and the age.
Stairs: based on the location of the stair changing it's shape. A few are visually the same, but will change differently based on adjustment of nearby stairs.
TNT: Explode set to true would cause it to detonate upon breaking it, and false will cause it to only detonate from standard causes.
Tripwire: Disarmed means it was broken using shears, so it will not transmit a signal. When you break tripwire using other means, it powers.
--KnightMiner (t|c) 17:41, 29 September 2014 (UTC)
Through some testing it seems that fire's "upper" if 1 or 2 means the fire is on the top face of the block it is within, while if 0 means it is not. It seems it alternates between 1 and 2 for the top face in a checkerboard pattern.
If I ever get around to it, I will try changing the models of the other two tags on fire to find what they do. Currently there is no visual difference, as they use the same model. KnightMiner (t|c) 19:45, 2 October 2014 (UTC)

Messed up History[edit]

Can someone fix the history?-- 16:10, 15 December 2016 (UTC)

Done! Thanks. – Sealbudsman talk/contr 23:21, 15 December 2016 (UTC)

Block State Syntax in Commands[edit]

When using commands, there's two formats I know of:

When specifying the value of one or more block states:
space:block_name state_a=value_a[,state_b=value_b[,state_c=...]]

And when matching a block regardless of state:
namespace:block_name *

These formats are more likely to be used in future versions than the old damage values. Knowing that, I'm trying to figure out what to put in the block state field for blocks without a state:
/fill ~ ~-1 ~ ~ ~-1 ~ minecraft:grass replace air *
'replace' is not a state for block minecraft:grass
/fill ~ ~-1 ~ ~ ~-1 ~ minecraft:grass * replace air *
'*' is not a state for block minecraft:grass

I've tried a few things like "-" that I thought would work for a no-block-state space, but I can't seem to get it to work. Is there anything I can put there besides the old damage value method of putting a 0 for blocks without a block state?

It looks like the block state system is going to be far more flexible and easier to use than damage values once they're implemented, but a lot of thought needs to go into designing and documenting them. Thanks to everyone who contributed to the Minecraft Wiki, and this page in particular. NickNackGus (talk) 05:09, 3 July 2017 (UTC)

State type=boolean/integer/string[edit]

Currently, the pages have the types integer, boolean and string, but the game saves all states as strings in NBT (both in world format, and NBT representing blocks (eg carriedBlockState of endermen). Should we change the wiki to make them all strings instead? Because, for example, providing Properties:{north:true} in carriedBlockState won't make fences have a connection north, but Properties:{north:"true"} will.

FVbico (talk) 20:33, 15 August 2018 (UTC)

 Support this. Don't see why not, given that acceptable values for state strings are described in the tables. --AttemptToCallNil (report bug, view backtrace) 09:56, 1 October 2018 (UTC)

Merge this page with Java Edition data values?[edit]

I understand the former purpose of this page, but now we are at 1.13 (.1) and the old "weird-and-nonsensical-mixup-of-numeric-block-metadata-with-block-states" system has been replaced by the new, more powerful and simpler block-states-only system. The Data values page is now completely messed up because of 1.13, and I think this is exactly what these pages need. GammaMicroscopii (talk) 16:09, 6 October 2018 (UTC)

 😖😖😖😖😖 Two humongous pages consisting of barely intelligible tables. And you want to merge them.
I'm a bit out of the loop, but unless you mean moving this page to "Java Edition data values" and archiving that one to a subpage, I'm not even going to oppose or support. --AttemptToCallNil (report bug, view backtrace) 16:31, 6 October 2018 (UTC)
Maybe these things become slightly less unintelligible if we keep things simple and ordered by merging this blockstates page into the data values page and explaining what these things are and why you can't understand them as unrelated things (both are used to describe how the game defines and stores blocks and they cannot exist without each other). Remember how the 1.12 data values page was, with all the IDs first and the metadata below, and it was straightforward and consistent, at least to me. GammaMicroscopii (talk) 17:17, 9 October 2018 (UTC)
Just linking to and from this page, and making this a sub page should suffice. FVbico (talk) 16:42, 6 October 2018 (UTC)