Talk: Block

Long boxes followup

Well, it has been a year since the last discussion, and I just finished removing the last of |firstver=. 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. -- Orthotope^talk 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. —munin · · 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 ^(talk|contr) 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 ^(talk|contr) 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? —munin · · 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)

 Support Some mobs, particularly bosses, look like they are either bigger or smaller than they actually are. The Blobs 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 |size= 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 Blobs 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)

 Done –KnightMiner ^t/_c 03:16, 21 July 2018 (UTC)

Protected edit request

Can the |tool= 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)

@Nixinova: Are you saying to replace all the instances of {{InvSprite}} within the {{#switch: {{ lc: {{{tool|}}} }} function with {{AnimateSprite}}?-- Madminecrafter12^{Talk to me} 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^{Talk to me} 02:49, 2 November 2018 (UTC)

With {{AnimateSprite}} the 5 parameters need to be Wood,Stone,etc |tool= otherwise it doesn't work. So "axe" = {{animateSprite|Wood Axe|Stone Axe|etc}}, etc. Then it can also be changed to support min-and-above tools as well – Nixinova  03:15, 2 November 2018 (UTC)

@Nixinova: But then what would I do with the rest of the stuff in the currently-InvSprite parameter, i.e. {{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^{Talk to me} 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 #replace 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  Done. 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, Nixinova, would you care to respond to the ping in the directly above section. Thanks!-- Madminecrafter12^{Talk to me} 02:30, 8 December 2018 (UTC)

If no one objects I'll probably be able to run my bot tomorrow.-- Madminecrafter12^{Talk to me} 23:36, 8 December 2018 (UTC)

Was about to run AWB with my bot to do the replacement, but I do have a question. Nixinova, 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^{Talk to me} 15:34, 10 December 2018 (UTC)

I think that might be better. – Nixinova   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^{Talk to me} 20:39, 10 December 2018 (UTC)

 Done. 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^{Talk to me} 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:

Furnace Fuel

8.0 smelts

Slabs:

Furnace Fuel

Wood only: 0.75 smelts‌ 1.5 smelts‌

Diamonds:

Furnace Fuel

No

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)

This is something I plan on doing soon. - User-12316399 (talk) 19:59, 6 March 2020 (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 version.jar/assets/minecraft/block) in the Infobox itself. e.g. the page for Smoker could have "'''Front''': {{cd|smoker_front.png}}<br>'''Top'’': {{cd|smoker_top.png}}<br>'''Side''': {{cd|smoker_side.png}}" 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)

Add “Waterloggable” row

We need an easy way for readers to check if a block is waterloggable. Right now, if I want to check, I need to go to the Waterlogging page and look at the table for which blocks are watterloggable. When I use a desktop, I can use ctrl+F to find the block that I am looking for. However, I mostly use mobile devices (and I except many other readers do too). Since the blocks are not alphabetized, it is very difficult to find a block.

We should have a |waterloggable= parameter, which defaults to NA (since waterloggability does not apply to full blocks). We can have a bot apply this parameter to non-full blocks, and re-order the table on the Waterlogging page; Majr or KnightMiner, could one of you do this? The Blobs 16:49, 24 July 2019 (UTC)

Seconded. I think it's worth noting that the page is actually somewhat outdated in many respects, so the info will need to be updated. It may also be worth adding a snowloggable parameter. - User-12316399 (talk) 18:52, 24 July 2019 (UTC)

 Support adding a |snowloggable= parameter. However, the “Snowloggable” header should indicate that this only applies to Bedrock Edition.The Blobs 21:24, 24 July 2019 (UTC)

I'd support such a parameter as well. I can do it myself in a few days if no one objects.--Madminecrafter12 ^{(Talk to me | View what I've done)} 18:55, 24 July 2019 (UTC)

Request column width tweak

There are several obtrusive line wraps which could be eliminated if the second data column was just a little bit wider:

• Pages for possibly wooden blocks (such as Fence) have a line under "Flammable" which reads "Overworld Wood: Yes", followed by a number in parentheses. The number always gets wrapped.
• Under "Stackable", "Yes (64), same type only", the "only" gets wrapped
• The "Blast resistance" and "Hardness" fields are quite large in articles on block "families", where the individual block types do not all have the same values. In particular, see Stairs.

If it is desired that the total width not change, then some space could be taken from the heading column if "Catches fire from lava" was allowed to wrap

If this is a platform-specific issue, then could instead the widths be made modifiable with a drag-drop handle? - Arkaenum (talk) 23:22, 23 August 2020 (UTC)