Template talk:Block state table

Sprites column
Instead of having the sprites column sometimes blank, what if there was no sprites column and you just added a sprite to the description when appropriate? &mdash;munin &middot;  &middot; 22:59, 6 September 2014 (UTC)


 * That would work, although be a little more code on the user's side. I'll try it to see how it looks. --KnightMiner  (t 03:23, 7 September 2014 (UTC)


 * Comparison view. You could really use blocklink and alike there if desired too. --KnightMiner  (t 03:36, 7 September 2014 (UTC)


 * Yep, I prefer no sprites column. BlockLink is easy, it shouldn't be a problem. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 05:39, 7 September 2014 (UTC)

Multiple values per row
Would it be okay to suggest/permit multiple values per row, where the values can be more-easily described with a single description? You would do it by only providing a single value-description pair, but provide multiple values in the value part (delineating by BR probably). I think that would make some state fields easier to discuss as a whole, rather than being limited to discussing each individual value separately. For example:

Of course you can still have separate lines for each value where it makes sense (like ). &mdash;munin &middot;  &middot; 23:39, 7 September 2014 (UTC)


 * For redstone dust and maybe others, it may even make sense to put multiple fields in a single row, rather than repeat the same information multiple times:


 * {| class="wikitable"

! Name ! Value ! Description ! rowspan=3 | !
 * + Redstone Dust
 * || Not configured to point in this direction.
 * || Configured to point in this direction.
 * || Configured to point in this direction, linking diagonally vertically.
 * || Configured to point in this direction, linking diagonally vertically.
 * || Configured to point in this direction, linking diagonally vertically.
 * 0 to 15
 * Redstone power level.
 * }
 * &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:08, 8 September 2014 (UTC)


 * . Simply separate the values using commas, or for multiple number, use "to" in the middle. --KnightMiner  (t 02:57, 8 September 2014 (UTC)


 * Is it better to order values alphabetically (e.g., east, north, south, west; false, true), by coloquial convention (e.g., north, south, east, west; true, false), or no specific order? &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 17:41, 18 September 2014 (UTC)

State field types
Is there a way to determine a state field's type (string, byte, etc.) from the F3 screen, or is it just an educated guess (true/false and numeric values below 256 are bytes, white text is string, etc.) or you have to look at the code? &mdash;munin &middot;  &middot; 23:57, 7 September 2014 (UTC)


 * It is mostly just an educated guess, based on the way js acts. "byte" means it is a simple true/false or 1/0 value, aka boolean. "int" means it is a numerical value, aka integer. "string" is any text value. --KnightMiner  (t 02:57, 8 September 2014 (UTC)

Name id vs. id name
I'm not sure which is preferred, "name ID" or "ID name". I've seen both from Mojang.

I wouldn't use a compound tag icon for it though, because it's just not. If it must have an icon, it's a string. But giving it any icon might imply it's a regular field like the others, which isn't the case. (or is it?)

I'm not actually sure it should it should be in the table, but we can give it a try. &mdash;munin &middot;  &middot; 22:30, 17 September 2014 (UTC)


 * Bug reports aren't written by Mojang, so the terms used in them shouldn't be considered official (unless it's a Mojangsta commenting, of course). I'm guessing "ID name" is more likely to be the official term, though it feels a bit more awkward to me. -- Orthotopetalk 23:34, 17 September 2014 (UTC)


 * The main reason I declared it "compound" was because of the initial format:, plus I liked the icon. I do think it could use a better location, as I want the name to always be included, instead of only when multiple blocks are used.
 * munin295@undefined Didn't you request it in the table though?
 * Orthotope@undefined Likely, yes. The main reason I used "Name ID" was because that is what we tend to use elsewhere on the wiki, mainly in parameter names though.
 * Edit: The best location I can think of would likely be separate from the table, like at the top of the data values section. Maybe add that as table (or a template...).
 * --KnightMiner  (t 00:43, 18 September 2014 (UTC)


 * The bug report had been rewritten by a moderator, but yeah iffy.
 * @KnightMiner: I asked if it made sense in the context of how to structure the article because I wasn't sure. Sorry if it sounded like a request.
 * "initial format"? where is that from?
 * In a couple style rewrites I've done, where it seemed like a short discussion of the id name made sense (e.g., how it's used to specify whether a redstone torch is lit or unlit) I had been placing it at the start of the Data values section and I'd be fine with continuing that, even to listing it when it's only one name. Technically it's just duplicating information that's already in the block box at the top of the article, but it would probably be nice to have the block's entire specification in one place. Though this is a style guide issue, not a template issue. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 01:22, 18 September 2014 (UTC)


 * munin295@undefined What you did on Command block looks pretty good, I may end up removing that feature then...
 * Also, the initial format was from the snapshots, starting in version 14w27a and being removed in 14w30a.
 * --KnightMiner  (t 01:33, 18 September 2014 (UTC)