Template talk:Infobox block

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

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)

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

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)

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

Can the {{{tool}}} parameter icon be replaced with a {{AnimateSprite}} to show all tools instead of having just a wooden one? – Nixinova 👁 Image
👁 Image
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^{👁 Image
Talk to me👁 Image}
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^{👁 Image
Talk to me👁 Image}
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 👁 Image
👁 Image
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^{👁 Image
Talk to me👁 Image}
23:13, 6 November 2018 (UTC)

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 👁 Image
 👁 Image
(01:44, 8 December 2018 (UTC))

Agree with you regarding the first one and I see no reason why it could be controversial, so 👁 Image
 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^{👁 Image
Talk to me👁 Image}
02:30, 8 December 2018 (UTC)

If no one objects I'll probably be able to run my bot tomorrow.-- Madminecrafter12^{👁 Image
Talk to me👁 Image}
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^{👁 Image
Talk to me👁 Image}
15:34, 10 December 2018 (UTC)

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

👁 Image
 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^{👁 Image
Talk to me👁 Image}
03:43, 11 December 2018 (UTC)

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‌[Java and Legacy Console editions only] 1.5 smelts‌[Bedrock Edition only]

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 (👁 Image
 👁 Image
👁 Image
) 21:32, 31 January 2019 (UTC)

This is something I plan on doing soon. - User-12316399 (talk) 19:59, 6 March 2020 (UTC)

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

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 + 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^{👁 Image}
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)

👁 Image
 Support adding a {{{snowloggable}}} parameter. However, the “Snowloggable” header should indicate that this only applies to Bedrock Edition.The Blobs^{👁 Image}
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)

Is someone available to implement this? I am not familiar enough yet with the various syntax to be confident in doing it myself. -- Mudscape (talk) 00:14, 1 October 2023 (UTC)

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)

Wondering if we should not add drops to this table so it's easier to find. Most blocks drop one item (or itself with silk touch) and some drop some XP. So I think the info is small enough to fit and be found quickly and easily. What do others think? - AD OffKilter (talk) 15:17, 8 July 2022 (UTC)

Thoughts on adding a map colour row to this infobox? LZH wiki has this (and maybe others), and someone suggested it on the community portal wanted pages. Map colour isn't terribly useful information, but it is a property of each block that I think I should be able to learn by visiting the block's page. - Harristic / Talk 👁 Image
10:48, 18 August 2024 (UTC)

How the colors would be shown if the block in question has colored versions? — BabylonAS 10:56, 18 August 2024 (UTC)

Like concrete? It could just be a list, though for long lists it should likely be collapsed. - Harristic / Talk 👁 Image
11:01, 18 August 2024 (UTC)

You can view glass on Chinese Wiki to preview the effect. Click "显示" button in the infobox. 👁 Image
Wilf233_zhMCW（论·功） 14:35, 18 August 2024 (UTC)

👁 Image
 Support Not much to say but I do like this idea. Grzesiek11 (talk) 10:56, 18 August 2024 (UTC)

I guess this is very good idea! SymORmaK (talk) 12:03, 18 August 2024 (UTC)

On some pages it might be unclear as to whether or not something is pushable by pistons because it just doesn't mention it. While some pages do have the piston interactivity section, others don't. This is also useful information, especially for people that like to build with redstone and stuff. Plus, these sections are never long, and in some cases, simply missing. This is the sort of thing a new infobox row would benefit from, don't you think? -~- Nerdyguy2000   Talk   Edits  02:07, 29 July 2025 (UTC)

Ew, double links. Just list them. Like examples: 1,2,3,4,5. -- Simanelix ^(T|C) 02:20, 29 July 2025 (UTC)

I was doing that for emphasis... :P -~- Nerdyguy2000   Talk   Edits  02:21, 29 July 2025 (UTC)

👁 Image
 Support. I've seen this suggested a couple of times over the past few months, and it makes sense to me. There have been concerns about infoboxes getting too big on Discord (I don't think there's been any on-wiki discussion), though I don't think it applies to block infoboxes, nor do I think this row would significantly contribute to the problem. I'm assuming it would be something as simple as: "Movable: Yes / No / No (breaks)".

(Though the inconsistency regarding whether this information should have its own subsection or be part of the redstone component subsection should still be addressed, whether we add this row or not.) - Zamburger (talk) 19:10, 29 July 2025 (UTC)

It would be useful for block infoboxes to say if the block is able to conduct redstone power or not. Even though conductivity can often be equated to transparency, there are exceptions to this rule, and having this field would help make redstone more intuitive and understandable. Readers wouldn't need to make mental leaps like 'Transparency = conductivity'. They could just read the infobox and see it put simply, and not get tripped up by mangrove roots or other exceptions.

It would be a simple Yes/No field called 'Conductive', with the title linking to the Conductivity article and the default value being Yes (or No, if there are more non-conductive blocks in the game). Some blocks, such as honey blocks, are conductive in Java Edition and are not conductive in Bedrock, so the field would need to be able to accomodate the version differences. Batbrain55 (talk) 10:50, 23 October 2025 (UTC)

👁 Image
 Support I don't know why nobody comments here after months. I don't see why not add them.

But if the goal is to remove ambiguity from transparency, we have much more work to do. Aloi4 (talk) 17:24, 12 April 2026 (UTC)

Recently on the Discord it was suggested that we implement a row for note block instruments, as well as one for sulfur cube properties. I'd like to gauge people's opinions on this here to better keep things organized. 👁 Image
Sightnado ^{t | c} 20:28, 22 March 2026 (UTC)

👁 Image
 Support both. 👁 Image
Sightnado ^{t | c} 20:29, 22 March 2026 (UTC)

👁 Image
 Support, good idea. For note blocks: Is that something automatable with a substring query, or would it have to be specified on all pages?  Nixinova  T ⁄ C  20:45, 22 March 2026 (UTC)

👁 Image
 Support for both properties. --Capopanzo (talk | contribs) 20:51, 22 March 2026 (UTC)

👁 Image
 Support both. –LauraFi - talk 22:26, 22 March 2026 (UTC)

👁 Image
 Support, I feel like this should be automated somehow though. Like the information is put on the sulfur cube and noteblock pages and then infoboxes pull from there. - Harri / Talk 👁 Image
00:58, 24 March 2026 (UTC)

Or like {{Map color}}  Nixinova  T ⁄ C  02:10, 24 March 2026 (UTC)

Or like {{Blast resistance values}} (using a module instead of a template). I think the second one is a bit more organized.

But I think it would be interesting to do it in a more automated way, using a for loop for similar blocks (stairs variants, etc.) instead of adding everything manually. Aloi4 (talk) 22:26, 10 April 2026 (UTC)

Actually a module would be ideal, since it could just use a Lua table that would look like the one on the sulfur cube page. Your for lip idea is overly complicated. Also you can't use stairs in sulfur cube.

.

Similar Lua logic for note block. I will right a module of no one else does. --   Simanelix   (T|C) 23:09, 11 April 2026 (UTC)

I have made Module:Note block values and Module:Sulfur cube values. --   Simanelix   (T|C) 01:12, 12 April 2026 (UTC)

This is very good. But remember that we have to use the page name for the automatic use of the infobox. For example, use Planks instead of Oak Planks because the Planks infobox will only read the page name. The block name should only be used in cases where we have to manually add the block to the field because the page lists more than one. As is the case with block of copper, both currently for map color and later for the instrument.

Won't be able to enable the option to write something like ['Sand', 'Gravel'] = 'Snare Drum'

You could make the module case-insensitive to make it easier to use manually. But possibly all the values ​​would have to be in lowercase. Aloi4 (talk) 17:46, 12 April 2026 (UTC)

Well, making it case insensitive and adding more options is easy. I'll get around to doing both of those. Probably it would be best to convert it to the lower-case-hyphenated format. So I'll make it do that with the block name variable. --   Simanelix   (T|C) 06:10, 13 April 2026 (UTC)

Okay. Now I've expanded the modules, making sure they work and adding all of the blocks listed on Note Block and Sulfur Cube, at least as far as I can tell. I might have missed some things. I also created corresponding templates and documentation. --   Simanelix   (T|C) 05:51, 15 April 2026 (UTC)

Are these ready for implementation? - Harri / Talk 👁 Image
21:21, 21 April 2026 (UTC)

There is still an issue that needs to be fixed: {{Note block values}} causes an error when given Block of Resin as its input. Aside from that it seems like it is ready for implementation. 👁 Image
Sightnado ^{t | c} 22:36, 21 April 2026 (UTC)

Fixed the issue (Bass was incorrectly defined and Bass Drum wasn't defined at all). I've implemented the infobox rows, hopefully nothing else slipped past. 👁 Image
Sightnado ^{t | c} 22:49, 21 April 2026 (UTC)

I have disabled the note block instrument row as the data there is severely incomplete. Someone with more time than I can dig through the code and get all the note block instruments of every block in the game. 👁 Image
Sightnado ^{t | c} 03:17, 22 April 2026 (UTC)

Wouldn't it be better to remove the automatic harp noteblock and leave it the same as map color? If it's not defined, it doesn't show up. Along with that, we could create a category to help, to find out which blocks were not added. Aloi4 (talk) 06:31, 22 April 2026 (UTC)

I would prefer not having to list almost every single block in the game in the harp section. --   Simanelix   (T|C) 09:38, 24 April 2026 (UTC)

Like, Java Edition's code? And try find all the values there? That could be a lot of work depending on how organized the code for note blocks is. --   Simanelix   (T|C) 09:56, 24 April 2026 (UTC)

Is it possible to disable the note block and sulfur cube rows on the Earth namespace without doing it manually? –LauraFi - talk 05:58, 26 April 2026 (UTC)

That is super simple. Just use the #if: parser extension and the NAMESPACE magic word. --   Simanelix   (T|C) 00:17, 27 April 2026 (UTC)

Done for mapcolor and noteblock rows.  Nixinova  T ⁄ C  00:27, 27 April 2026 (UTC)

Thanks! –LauraFi - talk 05:16, 27 April 2026 (UTC)

There's an error. Blocks like Gear that shouldn't have instruments shouldn't have space in the infobox. And April Fool's blocks that weren't documents on the notebook page should have a "?" unless someone confirms their instrument. These cases are incorrectly using the harp instrument. Aloi4 (talk) 01:36, 22 April 2026 (UTC)

But isn't the instrument for blocks like gears just harp? Or do some blocks (other than player heads) cause the note block to make no sound? Sorry but I'm not sure how the mechanic works. But Note Block#Instruments says that all blocks with no instrument default to harp. --   Simanelix   (T|C) 09:47, 24 April 2026 (UTC)

Harp plays if there is no block or a block that has no other instrument. The blocks do not affect the instrument at all, harp is not tied to them, so these pages should just say nothing. - Harri / Talk 👁 Image
13:25, 24 April 2026 (UTC)

At least in the Java code, the harp is defined as the default instrument. I think it should be included, but not automatically, because there are cases where the instrument hasn't been defined (new blocks, April Fools, etc.), and blocks that don't have an instrument because they never existed alongside the notebook. So there are three different things: harp, ?, (none). An analogy is the map color, which has the color
 0 NONE, which is also the default for blocks (in Java code), but we define the blocks that are none. This helps to separate blocks that we haven't defined a color for in the Wiki (like most of the 24w14potato), of those who are truly transparent. Aloi4 (talk) 23:10, 24 April 2026 (UTC)

Hold on, I'm super confused. What distinctions and who benefits from it?

• First off, you're saying both ? and (none) would result in no infobox row appearing at all, right? Because infobox row saying "Instrument ?" or "Instrument (none)" would be confusing in both of these cases: the case where note blocks don't exit in that version, thus making the instrument completely irrelevant; and the case where the note block plays the harp instrument. Since (none) definitely implies no sound at all. And ? implies an unknown sound. Which would we weird if we could test it. And would probably be irrelevant information if we could test it.
• Second off, you're saying there is a semantic difference between ? and (none). But what do either of those mean? Does ? mean we, as the wiki, just don't know? Does (none) mean a value is not explicitly defined, and therefore defaults to harp? And you're implying that in the actual code, some blocks explicitly lit harp as their instrument. Can we get a list of those please? And most importantly, what would we do with the infobox if they did explicitly list harp? Would we list "Instrumet harp" on them to indicate that the code is using a defined value rather than a default value? Even though that makes no difference in gameplay. Amd we could only say it does that in Java Edition, right? So now we're putting weird trivia about Java Edition code in the infobox? Like why are we doing that?
• Third off, is it confusing to list "Instrument harp" on every other block page? Because I do think that sounds kinda confusing. Especially for removed blocks or blocks that were removed before note blocks were ever added. But it is also in a way not confusing because someone could go to the instrument section of Note Block and learn that harp is just the default instrument. Anyways, if you just wanna not list things using the harp instrument, that sounds very simple to me. Like I think we should do that.

@Harri you seem to be implying exactly what I was mentioning in the second point. That whether it is explicitly listed in the code is relevant. --   Simanelix   (T|C) 19:05, 25 April 2026 (UTC)

'?' already exists in some cases of the infobox; it should be placed precisely when the infobox is incomplete, motivating its completion. This already exists for Tool, Blast resistance, Hardness, Luminous, Transparent, Flammable and Catches fire from lava. Isn't it a value to save "does such a block have the instrument '?'", will only be placed '?' when placing an infobox from a block that should not be saved in the module.

The option to hide the infobox might also work. That's what's done with the unsaved color map.

Personally, it doesn't matter what you use; I only think it's wrong to use a harp for cases where there's no instrument or for cases we don't know about.

The difference between "none" and "?" is that "none" is for truly rare cases (blocks that never existed with noteblock). This happens more often with discontinued blocks. But perhaps there are some other exceptions (this infobox is used in blocks in the Chinese version, for example; I don't know if it has noteblock there.) "None" perhaps the best thing to do is simply not to display the line in the infobox.

The question mark is more useful than none, because in addition to having blocks that were not documented (April Fool's Day), these are useful when new blocks are added and the initial versions of the page don't yet have this information, or in the case of planned blocks.

It's not a Java code quirk; the harp is an instrument like any other, it's just the default. I mentioned Java because that's what I know, but I have no doubt that it's the same in BE. If most people think it's better to leave those three values empty, that's fine, but I don't see why we shouldn't add harps to the blocks that we know are harps (I only see a problem with adding blocks that came out before noteblock or in undocumented blocks.) Aloi4 (talk) 22:01, 25 April 2026 (UTC)

Okay, right. So you are suggesting making an explicit list of every block, including the ones that need ? and the ones that need harp. We don't need to do this for sulfur cube though, right? Since it doesn't have a weird default value? --   Simanelix   (T|C) 15:27, 26 April 2026 (UTC)

Gears were removed before note blocks were added, so they shouldn't have an instrument entry at all. --Capopanzo (talk | contribs) 13:59, 24 April 2026 (UTC)

Another issue I've found is blocks that cannot be placed on noteblocks, like flowers, are showing Harp too. We should really just not show harp at all, block placement does not affect the instrument and we're misleading people into thinking that these blocks are the reason for the harp sound. - Harri / Talk 👁 Image
11:54, 27 April 2026 (UTC)

I've changed it to 'Default (Harp)'; is that less misleading?  Nixinova  T ⁄ C  10:36, 28 April 2026 (UTC)

Right, yes. I think that is the most reasonable solution. --   Simanelix   (T|C) 16:32, 28 April 2026 (UTC)

👁 Image
 Support 👁 Image
amethyst_hhh👁 Image
01:21, 24 March 2026 (UTC)

👁 Image
 Support and here is what I think it should look like: User:Simanelix/Sandbox/Infobox example. --   Simanelix   (T|C) 18:04, 10 April 2026 (UTC)

👁 Image
 Strong Support The note block, I was even planning on having surgery for that; I even had a slight feeling that it already existed, only to find out that it didn't.

👁 Image
 Support Sulfur cube property. Although I find it slightly less important for Java, since ideally this information is already in the data value (because of the item tags). I'm not saying it's not important, just a little less so. It's possibly equally important for BE. Aloi4 (talk) 22:21, 10 April 2026 (UTC)

You're going to have surgery done on you because of the Minecraft Wiki? That makes no sense. --   Simanelix   (T|C) 01:13, 12 April 2026 (UTC)

I would say that I was thinking of suggesting this before.

I mixed up the words, sorry. Aloi4 (talk) 23:37, 13 April 2026 (UTC)

Considering the class BlockBehaviour.Properties (see here), there are some properties that are not in the infobox. I will list them all, say whether they are there or not, and give my opinion on how to implement the missing properties.

Properties	This is in the infobox?	Note
mapColor	Yes (Map color)
hasCollision	No	I believe it's important. Using a term like "collision" (and not "solid," which causes confusion). In collision box there's information about the blocks like that. I believe the values ​​can be "No," "Yes," or "Partial."
soundType	No	Neutral opinion. This information is already in the sound section, but it's a large table. Here it would only be sound type, which would only be one or two words. It's not a substitute for the sound section!
lightEmission	Yes (Luminous)
explosionResistance	Yes (Blast resistance)
destroyTime	Yes (Hardness)
requiresCorrectToolForDrops	Partial (tool)	Edit: Read the comments. There was incorrect information here. My current opinion is to allow scissors and swords to have "any" for use in the cobweb and change the tool from "None" to something more specific (like "no drop" for Reinforced Deepslate, and "unbreakable" for Bedrock) which are theoretically "Any" and leave "none" for very specific cases like copper trap. Unbreakable also doesn't drop, in reality it doesn't even have a loot table (unlike Reinforced Deepslate which has an empty loot table).
isRandomlyTicking	No	Currently, I don't see the need to add that. But I haven't analyzed it yet, so I might change my mind.
friction	No	It differs from 0.6 only for ice, slime block, packed ice, frosted ice and blue ice. I don't see why you shouldn't make it a hidden category and only show it to those blocks. But you would have to create the page friction.
speedFactor	No	It differs from 1.0 only for soul sand and honey block. There are very few cases. I have a neutral opinion; I would add it as optional and only include it in those two blocks.
jumpFactor	No	It differs from 1.0 only for honey block!! Perhaps I could take the last three properties and put them in a single section. But I don't know how it would be organized...
id	No	This value is already in the date section. Although I'm not against having it more readily available in principle, I believe that in the case of multiple blocks per infobox, it would only hinder rather than help.
drops	No	I believe this could be an interesting discussion. The problem is that some drops aren't easy to write in a few lines, and there's already a section for that. Anyway, I think if we were to discuss this, we could also discuss adding this feature to mobs.
descriptionId	No	I see no need for it whatsoever. This is what's called the "Translation key" in data usage. I don't see why anyone would want information about this at the top of the page.
canOcclude	Partial (transparent)	Although it already exists, it's wrong in some cases and I think it can be revised. For example, in wooden fence transparent it's set to "yes" when in reality it does obscure the faces of the blocks, but only the faces of smaller blocks. Furthermore, this is being mixed up with the ability to block light directly from the sky, which is actually a completely independent property. If you argue that stating that fences, for example, are partially transparent is not a good thing, then at least we can agree to change the name or move the page to reflect transparency since Opacity defines opacity correctly at the beginning? In reality, the opacity page is a bit messy too.
isAir	No	Completely unnecessary. In Java there are three blocks with this property, but they are all on a single wiki page air
ignitedByLava	Yes
liquid	No	It is satisfied by water, lava, and bubble column. The first two cases are trivial, but the last one is not. I don't know how it is in BE. In any case, if something were to be changed, it could be in the text of the bubble column page and not in the infobox. In any case, I believe there needs to be a reformulation to stop calling the water and lava block "fluid" and start calling it "liquid." Fluid is something that only exists in Java and is entirely separate from a block. Liquid, on the other hand, is a class of blocks.
forceSolidOff	No	This is discussed here Opacity/Placement#Solid block. Maybe here Block properties/Solid (legacy) too, but I might be confused. It's a somewhat counterinductive concept, but because there are many ways to call a block solid or not, and this can have many effects on the game, it might be interesting to have this information clearly placed in the infobox so that when we have to mention blocks with this property in the middle of the text, we don't have to make a list but rather use a name that an active reader may already be familiar with from seeing infoboxes.
forceSolidOn
pushReaction	No	I'm very much in favor. It might be information that a lot of people would like to know, and I see it fitting easily into a specific line of reasoning.
spawnTerrainParticles	No	I don't see the need. Apparently it's just a visual effect and only the barrier and structure void aren't satisfied. It also seems redundant to consider this property because barrier won't show this effect since it has an invisible render shape.
instrument	No	YES. It has been suggested before and many people approved. Although it hasn't yet...
replaceable	No	Since it's something hidden, I don't see it because I don't see it. Look User:Aloi4/test/3#Replaceable Blocks
isValidSpawn	No	I don't know. I'm starting to get tired of researching all the properties, lol. Maybe I'll edit my comment later when I have an opinion on this.
isRedstoneConductor	No	I approve. This has already been suggested and no one has commented.
isSuffocating	No	That might be interesting...
isViewBlocking	No	I don't know. (see isValidSpawn)
postProcess	No	I don't know. I don't even know what that is. (see isValidSpawn)
emissiveRendering	No	I don't know. Possibly not (see isValidSpawn)
dynamicShape	No	I don't know. Possibly not (see isValidSpawn)
requiredFeatures	No	This is for a block that is only active with certain experiments. Currently, this could be useful for the BE. It would be redundant information since there's already a template to indicate that the page content refers to an experiment, but I don't see a problem putting it here as well. It would only be on a few pages and temporarily, depending on the user's intention to read the infobox and then open the page; it might be important to have this information there too.
offsetFunction	No	I don't know. I don't even know what that is. Possibly not (see isValidSpawn)

I was going to write more things later... But this comment is already quite long, so it'll have to stay like this. Aloi4 (talk) 00:54, 11 April 2026 (UTC)

I discovered that the Chinese wiki already has a lot of this properties. I haven't analyzed everything that's there, but I think it's a good benchmark that it worked.

Another thing it has is that it separates the sections into items and blocks. Something I totally approve of, but I know there are people who are against clickable interfaces. Aloi4 (talk) 01:46, 11 April 2026 (UTC)

requiresCorrectToolForDrops is not needed, since the rule about pickaxes is basic game knowledge. Repeating basic game knowledge like that on every page on the wiki would be bad. --   Simanelix   (T|C) 01:11, 12 April 2026 (UTC)

It's not pointless information because not all blocks with the pickaxe as the preferred tool require it for drops (e.g. pistons or rails, which don't require a pickaxe, vs stone). Still, this is already covered by both the infobox (empty tool outline if a tool is not required for drops) and by the breaking table. --Capopanzo (talk | contribs) 01:18, 12 April 2026 (UTC)

The truth is, we already have the case of the stomps, we just need to change it a bit for cases like coweb then. Maybe put a stone sword instead of empty.

There's the very specific case of the iron trap and copper trap. Technically, "none" is correct, but "none" is already used for cases where "any" would be used without a drop. Perhaps you could change "none" to "without drop" or "unbreakable" to be more precise, and it would still be functional. Aloi4 (talk) 01:45, 12 April 2026 (UTC)

Good point. Could you add just for exceptions?

• If the tool is a pickaxe, and not requiresCorrectToolForDrops: We have to inform (I don't remember if there's a case like that)
• If the tool is not a pickaxe, and requiresCorrectToolForDrops: We have to inform. This is the case of cobweb (I had forgotten about it). Even the cobweb tool tooltip has incorrect information, saying it can be broken with any tool.

But we could add this to the previous tool field instead of creating a new one. Aloi4 (talk) 01:33, 12 April 2026 (UTC)

Blocks that have the pickaxe as the preferred tool but do not require it for drops (e.g, pistons and rails) already use an outlined pickaxe in the Tool row, while blocks that require a pickaxe show an icon of the lowest tier required (e.g. a wooden pickaxe for stone and an iron pickaxe for diamond ore). Other than shears, the only blocks that require a non-pickaxe tool are snow and snow block, which show a wooden shovel instead of the shovel outline other blocks like dirt or sand use. This information is also already provided in the breaking tables, which use a red background when the required tool is not used. --Capopanzo (talk | contribs) 01:44, 12 April 2026 (UTC)

Thank you for showing me the exceptions and how they already have information. I think only cobweb is currently wrong (it should remove the 'any' from the scissors and change the sword to wood), and 'none' could be more precise. Aloi4 (talk) 01:49, 12 April 2026 (UTC)

Swords are fine as outlines because block mining is not affected by their tier. The "any" text on scissors is unintentional and should definitely be removed. Capopanzo (talk | contribs) 01:51, 12 April 2026 (UTC)

There's also an 'any' on the sword that needs to be removed. I thought about putting wood on it for the same reason as the shovel, but it doesn't really make sense because it doesn't have a tier. Although I think it should combine with {{breaking row}} (change one of the two). Aloi4 (talk) 02:03, 12 April 2026 (UTC)

Actually, thinking about it more, I'm against using outlines on swords. In all contexts, outlines function as "optional tool", so why not on swords? The only place that should possibly change this is the cobweb, and it would become much more intuitive. The wooden sword would be more of a symbol of swords than an indication of tier. It would be much less confusing. Aloi4 (talk) 17:33, 12 April 2026 (UTC)

I think we should add a collision field. It could be simple, like "full block", "partial block", and "none", rather than the obscure number information in Hitbox#Collision box.

.

The sound data is really just 1 or 2 IDs, and all IDs belong in the data values section. I think we should avoid putting IDs and stuff in infoboxes.

.

After reading through the list I see no reason the rest of these should be listed, except instrument and requiresCorrectToolForDrops as already discussed. --   Simanelix   (T|C) 19:16, 25 April 2026 (UTC)

The sound type is not always the ID of the block in question. It is almost always the ID of some block, but many blocks share the same sound type. Thinking about it, if you include a block with wool, the ID wool doesn't currently exist (only [color]_wool), But there is sound type wool. In BE is cloth.

In any case, it's not literally an ID, it only shares the name; things that use technical names are already in the infobox, like the map color, which even uses the variable name from the code. Aloi4 (talk) 21:42, 25 April 2026 (UTC)

What if instead of trying to add these to the infobox, we had a Block properties section in articles similar to a Data values section. I imagine something like mob data values where most of the info is collapsed except for values that are specific to that mob (see Creeper#Entity data for what I mean). For blocks, the uncollapsed part could be for the values that differ from the default values. Rampage455 (talk) 22:01, 25 April 2026 (UTC)

That could be interesting.

There are some discrepancies in your comparison, as these properties are not saved when the world loads like they are for entities. But I believe that creating a section like this might be the best place to these properties are not very important to highlight, especially for placing hitbox information (which, even though important, are difficult to describe in a few lines).

Although I don't know what the section name would be (hitbox information, even though it's somewhat influenced by these priorities, has other influences, (and it seems a bit strange to call the infobox format a "property")

Something I think you could add is technical information about the model. But this could be added directly to the data section with coplased JSONs. Aloi4 (talk) 22:14, 25 April 2026 (UTC)

Yes! We could really use some technical information about blocks and mobs, like hitbox information and anything not covered in block entity / ID data. For hitboxes, we should make the info more verbose, rather than using the overly concise and confusing information on Hitbox. --   Simanelix   (T|C) 01:39, 28 April 2026 (UTC)

Like we could have verbose redstone info, or a link to the page explaining how redstone conducts. This would sometimes be duplicated info with the Usage section, but Usage sections are sometimes a bit hard to read. A redstone person might get used to checking Data values instead. --   Simanelix   (T|C) 01:42, 28 April 2026 (UTC)

👁 Image
 Agree - We should specifically have a Block properties subsection of Data values. --   Simanelix   (T|C) 01:39, 28 April 2026 (UTC)

I don't understand the goal of this discussion. If you're proposing some more rows be added that's kind of hard to tell amongst the twenty or so "this probably isn't needed". Please make more specific and succinct proposals. - Harri / Talk 👁 Image
11:58, 27 April 2026 (UTC)

It is an evaluation of whether he thinks each of the poperties would be good to add. And as he said, most of them don't seem good.

It is not a proposal. --   Simanelix   (T|C) 01:30, 28 April 2026 (UTC)

Retrieved from "https://minecraft.wiki/w/Template_talk:Infobox_block?oldid=3552505"