Talk:Block states

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 · 👁 Image
👁 Image
· 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)

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 (talk • contribs) 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)

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 · 👁 Image
👁 Image
· 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) 👁 Image
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. -- Orthotope^talk 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) 👁 Image
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. -- Orthotope^talk 17:06, 25 September 2014 (UTC)

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) 👁 Image
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 · 👁 Image
👁 Image
· 17:35, 29 September 2014 (UTC)

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) 👁 Image
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) 👁 Image
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)

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

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

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)

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)

👁 Image
 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)

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)

👁 Image
 😖😖😖😖😖 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)

It appears that the term block state is used incorrectly in a few places on this wiki. The official i.e. correct usage refers to the overall state of a block, containing all of its key-value pairs. For example minecraft:furnace[facing=west,lit=true] is a block state. In this case referring to "facing" and "lit" as block states, which are in fact properties or keys of the block state, would be incorrect usage.

The correct usage is confirmed by the fact that has been used by Mojang developers including Dinnerbone. For example, twitter.com/dinnerbone/status/454208814393597952 refers to each line of the linked text file, which lists all valid key-value combinations for each block at the time of writing, as a "unique block state".

It is also confirmed by the code under net.minecraft.world.level.block.state; The BlockState class refers to a Block (e.g. FurnaceBlock), and a StateHolder which in turn contains and manages multiple Property objects (e.g. DirectionProperty and BooleanProperty subclasses) associated with the Block class. Classes named according to official Mojang mappings as of version 1.16.5.

For consistency of information across the wiki, as well as consistency with external information such as that provided by Mojang developers, it is recommended that the usage of the term "block state" follows the official usage where possible. Kasamikona (talk) 16:48, 17 September 2021 (UTC)

Looks like this still hasn't changed. A "block state" is the complete set of specific values for all properties of a block. Something like a /setblock command specifies a block state, expressed as a reference to thee block type and an optional list of properties different than the default block state for that block type. Calling the individual properties "block states" is just plain wrong. Wormbo (talk) 09:28, 15 April 2026 (UTC)

This is correct, only bedrock wrongly calls properties states. This page should be called "Block properties" Tryashtar (talk) 20:17, 15 April 2026 (UTC)

Hanging Sign Block States are not in this list. Miner (talk) 06:11, 21 April 2024 (UTC)

The values ​​in a block state have an order. This affects things like command suggestion, debug mode, and the debug stick. Removing this order to use alphabetical order is erasing important information in favor of easily obtained information. Aloi4 (talk) 00:47, 14 March 2026 (UTC)

Properties for a particular block have a specific order, yes. But this page lists properties by name, so that order has no meaning. Properties can be ordered differently for individual blocks. The order would thus only mapper on that block's description page. Wormbo (talk) 09:31, 15 April 2026 (UTC)

It's not the order of the properties, but rather the order of the values. The list would remain the same, only the order of the values would change. Aloi4 (talk) 15:50, 15 April 2026 (UTC)

That is true. Value order matters for when they are iterated over, e.g. cardinal directions. Wormbo (talk) 18:40, 30 April 2026 (UTC)

Correction: Suggested command in alphabetical order. But I believe the main reason for ordering correctly is the debug stick. Aloi4 (talk) 12:40, 10 June 2026 (UTC)

Retrieved from "https://minecraft.wiki/w/Talk:Block_states?oldid=3619423"