Template talk:Block

Long boxes followup
Well, it has been a year since the last discussion, and I just finished removing the last of. So, what now? Do we just remove the row entirely, or leave the "See history" link there? – KnightMiner  t/c 02:10, 26 February 2016 (UTC)


 * I think it would be fine to remove now. People should hopefully have gotten used to clicking history in the TOC to find out if they can use something in their version.
 * I think it'd be good to review what fields we have in general, and see if they're all still relevant, and if there is anything else that should be there.
 * I'd like to remove:
 * type: not useful, the intro text often says what something is anyway.
 * flow speed
 * player movement speed
 * hardness: most players won't know what this number means, and the obtaining section also shows it, along with actually usable data. Blast resistance has the same issue, but we currently don't have it anywhere else on the page with player relevant data.
 * –Majr ᐸ Talk Contribs 03:26, 27 February 2016 (UTC)


 * Agree on type, flow speed (there are only two liquids, should be mentioned in the article – lava's flow rate varies by dimension). Movement speed is also only used for water and lava, and "slow" and "very slow" aren't helpful. I don't know if we need the gravity field, which only applies to four blocks, all of which already mention their behavior in the body of the article. -- Orthotopetalk 04:48, 27 February 2016 (UTC)


 * I also agree on removing all those fields, plus gravity as Orthotope mentioned. I am not really sure where blast resistance could fit in articles though, so until we get something better with that I would just leave it in the infobox. – KnightMiner  t/c 19:05, 27 February 2016 (UTC)


 * Agree with Majr and Orthotope. – LauraFi - talk  00:00, 28 February 2016 (UTC)


 * Agree remove firstver, type, flow speed, player movement speed, hardness, gravity.
 * Blast resistance is a good example of a something which should stay in the infobox. For most blocks (other than those which come in multiple materials) it's a small bit of data that doesn't require an explanation in the article, just a link to the relevant article, so the infobox is a good place for it.
 * If we remove hardness we might as well remove tool as well, since they're both explained in the same place in the article. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 20:12, 28 February 2016 (UTC)


 * Yeah, I agree we don't need the tool in the infobox as well since we describe it better in the text. – KnightMiner  t/c 22:52, 28 February 2016 (UTC)


 * I don't know about blast resistance. It is a meaningless number, which links to more meaningless numbers and (if you scroll up) a too complex for most players explanation of what it means. If the explosion mechanics cannot be simplified in a way for non-technical players to understand, we should at least move blast resistance down with data values and change the link to the explanation, rather than the section on other blocks.
 * As for tools: perhaps, but it does have an actual immediate use to players (e.g.: I need a diamond pickaxe to mine thing), whereas hardness doesn't. The obtaining section does also explain it further, but isn't necessarily on the page without scrolling, and that extra detail isn't necessary to obtain the thing. –Majr ᐸ Talk Contribs 00:02, 3 March 2016 (UTC)
 * Not entirely meaningless. For example, Explosion tells us the limits for blocks stopping different kinds of explosions: "121.00 (charged creepers), 77.67 (TNT), 56.00 (creepers), 16.42 (fireballs)". Good to know to find out if a block is safe from Ghast fireballs. Anomie x (talk) 12:29, 3 March 2016 (UTC)

I have removed type, gravity, hardness, flow speed, player movement speed, multiplevers, firstver, and firstdev. Don't go removing these fields from articles just yet, in-case we suddenly decide we want them back. Now we can discuss any further changes to be made. –Majr ᐸ Talk Contribs 11:04, 21 July 2016 (UTC)


 * Hey Majr, isn't there supposed to be a History table, Issue and Gallery areas at the bottom of the template? Most (probably all) block pages have it. | AndrewAB (talkAndrewAB.png 11:17, 21 July 2016 (UTC)


 * What do those sections have to do with this infobox? –Majr ᐸ Talk Contribs 12:00, 21 July 2016 (UTC)


 * I don't get what you mean. Anyway, I'm wrong so yeah. Cut this part. I though that this template is supposed to be like this Stone page. | AndrewAB (talkAndrewAB.png 12:02, 21 July 2016 (UTC)


 * Thanks, Majr. Now that articles have good Data Values sections, would it make sense to simply remove the Data value and Name fields from the infobox? &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 17:26, 21 July 2016 (UTC)
 * Not all articles have Data Values sections. Those with just a single data value should probably remain in the infobox.-- ALWAYSFF talk·contribs 05:07, 22 July 2016 (UTC)

Size for blocks
I've recently implemented a size parameter in the template for entities and added the values to all infoboxes of living entities. Working on this project the idea came to mind that this might also be a good parameter for the blocks infobox. Of course this parameter would only be used for blocks smaller than a whole block e. g. a chest. The values would be the ones of the hitbox. In contrast to entity sizes there would have to be three dimension, because width and length are not always the same like it is the case for all entities. So I want to know wether there is some support or any objection for this idea. The parameter would have to be added to the template by an admin as editing the template is locked for normal users like me. Fusseel (User talk:Fusseel)
 * Some mobs, particularly bosses, look like they are either bigger or smaller than they actually are. The BlobsPaper.png 02:02, 9 June 2017 (UTC)
 * I'm glad that someone finally commented on my suggestion, but I honestly wasn't speaking about mobs. I already implemented the size parameter for mobs one month ago and added the values to every page. I missed out on the ender dragon, as it has a multi box model and it is quite confusing where he is actually vulnerable. That would've been too much text for the small infobox, at some point I may take the time to add a separat section to the article.
 * I was talking about a size parameter for blocks that would only be applied for blocks like chests as their collusion box doesn't quite match the size of a full block. Especially for the technical community this is an interesting value. I hope you're still in for that idea. Fusseel (talk) 10:12, 9 June 2017 (UTC)
 * A parameter for blocks is still a good idea; someone may want to know the thickness of doors. I am not sure what we would do for stairs, though. The BlobsPaper.png 13:46, 9 June 2017 (UTC)
 * Yeah, looks like I didn't think this completely through then. Cauldrons will be a problem as well, because they have this hollow collusion box. Maybe just skip those for now, until we figure something out? Fusseel (talk) 20:36, 12 June 2017 (UTC)

Sounds parameter
Would it be possible for a director/admin to add a sounds parameter (similar to the one on Template:Entity and Template:BlockTileEntity)? - Sonicwave talk  02:13, 21 July 2018 (UTC)


 * – KnightMiner  t/c 03:16, 21 July 2018 (UTC)

Protected edit request
Can the parameter icon be replaced with a AnimateSprite to show all tools instead of having just a wooden one? – Nixinova  02:40, 2 November 2018 (UTC)


 * Are you saying to replace all the instances of InvSprite within the {{#switch: {{ lc: {{{tool|}}} }} function with {{tl|AnimateSprite}}?-- Madminecrafter12 {{sup|Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png}} 02:46, 2 November 2018 (UTC)


 * I've boldly done that and the whole wiki hasn't broke yet, so that's a good thing.-- Madminecrafter12 {{sup|Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png}} 02:49, 2 November 2018 (UTC)
 * With AnimateSprite the 5 parameters need to be {{code|Wood,Stone,etc }} otherwise it doesn't work. So "axe" = {{t|animateSprite|Wood Axe|Stone Axe|etc}}, etc. Then it can also be changed to support min-and-above tools as well – Nixinova Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png 03:15, 2 November 2018 (UTC)
 * But then what would I do with the rest of the stuff in the currently-InvSprite parameter, i.e. {{tcode|Axe Required|link{{=}}Axe|This block can be broken with any tool, but an axe is the quickest}}? I've reverted my edit for now because it did break stuff. Apologies, you're much better at templates than I am, so presenting your changes in an X to Y format would be helpful for me. Thanks, -- Madminecrafter12 {{sup|Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png}} 23:13, 6 November 2018 (UTC)

Protected edit request
Can the "Transparency" field be changed to "Transparent"? Because having the -y implies it should be a number value or something not a yes/no question. Also "luminance": can it have a to change "no" to "none"? – Nixinova   (01:44, 8 December 2018 (UTC))


 * Agree with you regarding the first one and I see no reason why it could be controversial, so . For the second one, it may be a better idea to have a bot (mine, if needed; I should be easily able to do so with Madbot121 using AWB) to run through and replace "no" with "none" in every mainspace page, and leave instructions for future users of block to use "none" instead of "no"; I'm not sure using a replace function would be the best option. Also,, would you care to respond to the ping in the directly above section. Thanks!-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 02:30, 8 December 2018 (UTC)


 * If no one objects I'll probably be able to run my bot tomorrow.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 23:36, 8 December 2018 (UTC)


 * Was about to run AWB with my bot to do the replacement, but I do have a question., do you think it would be better to have "0" instead of "None"? This would also be useful because it's consistent with blast resistance. Responses from others would be appreciated as well.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 15:34, 10 December 2018 (UTC)
 * I think that might be better. – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 19:34, 10 December 2018 (UTC)
 * Alright; thanks for the reply. Unfortunately, I'm on mobile atm and will be for the next few hours, so obviously can't access AWB, but I should be able to do an AWB run with my bot when I get back home.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 20:39, 10 December 2018 (UTC)
 * . My bot has done the task using AWB, replacing all instances of light=no with light=0, as there have been no objections to this and the change is reasonable.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 03:43, 11 December 2018 (UTC)

"Furnace Fuel" Property
Browsing around the Wiki I (for some reason) always notice the little Usage > Fuel sections on articles. They're generally similar enough that I started to wonder if they would be suitable as an entry in the Item and Block templates. I imagine it continuing to focus on the number of operations per item, as in the following rough examples:

Coal:

Slabs:

Diamonds:

I'd love feedback on whether this information is overkill, and if not, what the clearest wording/formatting would be to present it. I'd be willing to make the related edits to blocks and items that can be used as fuel if something like this was implemented. – Brombardier (  ) 21:32, 31 January 2019 (UTC)

Request to add "texture files" parameter
I find it quite annoying while making texture packs to have to extract the version.jar just to find what textures go where. It would be great to have the texture files (from ) in the Infobox itself. e.g. the page for Smoker could have "" in the infobox. – Nixinova   23:55, 12 March 2019 (UTC)


 * I don't see much value in that, we might as well start including the localized name, model file, and blockstate files, and it would be a pain to maintain for every block. Plus, the texture files are really not constant, its entirely up to the resource pack to determine those from the blockstate and model files so you would have to extract the files from the jar anyways. Its a pretty niche group that needs that information which would already be extracting anyways.
 * Personally, I'd suggest just do what I do: extract the resources once and save them in a folder on your computer somewhere. – KnightMiner  t/c 02:53, 13 March 2019 (UTC)