Minecraft Wiki talk:Community portal/Archive 28

Color disambiguation pages
The result of the discussion was  delete.

* Black
 * Blue
 * Brown
 * Cyan
 * Gray
 * Green
 * Light Blue
 * Light Gray
 * Lime
 * Red

I propose that such disambiguation pages are deleted because:
 * 1) They are, in most part, template-like collections of color variants of dyeing-related objects.
 * 2) They claim to be lists of objects having a certain color, apparently only applying to an explicit connection with the said color (so for the purposes of such pages, bedrock is not black, lapis lazuli blocks are not blue, and prismarine has no color). If the pages would also list blocks having primarily some color, this may create controversies regarding ambiguous color classification. (Note that I don't believe it's meaningful to involve resource packs as a means to refute this point, as resource packs may not have the dyeing/color system in a form similar to the original game.)
 * 3) In most part, they represent an artificially constructed category with little value to players. If we wished to provide an easy way for players to e. g. select objects for their color during construction or similar purposes, a page (tutorial?) on in-game color design could be useful; I don't believe simple disambiguation lists are helpful for this purpose.

Any feedback on this? --AttemptToCallNil (report bug, view backtrace) 08:22, 4 January 2020 (UTC)


 * . -BDJP (t 08:27, 4 January 2020 (UTC)
 * . A tutorial would be much better. -- Hatsuki kiri 〔 T 〕 08:41, 4 January 2020 (UTC)
 * . I actually got confused when I knew their existance.-- LakeJasonFace.png Lakejason0  (Talk • Contribs) 08:48, 4 January 2020 (UTC)


 * removing them. They seem kinda useless. The page names could also re-redirect to dyes. -PancakeIdentity (talk) 08:59, 4 January 2020 (UTC)


 * Recommended removtal. This kind of meaningless and controversial disambiguation page is better not to appear. -- HlDorəmonWf (TAlK · C0NTR1BZ) 09:03, 4 January 2020 (UTC)
 * For example, the Red page lists all red-dyed features, which is already documented on the Dye and Red Dye pages. There is no point redirecting because if a user searches, the Red Dye page will show up. With the Village and Pillage dyes, this holds for all 16 colors. The BlobsPaper.png 14:21, 4 January 2020 (UTC)


 * : the search function does a better job of getting you pages about Red (and so forth), but automatically. – Sealbudsman talk | contribs 15:39, 4 January 2020 (UTC)


 * Useless pages –Capopanzone (talk | contribs) 00:39, 7 January 2020 (UTC)


 * We can almost certainly re-redirect/delete these pages at this point. -PancakeIdentity (talk) 01:07, 9 January 2020 (UTC)

Gravatar machine broke
The result of the discussion was cannot fix. Gravatar is outside our control and this discussion has been inactive for a while.

Is it just me, or is my icon still blank? I have my Gravatar set up (and have for a very long time), and yet my user icon is still the default grey person. -- DigiDuncan! (talk) 01:45, 16 January 2020 (UTC)


 * Yeah, it took a long time to finally work for me. Not sure how I fixed it tbh. -PancakeIdentity (talk) 04:42, 16 January 2020 (UTC)

Template AutoUnsigned
The result of the discussion was template deleted and replaced with a gadget.

So, as you may have noticed, no longer works as of a recent MediaWiki update. I was using a (somewhat hacky) approach to fetch the last user to edit the page, and now that approach has been "patched" to return the current user making the edit.

Since it appears it is no longer possible to make that template work using wikitext, I implemented an alternative using JavaScript at User:KnightMiner/autosign.js. The script adds a button to the editing toolbar under Advanced > Insert to insert a filled out Unsigned. It works fine in my testing so far, but I would like additional testing; if well received, I would like to make it into a gadget then delete. So, does anyone support or oppose this as a gadget?

As a couple notes on the script, the first thing is it does not currently support the classic toolbar. I would have added support, but I cannot find the option to switch to that toolbar to test it. The second note is it would be possible by changing the script to autosign comments from older revisions than the latest, though not sure if we can add a good enough interface to that to make it worth it. – KnightMiner  · (t) 20:25, 6 January 2020 (UTC)
 * The template was very useful because I would not need to keep checking the IP address and timestamp. The BlobsPaper.png 23:25, 6 January 2020 (UTC)


 * The template still works if you subst it, go into "Show changes", and copy-paste the added text.  Nixinova  T  C  23:47, 6 January 2020 (UTC)


 * I haven't been able to get the button to show up after adding the import line to my common.js; the Advanced > Insert section just shows the gallery, redirect and table buttons. I tried changing the Editing > "Enable the editing toolbar" and Gadgets > "Show extra buttons on the classic toolbar" options in preferences, but neither of them seem to have an effect on the toolbar. – Sonicwave talk  06:12, 9 January 2020 (UTC)
 * The existing gadget is unrelated. It appears the javascript function  no longer exists.  can you shed any light on if that is intentional?
 * You should be able to fix this using, of if you are lazy you can copy the   function and use that in place of  . – KnightMiner  · (t) 05:25, 10 January 2020 (UTC)
 * Fixed, it seems to work when testing it in Special:Diff/1485234 and Special:Diff/1485236. I would support this as a gadget; for the idea of signing older comments, maybe clicking the button could show a popup window where you'd input the diff ID of the unsigned comment. – Sonicwave talk  07:13, 10 January 2020 (UTC)


 * That would certainly be possible, but I feel like if you can copy and paste the diff ID, it would be just as easy to copy and paste the username and timestamp. I guess timezones would be a bit annoying, so maybe we should add a timezome parameter to unsigned2 so it can automatically convert to UTC. – KnightMiner  · (t) 18:54, 11 January 2020 (UTC)


 * I tried to add this as a gadget at MediaWiki:Gadget-autosign.js, but it's not working. The actual gadget definition works fine for me (e.g. the gadget appears in the preferences), but when I enable it the autosign option doesn't appear in the toolbar. It worked fine when I directly imported your user script, so I'm probably making some dumb error that's simply due to me being a newbie to JavaScript.--Madminecrafter12 (Talk to me 02:15, 10 February 2020 (UTC)


 * Removed for now.--Madminecrafter12 (Talk to me 02:28, 10 February 2020 (UTC)


 * I fixed it, seems MediaWiki supports Javascript ES6 in user scripts, but not in Gadget scripts. We should probably delete the old template at this time since its broken. – KnightMiner  · (t) 06:30, 11 February 2020 (UTC)


 * Thanks, and done.--Madminecrafter12 (Talk to me 15:01, 11 February 2020 (UTC)

Emoji redirect pages
The result of the discussion was delete.

Redirect pages like 🐮, 🍗, and 😻 could be not helpful, since they are never used in any articles and not expected to work in the search bar. They may also violate Minecraft Wiki:Style guide since emojis are not good enough to be used as alternate or shortened names. Therefore, it is suggested that all redirect pages with an emoji title should be deleted. -- Hatsuki kiri 〔 T 〕 01:17, 27 February 2020 (UTC)
 * More than 99.9% of users would type exclusively alphanumeric characters and certain punctuation into the search bar. The BlobsPaper.png 02:14, 27 February 2020 (UTC)
 * They're completely pointless.  Nixinova</b> </b> T</b> </b> C</b> </b> 02:27, 27 February 2020 (UTC)
 * I don't think these emojis are actually useful, as they are usually displayed after users type the correct words. Then they will directly search these words rather than put an emoji into the search bar. MysticNebula70  (T/C) 02:33, 27 February 2020 (UTC)


 * - Can't see those being useful for the vast majority of people, and it'd create a lot of clutter given the large variety of unicode emojis. – Sonicwave talk  03:47, 27 February 2020 (UTC)


 * deletion and I don't think I need to explain why. - User-12316399 (talk) 09:01, 27 February 2020 (UTC)
 * I'm here just to support. Lê Duy Quang (Make some words | Contributions) at 9h05:30 – 5 | 27/2/2020 (UTC)
 * when I saw that I was confused and said what is this? Pneuma01 (talk) 09:13, 27 February 2020 (UTC)
 * I deleted all the emoji redirects.  HorseHead.png Gamepedia icon.png MarkusRost (talk) 10:10, 27 February 2020 (UTC)

A new method to verify stuff on Java Edition
PancakeIdentity recently introduced me to a tool on GitHub that can decompile and deobfuscate Minecraft JE using the official mappings. Thus this creates a new method of verifying information: just search for the related part in the codebase, instead of having to go into the game and snipe the right moment.

So far I have used the tool for a while and, even without the variables in the implementation code, I can understand things with little issues.

I post this here to encourage anyone, with a bit knowledge of Java and reverse-engineering, to clean up the Verify category.

Lê Duy Quang (Make some words | Contributions) at 6h28:36 – 6 | 21/2/2020 (UTC)

If you are capable of and want to contribute, assign yourself here. Lê Duy Quang (Make some words | Contributions) at 6h56:41 – 6 | 21/2/2020 (UTC)

Addition of experience amount in furnace recipes
The result of the discussion was merge.

There is a request dating back from... 11/2015 that the amount of experience is added to the smelting recipe UI. Only almost 40 months later has this been implemented by me and Pneuma01 as per lordmuzik848#0191's taunt. Stuff is currently residing in Smelting, Recipe table and UI modules' respective edit copies.

The modification is nothing more than the addition of a third argument. Below are some previews:

I bring this here to receive potential feedback and if everything is fine, merge the changes into production.

Lê Duy Quang (Make some words | Contributions) at 3h02:14 – 3 | 18/2/2020 (UTC)


 * This is definitely a far better form of presentation than it was back when I first requested this in 2015, since I doubt people would be looking in the infobox for experience information from smelting. I think there should be something that clarifies how fractional experience amounts work, though, maybe by mousing over the value itself. (Also, why the hell is the template below us?) - User-12316399 (talk) 13:05, 18 February 2020 (UTC)
 * I made some styling adjustments to the experience text, does this look better? --AttemptToCallNil (report bug, view backtrace) 21:47, 18 February 2020 (UTC)
 * Added a tooltip for fractional experience (thanks to tryashtar on Discord for additional input). --AttemptToCallNil (report bug, view backtrace) 22:20, 18 February 2020 (UTC)
 * Look at the lower examples, there are multiple recipes cycling and the tooltip just keeps appearing and disappearing very quickly. The tooltip also adds a dotted underline to the number, which makes it ugly. I recommend against the tooltip, putting the explanation into somewhere else suitable, like Smelting or Experience. Lê Duy Quang (Make some words | Contributions) at 2h51:38 – 4 | 19/2/2020 (UTC)
 * I have changed how the tooltip works. Now regardless of whether there is a fractional part, it will always explain upon hovering. Maybe a hyperlink to the detailed explanation can be added as well. I have also gotten rid of that dotted underline. Lê Duy Quang (Make some words | Contributions) at 3h11:47 – 4 | 19/2/2020 (UTC)
 * The dotted underline is added because the  tag was used. It is suggested it's better to use this tag with a   attribute whenever text tooltips are needed.
 * To my knowledge, animation cycling should stop on hover. It does for me. So your tooltip appearing/disappearing issue should not have happened.
 * Since you also reverted my styling change with no explanation, I am putting the matter to more discussion by all editors.
 * To all editors with an opinion on the subject: In this image, do you prefer the experience text styling like on the top example, or like on the bottom example? I think my version (the one on the top) is better aligned, has less unneeded space between the sprite and the text, and makes the font less blurred by applying its intended size. --AttemptToCallNil (report bug, view backtrace) 10:16, 19 February 2020 (UTC)
 * I have reapplied the 16-px font size and realigned things. The distance from the bottom of the result slot to the top of the number is exactly equal to the distance from the bottom of the number to the bottom UI edge. Also, the  is now only added if the orb is large enough. Lê Duy Quang (Make some words | Contributions) at 10h27:19 – 4 | 19/2/2020 (UTC)
 * Another thing about the tooltip is if it is applied to some frames and not to others, when the user intends to move the mouse there, the animator will have a chance to switch to a frame without the tooltip before the finish is reached by the cursor, creating an unpleasant experience to the users. This should be avoided in my opinion, so it's best to have the tooltip always present. Lê Duy Quang (Make some words | Contributions) at 10h33:42 – 4 | 19/2/2020 (UTC)

So whenabouts will this be added to the default template? I'm not seeing much opposition to this concept, so it should be ripe for addition. - User-12316399 (talk) 09:02, 27 February 2020 (UTC)

. Merged into the main things. Lê Duy Quang (Make some words | Contributions) at 13h04:28 – 5 | 27/2/2020 (UTC)

Proposed logo update
The result of the discussion was update the logo to the logo the Polish wiki uses.

See the file on the Russian wiki: the change is making the "Minecraft" text gradient-coloured as opposed to the current flat grey. Another note is that maybe we should also update the grass block texture/model to the Texture Update version. --AttemptToCallNil (report bug, view backtrace) 14:33, 12 November 2019 (UTC)
 * Update: the Polish wiki already has an updated logo. --AttemptToCallNil (report bug, view backtrace) 15:21, 12 November 2019 (UTC)
 * adapting the Polish wiki's logo. The gradient, while small, looks nice. And it just makes sense to use the Texture Update's grass block texture. -PancakeIdentity (talk) 02:55, 13 November 2019 (UTC)
 * per . The BlobsPaper.png 03:55, 13 November 2019 (UTC)
 * using the Polish logo. –Capopanzone (talk | contribs) 20:14, 18 November 2019 (UTC)
 * Marcelah (talk) 23:57, 19 December 2019 (UTC)
 * - seems like consensus says to update it. - User-12316399 (talk) 09:53, 17 February 2020 (UTC)
 * I'd rather see a language-neutral logo with no text for the "Wiki" part of the logo: something more along the lines of a grass block with a book and quill in front of it. DSquirrelGMGRASP logo.png &#120035;&#120031;&#120018; 04:45, 3 March 2020 (UTC)
 * PL:Plik:Wiki HiDPI.png  Nixinova</b> </b> T</b> </b> C</b> </b> 05:03, 3 March 2020 (UTC)


 * I don't see a difference, so I'm . --dr03ramos Piston.gif (talk) Admin wiki[pt] 13:49, 3 March 2020 (UTC)

How to report someone for vandalism
The result of the discussion was the issue was resolved.

U88888s keeps vandalizing pages. How to stop her? Dogquest (talk) 22:40, 6 March 2020 (UTC)


 * Already accounted for via #requests in the discord. - User-12316399 (talk) 22:41, 6 March 2020 (UTC)

Some changes I've made to infoboxes
<div class="boilerplate discussion-archived" style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">
 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

I've done some stuff to infoboxes today and felt like I should check in here and ask for other peoples' thoughts on the matter before I proceed further.


 * Template:Fluid

I've decided to create a new infobox to split off fluids into. This might be a bit excessive, since there's technically only three fluids in the entire franchise, but they do behave considerably differently from other blocks, and it's worth noting that they probably won't even be considered blocks anymore with the planned fluid split (assuming that actually ends up going through, of course). I've equipped this template with its own set of parameters specific to liquids, and it seems to hold together relatively well. See Water, Lava and Mud for examples.


 * Biome colorations in Template:Biome

I added some fields to the Biome infobox that record biome-specific plant, water, sky and fog colour codes. A test case can be seen at Badlands (I haven't filled in the details on any other infoboxes, though). While they fulfil their job I feel as though they take up quite a big chunk of vertical space, which I feel could potentially be alleviated by compressing all of these values into some sort of "Biome colors" title, collapsed by default but expandable, like what can be seen here. Are there any other thing whose colours/appearances vary by biome (I think fog is one, or at least it will be in 1.16), and should I even continue with this in the first place?


 * Splitting sounds and drops into their own sections

This is another thing I've considered doing for a while. I decided to give it a shot (see Anvil and Barrel) and want feedback on this way of setting it out. I thought that sounds took up a bit much space on some of the infoboxes, and also believed that there was much more that could be said about them in a dedicated section (i.e. their internal IDs, their subtitles, volumes, pitch ranges, and the sound type category thing you specify in playsound).

Drops is another thing I'm not really happy with being inside the infobox, since again, there's a lot more that could be elaborated upon that would end up clogging up the template were it kept in it, such as how many of each item it could drop with Fortune, different drops depending on tools, and other conditional stuff. A dedicated section for drops, roughly equivalent to the Obtaining section, seems like a better move. Granted, this may result in lots of trivial repeated information (Breaking a barrel with any tool drops a barrel.), but this shouldn't be too much of an issue. On the topic of drops and obtaining, I think we should try reformatting the Obtaining section to more closely resemble the French wiki's obtaining sections, since monotonous paragraphs of text are boring, harder to digest and retrieve information from, and are generally less pleasing to the eye.

Any thoughts on these? - User-12316399 (talk) 19:36, 30 September 2019 (UTC)


 * I've now split off all block and enchantment sounds into respective sections and removed the Sounds parameter from the infobox template. Eventually I'll complete items and then mobs as well. - User-12316399 (talk) 07:46, 3 October 2019 (UTC)

...and some changes I want to make
I've detailed in the section below my proposals for how these would be documented. With those moved into that new section, these fields would become redundant and could be removed.
 * Removing the Drops and Experience fields

I'm not sure these (numerical IDs, at least) should be documented within the infobox, since the plan appears to be to remove them and perform a flattening across Bedrock Edition for parity reasons. We could probably keep the namespaced IDs there, though, since those will be official for as far as we can see going forward. Numeric IDs will still be kept in their own section. I'm also not sure about tags, these could probably also be relocated to a more technical section lower down.
 * Removing data values


 * Currently underway. - 23:51, 5 March 2020 (UTC)

Certain blocks are more flammable than others, should the values for them be documented in the Flammable row?
 * Flammability values

These are already documented in the very first section of most blocks, so do they really need to be documented in the infobox? (I do feel as though the section in question is rather incomplete in itself, and could do with more info such as the effects of Haste, Efficiency, and different tool types, as only listing unenchanted tool times feels very incomplete.)
 * Removing the tool fields

Now that we've relocated a bunch of block info to dedicated sections where they can be described in further detail, is there anything we could replace them with in the infobox that doesn't need much further elaboration? Two that come to mind are how much they slow entities passing through them (the value we'd show here would be the number they multiply entity movement by), and how slippery the block is (this only applies to a small set of blocks, though).
 * Add more parameters

Any thoughts on these ones? - User-12316399 (talk) 09:36, 1 October 2019 (UTC)


 * We should keep numerical IDs until the flattening. The BlobsPaper.png 13:59, 1 October 2019 (UTC)


 * Should they be marked as Bedrock Edition exclusive as to not cause confusion? - User-12316399 (talk) 14:37, 1 October 2019 (UTC)


 * I'd support that. Make sure to use the  tag. -PancakeIdentity (talk) 01:45, 13 October 2019 (UTC)

Replies
I feel like you should have copied the templates into your sandbox and made changes to them to see if they really work and fit. "Editing in production" has a risk of ruining pages. Lê Duy Quang (Make some words | Contributions) at 9h58:44 | 1/10/2019 (UTC)

Regarding sounds, what would go under "Pitch, Volume, and Min. volume"? The default sounds.json file does specify volume and pitch for some of the sounds, but all of the sounds already have different pitches and volumes anyway, so in my opinion this wouldn't make much sense for a casual reader. I can see the "source" column being useful (though it would be better renamed "category", "type" or "volume setting"), though that would require reading decompiled code since categories are no longer specified in sounds.json since 1.9.

Also, we should probably amend Minecraft Wiki:Style guide/Features to specify where the sounds section should be placed within the article. – Sonicwave talk  05:48, 5 October 2019 (UTC)


 * Those parameters are pretty much completely ripped off from the playsound command with no real knowledge of how they work. However, it's definitely possible to see that pitch is definitely one worth noting - glass breaking sounds and piston sounds are always lower pitched than their default values from the command, and some sound sources have variable pitches, such as sheep (and don't forget that baby animals are affected).


 * As for where to put these, I've just been putting them before Data values or Achievements, whatever comes first. - User-12316399 (talk) 20:52, 5 October 2019 (UTC)

The biome colors definitely need to be listed somewhere. Any chance we could display what these colors actually look like? Also, I'm not sure about removing them from infoboxes, but I definitely support expanding the breaking time table/template to include Haste and Efficiency. -PancakeIdentity (talk) 01:45, 13 October 2019 (UTC)


 * I would to have colors inside infoboxes.-- skylord_wars (talk) 08:19, 2 December 2019 (UTC)
 * I am not sure about including Haste or Efficiency in breaking rows, ad it would make them too complicated. Even if we only show Efficiency for diamond tools and only show Haste for diamond tools with Efficiency V, that is 13 scenarios instead of the current 6. The Breaking page does a good job of explaining the times in these situations. The BlobsPaper.png 14:46, 2 December 2019 (UTC)

03/2020
A good amount of the parameters proposed for removal have now been removed from the infoboxes in question. There's a few more things I want to bring up:


 * Are there any more parameters people want added to specific infoboxes that I haven't yet mentioned?
 * I'm considering removing the Light source section from the Usage section of pages since most of the time it just pointlessly duplicates a single value shown in the infobox anyway.
 * Also considering moving information about a block or item's fuel value into the furnace as well, given it is just a constant value. This would also get rid of a section.
 * On some lesser-known infoboxes exist some parameters I'm not too happy with, since they include a very wide range of things: the Consists of section for structures, and the Blocks section for biomes, the former of which should already be detailed in the respective /Structure subpage, and the latter of which could probably be moved out into the main article body as there does tend to be a lot of whitespace to fill.
 * Biome-related colours have been made optional parameters on the biome infobox, which I disagree with, as they should be filled in for every biome as they indeed do affect every biome on Bedrock Edition at least.

That's about close to all I have to say on the matter for right now. - User-12316399 (talk) 20:36, 6 March 2020 (UTC)


 * removing fuel value and light source from the article bodies. I'm ok with it being in both the article and infobox, I just hesitate to hide basic functions of a block/item in the infobox. My general sense is that a lot of users tend to not read the majority of the infobox  as it tends to be largely technical stuff. It hides the information more, especially since it'd remove the header from the Contents section.
 * removing blocks section from the biomes infoboxes. Lots of info for what should be a smaller thing.
 * Related, I'd removing the "consists of" section for structures as it works great for some structures and terrain features (mossy boulders for example).
 * making biome colors mandatory (I think). If there's Java-exclusive biomes, would they need the biome color info? I wouldn't think so but I'm not too familiar with those pages. -PancakeIdentity (talk) 21:28, 6 March 2020 (UTC)


 * Surely for cases of Consists of that can be clearly described, either the name of the structure or the introductory paragraph would offer sufficient information as to make it redundant?


 * Maybe having mandatory biome colours could be a temporary measure, to make sure all pages without them filled in are added to a category, to make pages with them not filled in easier to find. Also, simply because a biome doesn't have exclusive colours doesn't mean it doesn't have colours at all, so noting both java's and bedrock's values would be beneficial even if java's would be a lot more boring.


 * I've got pretty much all of the values I could think of added to a test template, a few examples of these can be found at Template:User-12316399/Block/doc. Feedback highly desired. - User-12316399 (talk) 01:29, 7 March 2020 (UTC)


 * The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

About transparency and documentation of its behaviors
<div class="boilerplate discussion-archived" style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">
 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

The behavior of transparent blocks is extremely complex and there's not different "categories" like the wiki likes to say they are. Almost every block is unique in some way. I've been documenting placement behaviors (placing transparent blocks that require support on other transparent blocks) at Opacity/Placement. This page currently only covers Java Edition. The problem with this page is that the tables are very large, and it could very quickly get out of control if new blocks are added or the Bedrock information is included. In addition, the page is kind of hidden away. I'd propose some sort of on-page documentation for each transparent block's transparency behavior. This could also cover stuff like mob spawning, light levels, etc. However, I'm not sure the best way to go about this. I'd love some discussion, as the current way we deal with this is not very good. Thoughts? -PancakeIdentity (talk) 01:57, 12 October 2019 (UTC)
 * I agree that documenting a block's behavior on its article is the better way. Should we pick some articles to experiment with adding that information to them? --AttemptToCallNil (report bug, view backtrace) 07:39, 12 October 2019 (UTC)
 * It looks like Torch has a decent table on it. Maybe something like that? We could also probably just copy the shulker box/piston sections on Opacity/Placement to the shulker box and piston pages. -PancakeIdentity (talk) 17:03, 12 October 2019 (UTC)
 * Yes, something like the table on Torch – and with your improvements (good work on that) I'd even say exactly like that. Also agree on shulker boxes and pistons, I think this information should be on their articles. --AttemptToCallNil (report bug, view backtrace) 17:28, 12 October 2019 (UTC)
 * The other thing I was wondering is how to document how a free-standing block's transparency works (such as Spawner, Glass, Brewing Stand, etc). Right now, most just have something in the infobox, but this doesn't provide a lot of information. For example, glass and spawners being listed as being partially transparent leads to misconceptions about placement behaviors, spawning, etc. Should we make a new section on the pages dedicated to this? Maybe a "Transparency" section? I'm not sure. This could help trim down these placement sections, as if we say that all blocks can be placed on spawners on the Spawners page, it doesn't need to be documented everywhere else.-PancakeIdentity (talk) 17:44, 12 October 2019 (UTC)
 * I would support a transparency section. I am not sure why so many different properties of blocks are categorized as transparency, so we definitely need more information. For example, ice is transparent but polar bears can spawn. This means that ice would need to be considered opaque in mob spawning, at least according to the Bedrock Edition algorithm. The BlobsPaper.png 18:04, 12 October 2019 (UTC)
 * Yeah, the behavior is pretty complicated. Ice seems to act as an opaque block (aside from rendering), like glass and light sources. It just has a hard-coded behavior to not allow snow on it to keep ice environments clean. -PancakeIdentity (talk) 18:09, 12 October 2019 (UTC)


 * I've always found the non-light-related definitions of "transparent blocks" to be unintuitive (suffocates mobs, allows spawning, block placement etc.), so I would support documenting these behaviors separately. I might even support changing "transparency" to something like "light-blocking", since many "transparent" blocks aren't visually transparent (like chests). The table on Torch seems good, although I'm not sure if it would be better to have top and side placement in separate columns. – Sonicwave talk  18:48, 12 October 2019 (UTC)


 * I agree, it seems like an outdated community term. I think it's time we try to move away from it. And I'll try to split the top/side placement and see how it goes. -PancakeIdentity (talk) 19:24, 12 October 2019 (UTC)
 * . They should be different infobox params instead of being shoved into a footnote.  Nixinova</b> </b> T</b> </b> C</b> </b> 19:42, 12 October 2019 (UTC)


 * I think we should split it into rendering, light blocking, and mob spawning. Then the placement rules can be detailed elsewhere and not attached to any of these three. -PancakeIdentity (talk) 23:22, 12 October 2019 (UTC)


 * Those properties plus placement are not an exhaustive list. We would need information about chest opening, water currents, etc. This is more information than belongs in an infobox. I propose that we reserve the infoboxes for the properties that will affect the most players, and document the rest in a "Behavior" section. The BlobsPaper.png 00:07, 13 October 2019 (UTC)


 * I agree. However, with the chest example specifically, I think that fits better on the chest page and not each block's page. -PancakeIdentity (talk) 01:38, 13 October 2019 (UTC)


 * . Visual transparency should be moved to model as that page fits better.-- skylord_wars (talk) 08:30, 2 December 2019 (UTC)


 * There is already a page zh:教程/不透明度 about opacity in Chinese wiki, which is collected and collated by Chinese players. Different opacity is introduced here, and the transparency list in java edition is listed, except mob spawning. This may be useful and perhaps it can be translated to English. -Chixvv (talk) 09:53, 25 February 2020 (UTC)
 * In addition, 实体方块 does not mean solid block in Chinese, so don't be misled by machine translation.--Chixvv (talk) 09:59, 25 February 2020 (UTC)
 * Information on mob spawning in Java edition has now been added to the Chinese page. --Chixvv (talk) 15:23, 25 February 2020 (UTC)

I've accounted for different "transparency" block properties in my proposed block infobox overhaul, which can be seen here; please tell me if there's anything more that can be added. - User-12316399 (talk) 12:10, 7 March 2020 (UTC)

From Discord: Proper game rules and predicates regarding block placement
Summarizing a discussion that occurred just now on the Discord server in the  channel.

Discord server member tryashtar provided us with rather useful information regarding block placement. This clearly invalidates "transparency"-based descriptions of placement rules. (Note that this relates to JE exclusively.) Quoting tryashtar:

- pressure plates require the block below to have a rim (e.g. hopper) or center point on top (e.g. glass pane) - rails require the block below to have a rim - banners and cakes require the supporting block to be a solid material (materials should probably be documented somewhere) - bells and levers require the supporting face to be "full" - carpet just needs to be above anything but air - lanterns need a center point on top (if place on top) or below (if placed below) -- for example a lantern can hang below a down-pointing hopper but can't be placed on top - redstone dust requires a full face below, but is also hardcoded to allow hoppers

The "rim" and "center point on top" are apparently well-defined in-game predicates; for example, the center point is a 2x2 center square on the hitbox (not visual box) assuming the surface is a 16x16 square grid. Quoting try ashtar on the "rim", "It's a predicate that is created specifically by removing the entire center section from a full cube, leaving only the, well, rim".

In references to other placement quirks (by tryashtar): Sea pickles just check if the below block has a non-empty upward face Not a block but item frames are really interesting, they can be placed anywhere that doesn't intersect with their hitbox (and support block material must be solid (or a repeater/comparator))

By the same person, on leaves' exceptional behavior: Leaves are considered to have faces that are "full" but not "sturdy"

This rule-based system would probably be far better than exhaustive lists of compatible blocks. In addition, 3D wireframes have been proposed to be made for the predicates mentioned. --AttemptToCallNil (report bug, view backtrace) 21:33, 12 October 2019 (UTC)


 * The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Tutorial link on MediaWiki:Sidebar?
The result of the discussion was the proposal was implemented.

Tutorials, imo, is a very important page on the wiki and therefore is worth being linked to on the sidebar so that readers can access it more easily. I already brought this up on Discord and it got a lot of support, but since it's generally better to bring important sitewide discussions to the wiki I figured I'd do so. However, I don't intend to have a month-long discussion before any action is taken; if no one objects to this proposal I'll probably go ahead and add it in a few days.--Madminecrafter12 (Talk to me 22:13, 8 March 2020 (UTC)
 * For transparency purposes, the people who reacted with the support emoji on Discord (as of the time of this post) are User:Leduyquang753, User:Capopanzone, User:AttemptToCallNil, User:Dr03ramos, User:Sonicwave32, User:PancakeIdentity, User:Marinah, and User:Nixinova (a total of eight users). I stand by my reaction and implementing this addition. It wouldn't be bad if at least some of the other seven supporters also declared their support here. --AttemptToCallNil (report bug, view backtrace) 00:06, 9 March 2020 (UTC)


 * Reaffirming my . -PancakeIdentity (talk) 00:31, 9 March 2020 (UTC)


 * Support adding it to the sidebar under "Useful pages". – Sonicwave talk  00:25, 9 March 2020 (UTC)


 * adding it to the sidebar, whether under useful pages or elsewhere. I would be fine with adding it the same section as main page and community portal, but that section seems to be mostly for wiki editors rather than viewers. jahunsbe (talk) 00:41, 9 March 2020 (UTC)


 * While the primary purpose of this wiki is to give information, people also seek tutorials. The BlobsPaper.png 01:12, 9 March 2020 (UTC)


 * , sort of – as long as this doesn't get abused to link just any tutorial to an associated article. Some tutorials are more like intellectual exercises than instructions on building anything useful. ~ Amatulic (talk) 02:24, 10 March 2020 (UTC)


 * I'm not sure what you mean by "as long as this doesn't get abused to link just any tutorial to an associated article". All this would mean is linking to the Tutorials page from the sidebar so I'm not clear on where linking a tutorial to an associated article would be involved. Am I misunderstanding what you're trying to say or did you misunderstand my proposal? Thanks, --Madminecrafter12 (Talk to me 01:29, 11 March 2020 (UTC)


 * under useful pages.--Madminecrafter12 (Talk to me 16:58, 12 March 2020 (UTC)

Removing Tutorials/Cake farming
The result of the discussion was delete.

Hello,

I think that Tutorials/Cake farming is completely useless.

That page is just a summary of tutorials on sugar cane farms, milk farms, wheat farm and egg farms put together (tutorials which already exist). Moreover, cake is really not that useful, meaning it's kind of weird to have a special page on it.

So, I think we should delete it.

Any objections ? Sagessylu (talk) 15:11, 7 March 2020 (UTC)
 * You can only farm cake by farming the ingredients, which have their own pages. The BlobsPaper.png 16:30, 7 March 2020 (UTC)


 * based on above arguments. – Sonicwave talk  19:40, 7 March 2020 (UTC)


 * because it isn't what it pretends to be; there is no cake farm described there, in the sense of having something that automatically fills a chest with cakes. As such, it's redundant with the other tutorials it references. ~ Amatulic (talk) 02:22, 10 March 2020 (UTC)

OK, I think we are going to delete it, aren't we ? Could an admin do that ? Sagessylu (talk) 18:11, 17 March 2020 (UTC)

Version of the in template for upcoming?
The result of the discussion was the template was created. INUpcoming, inUpcoming, INUntil, and inUntil have all been created.

Should we make a version of the in template for upcoming? Right now, we always have to add it onto the end of sentences. This can make things confusing or hard to read in certain cases. A version of the in template would allow us to preface a sentence with the information that something is upcoming, leading to clean sentences and easier reading. -PancakeIdentity (talk) 05:24, 7 February 2020 (UTC)
 * So are you suggesting an "In Java Edition 1.16" format? I would this. The BlobsPaper.png 15:09, 7 February 2020 (UTC)


 * Yeah, exactly. -PancakeIdentity (talk) 05:55, 28 February 2020 (UTC)


 * I'm not so sure about this. It's just a small patch to a very large and wide problem on the wiki. How is the RESI project going? I'd be neutral to this suggestion, but I'd rather like to see larger solutions or more progress on the overall project. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 11:03, 9 February 2020 (UTC)


 * That project, while not fully done, is much less critical now that we have only 2 active versions that generally are working towards parity anyway. I think the best way to solve the remaining problems is through smaller solutions like this that increase article readability. And anyway, that project is about editions and not number versions, so this topic isn't completely relevant to that. The creation of this template would also allow us to use it in place of a standalone tag, such as in the description of recipe tables. -PancakeIdentity (talk) 05:55, 28 February 2020 (UTC)


 * , placing this info right at the start of a sentence would make it much more readable. --Capopanzone (talk | contribs) 11:29, 7 March 2020 (UTC)


 * If this would be part of the in template, maybe we could do something like or  which would become "in Java Edition 1.16" (or whatever version is next). Doing it this way instead of directly naming the version prevents it from being used in a style guide breaking way (mentioning old/already released version in articles) and would automatically put it on the radar for removal upon release. Thoughts? -PancakeIdentity (talk) 06:11, 8 March 2020 (UTC)


 * I'd prefer not to include the [upcoming] tag in that case; part of the reason I'd prefer an inline version (like what in does) is to communicate that information without an awkward tag. – Sonicwave talk  18:22, 8 March 2020 (UTC)


 * True, I was just thinking of an easy way to have it on the radar for removal once the full version releases. If we could make it so the use of this specific part of the template would do that anyway, I'd be happy not including the tag. -PancakeIdentity (talk) 19:20, 8 March 2020 (UTC)


 * doesn't seem too difficult. - User-12316399 (talk) 18:14, 8 March 2020 (UTC)


 * I have a bit of a mockup here. It's not totally done (not sure how to remove that nocat thing), but I think it should work once that's taken care of. I think and  could work as names for these templates. -PancakeIdentity (talk) 01:50, 18 March 2020 (UTC)
 * Created under those names. -PancakeIdentity (talk) 02:17, 18 March 2020 (UTC)


 * May I have a bit of detail for this thing so that I can try to contribute?
 * Why don't we just add a parameter to specify whether to capitalize or not instead of duplicating the template?
 * Lê Duy Quang (Make some words | Contributions) at 2h42:52 – 4 | 18/3/2020 (UTC)


 * I think that could work, but you should create a new topic for it because it'd apply to the original in templates as well. This new template is basically an in-line version of the upcoming template. Anywhere that an inline mention would improve readability, you can use it. -PancakeIdentity (talk) 02:47, 18 March 2020 (UTC)

Test and add new mood algorithm for cave ambience
The result of the discussion was inconclusive. This discussion should be had on the ambience page, and the info we have already seems good enough.

Hello, in java 1.16 snapshot 20w12a, new mood algorithm was added for cave ambience to make them play at better times. As I know, it works as this:
 * Mood algorithm is % number (0-100%) that increases when player is underground and/or in low light level.(?)
 * When it hits 100%, cave ambience plays.

Thats all info. Please someone test how it really works, i mean that first part, how depth and light affect it and then add it as upcoming part to the Ambience page. Thank you. Klusimo (talk) 09:16, 26 March 2020 (UTC)

Names for wood variants
The result of the discussion was do not change. Evidence in support of the change was weak, and the current name has been well adopted.

We've been using the names Nether Wood/Overworld Wood in most cases when the distinction is necessary. However, 20w13a added the  block and item tags. Should we change our naming system to be "Non-Flammable Wood" and "Flammable Wood"? The current system is only referenced by the code, and the proposed system is only referenced by tags, which is a step more visible but still not an official name. I also think the nether/overworld system might be a bit more immediately recognizable for the average user, but the flammable system better describes the functional differences.

What do you all think? -PancakeIdentity (talk) 20:56, 25 March 2020 (UTC)


 * Agreed Ma (talk)


 * I prefer "Overworld wood" and "Nether wood" as it's more recognizable for the average reader.--Capopanzone (talk | contribs) 00:38, 26 March 2020 (UTC)


 * 20w13a also contains the inconsistent name "#logs_that_burn" (why is there a conjunction in a tag name…) so I don't think we should make a decision just yet. <b style=background:#0800aa;padding:2px> <b style=color:white>Nixinova</b> </b><b style=background:#006eff;padding:2px> <b style=color:white>T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 01:44, 31 March 2020 (UTC)

Handling loot tables on the wiki: a proposal
The result of the discussion was implement for blocks. Later discussions have since reverted this change.

Currently the information on the wiki regarding obtaining blocks and items from entities and the like is a complete mess. It's pretty spread out and not consolidated into standardised sections like crafting and smelting information is. I propose that we fix this by having loot be handled much like recipes currently are.

Firstly, the Obtaining section would be split into up to four sections: recipes (for when the time is obtained through crafting, smelting and the like), loot (for when the item is obtained as a drop, from chests, fishing), trading (for when obtaining the item via trading), and other usage (filling and emptying buckets, filling and emptying bottles, filling bowls via milking and eating foods in bowls).

A proposal for how blocks would work: we should handle the "this block drops" and "obtaining this through drops" sections like we currently handle "usage of this as a crafting ingredient" and "obtaining this through crafting" sections:


 * on the block's page, the Usage#Drops section contains a small one-row table describing what the block drops under the following conditions: silk touch, unenchanted correct tool, fortune I, fortune II, fortune III, no tool or too low tier tool, correct tool II (if applicable e.g. shears on cobwebs)


 * on the desired block or item's page, the Obtaining#Loot section contains a template that calls for all blocks that drop this specific item when mined. it then displays that table in this section, including the entries that don't drop the desired item.

For example, here's how it would work with coal ore and coal:


 * Coal ore's drops are listed in the Drops section of the coal ore page in a table like this:


 * The coal page calls for all blocks that drop coal, and lists coal ore's table entry, showing players that mining with the correct tool will drop coal, and advising them not to use ineffective tools or Silk Touch as these do not yield coal.

Now I think entity drops should be handled in much the same way, but the problem with this is that entities have a lot more weird conditions where they can drop different stuff depending on how they were killed. We'd need to consider death while on fire, skeleton arrow kills, charged creeper kills, among other things, and there's even cases where mobs drop things without even dying, such as chicken egg laying, turtle scutes, cat and villager gifts, and we could go yet further with the yet more weird cases such as shearing. (In fact, this even extends to blocks somewhat, with berry bushes, pumpkin shearing and also the advent of beekeeping.) Naturally-spawned equipment on mobs throws yet one more spanner in these theoretical works, and I think these should be kept on a separate table from the rest.

Chest loot and fishing loot probably shouldn't be as difficult to do, but should be also put into a table format like the other obtaining methods.

There's a few more things I want to mention on this matter:


 * We could also move experience drops into this section, since they almost universally accompany all types of loot except chest loot.


 * Don't forget that mobs are also a thing that can be dropped as a type of "loot" (see infested blocks, turtle eggs, splitting of slimes), which could also be integrated into the table somehow.


 * If we include experience drops and mob spawning as parts of these tables, could we also have drops sections for projectiles? Thrown bottles o enchanting drop experience, thrown chicken eggs can drop chickens, and thrown ender pearls can occasionally drop endermites, so it might just fit in well, but this might be getting out of the scope of "loot". We could even consider explosions as a type of loot, but that's probably another step too far.


 * We should address blocks more or less informally when describing what they drop. For example, we wouldn't distinguish between what a  drops and what a   drops, since in casual gameplay those are the exact same thing despite having different block IDs. We would distinguish on different block states if they make a difference, such as wheat that's fully grown as opposed to wheat that's not.


 * As I addressed above, mobs can drop items without having to be killed first. Should we have separate tables for "mob loot from killing it" and "mob gifts from the living thing", or should they be merged together? If these are to be made separate, should we also have block interactions such as berry harvesting kept separate as well?


 * The template should be designed to merge a source block or entity if it can drop multiple different items, similarly to how consecutive identical major versions are merged by the History template. Here's an (incomplete) example table:


 * We'd have trivial self-referential cases, such as a section on the Block of Redstone page saying that breaking a Block of Redstone drops a Block of Redstone, and another section on the same page saying that a Block of Redstone can be obtained by breaking a Block of Redstone. I really don't think that's anything worth worrying about though.


 * Blocks and entities that don't drop anything should still have a drops section to be consistent with the rest, since most of the time (at least in the case of entities) they do still drop experience.

Any thoughts on this system? - User-12316399 (talk) 08:14, 1 October 2019 (UTC)


 * I sorta agree with the "Fortune" table, but it can be more visualized by generating a small graph in each cell (I will try to create a preview of this using HTML and CSS later).


 * For conditional loot, another type of table can be created:


 * {| class="wikitable"

! Loot type ! Dropped when... Drop conditions 5% chance. 1,25% chance.
 * Killed by a player.
 * Killed by a player.
 * Killed by a player.
 * Killed by a player.
 * Killed by a player.
 * Killed by a player.
 * }
 * }
 * }


 * If a condition is repetited multiple times, I think we can use color codes and a legend table.


 * If the chance involves Looting, we can embed a sub-table like the Fortune table.


 * About "entities" as "drops", from my point of view, I don't consider silverfish, small slimes,... as loot, they are special functions of the block/entity when triggered, thus they should be addressed as "special behaviors" or something similar.


 * Lê Duy Quang (Make some words | Contributions) at 8h29:26 | 1/10/2019 (UTC)




 * Here is the table I attempted:


 * [[File:Loot table proposal – Mining.png]]


 * Lê Duy Quang (Make some words | Contributions) at 9h48:08 | 1/10/2019 (UTC)


 * I would prefer to keep the non-enchanted versus enchanted options closer together, so if you switch Silk Touch with Incorrect Tool, that should be better. In your example Le Duy Quang, you're using percentage heights for each cell to represent their values. I don't know if I'd like that, as this technique is not used elsewhere on the wiki and would be inconsistent design. Not saying it shouldn't be used, but if not, it would look like this (please excuse resolution, I just messed around):
 * [[File:Loot table proposal2 – Mining.png]]
 * – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 11:36, 1 October 2019 (UTC)
 * As we're on the topic of percentages for each item count, I think this is a point worth considering. - User-12316399 (talk) 11:46, 1 October 2019 (UTC)
 * The behavior of the lowermost cell filling the rest of the column is just ugly and illogical in my opinion. At least in each column, distribute the height of each cell. Lê Duy Quang (Make some words | Contributions) at 14h05:35 | 1/10/2019 (UTC)


 * Here is the updated version of the table using my new template In-cell graph:


 * {| class="wikitable"

! Block !! Incorrect tool !! Silk touch !! Correct tool !! Fortune 1 !! Fortune 2 !! Fortune 3
 * }
 * }
 * }
 * }
 * }
 * }
 * }
 * }
 * }


 * Lê Duy Quang (Make some words | Contributions) at 14h02:55 | 1/10/2019 (UTC)


 * something like this. It looks nice, is informative, and gets across much more than the current single sentences we currently use in most situations. -PancakeIdentity (talk) 02:00, 12 October 2019 (UTC)
 * For complex pages like this, it is much advisable to use graphs or diagrams. But for others that's fine. We should draw a clear boundary whether to use tables or not.-- skylord_wars (talk) 06:47, 29 October 2019 (UTC)
 * Perhaps we could still have a table like that, but hidden by default, and a more simplified version displayed so the full information can still be accessed without cluttering the page up too much? Or would this just complicate the code even further? - User-12316399 (talk) 09:28, 29 October 2019 (UTC)

So how exactly will we sort the Obtaining section once this is implemented? I'm thinking something like this (although named differently):


 * Obtaining
 * Loot
 * Blocks (this section itself contains stuff like ready composters, ready berry bushes, and shearing pumpkins)
 * Block drops
 * Contained items
 * Non-mob entities
 * Non-mob entity drops
 * Contained items
 * Mobs (this section itself contains stuff like cat and villager gifts, laid eggs, shearing, etc.)
 * Mob drops
 * Mob equipment
 * Contained items
 * Fishing
 * Loot chests
 * Recipes
 * Crafting
 * Smelting
 * Blasting
 * Smoking
 * Campfire
 * Stonecutting
 * Brewing
 * Loom
 * Enchanting
 * Trading
 * World (items that can be obtained by changing an existing item, such as filling bottles and milking cows)

Are there any other notable categories I missed? - User-12316399 (talk) 12:00, 6 October 2019 (UTC)

I've transferred all smelting and mining experience drops from blocks and items into the main text of articles and removed the Experience field from the blocks infobox, in line with this Obtaining reform. I've requested a change to the Smelting template to better incorporate this information into the article (4 years ago, funnily enough). Would anyone be willing to implement this change (and also the newer one noted beneath it)? - User-12316399 (talk) 14:29, 9 October 2019 (UTC)

I might try setting up a couple of examples on images soon, but I don't have much knowledge about scripting so the pages for the items they drop won't be able to automatically read and display the information. Also, would people be okay with me removing the experience parameter from the entity template and moving said information to the drops section? - User-12316399 (talk) 13:26, 18 November 2019 (UTC)


 * Some examples can be seen on Coal Ore, Diamond Ore, Grass Block, Gravel and Hay Bale. The template seems to be acting up a bit, though, since the values are clipping into cells below. - User-12316399 (talk) 15:58, 18 November 2019 (UTC)


 * I'm not sure if we need every column on pages like Hay Bale. Could we do something else for cases like that? -PancakeIdentity (talk) 03:46, 19 November 2019 (UTC)


 * The """fix""" for the hay bale page is still awful. I don't think we even need a table in that case. The tables should just be used for blocks that can have different drops. -PancakeIdentity (talk) 04:49, 20 November 2019 (UTC)


 * Replaced with two relatively short sentences. Header renamed to "Drops": I believe "loot" would typically apply to defeated mobs or treasure containers, not broken blocks. --AttemptToCallNil (report bug, view backtrace) 08:03, 20 November 2019 (UTC)


 * the usage of ICG as it breaks completely on mobile. Something like the first table example is good though. Adding colours also isn't really necessary. <b style=background:#0800aa;padding:2px> <b style=color:white>Nixinova</b> </b><b style=background:#006eff;padding:2px> <b style=color:white>T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 23:16, 20 November 2019 (UTC)


 * The text linking to this discussion is now showing up twice on a large number of pages. It appears this is because it is both part of the template and manually noted on the pages. We should probably either get a bot to remove the text from the pages or remove it from the template and from the pages later. jahunsbe (talk) 20:10, 27 February 2020 (UTC)


 * We're aware, the text will be removed from the pages themselves when they get double checked, which should happen soon; new pages that get the table no longer should add the text directly. FVbico (talk) 20:18, 27 February 2020 (UTC)


 * That works too. jahunsbe (talk) 20:29, 27 February 2020 (UTC)


 * I've got my bot to remove those duplicate links. <b style=background:#0800aa;padding:2px> <b style=color:white>Nixinova</b> </b><b style=background:#006eff;padding:2px> <b style=color:white>T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 02:14, 29 February 2020 (UTC)

February 2020
I've went ahead and created a new template, Template:Experience, which should be better than the previous method for transcluding experience drops. Sooner or later I plan on moving all Experience and Drops information from infoboxes into their dedicated sections in the respective pages, and then ripping out the Drops and Experience parameters from the infoboxes themselves, so if anyone wants to comment on that do it sooner rather than later. After this is done all the information will be in their respective sections and will be ready to be organised into the new table format when we've all come to an agreement on that.

A lot of people seem to be taking issue with blocks that drop themselves having dedicated tables. I did mention this before, but nobody seemed to have any problems with it with it until the trial implementation. I do think they should still have dedicated tables in articles - they do have their own loot tables, after all - but for these trivial cases they should be collapsed by default as to not take up a lot of space with this bland information. Blocks that do have non-standard drops would be open by default. Of course, this would mean that we'd make the table template collapsible and expandable, which doesn't seem like much of a challenge.

Otherwise, everything looks to be just about fine, and it shouldn't be much of a problem to take the newly added netherite tools into consideration for these templates. Is anyone else willing to contribute anything? - User-12316399 (talk) 10:14, 17 February 2020 (UTC)

29/2/2020
There are some problems with the current  template:


 * For multiple cases of the same block, Namespaced ID and Source just repeat, example: Wheat seeds § Loot.
 * For the same loot but different amounts across multiple block states, there appears a boilerplate that also repeats.
 * There isn't a way to handle other factors affecting drops, such as Fortune.

Currently I am replacing some of the complicated loot tables (for example Pumpkin seeds) to temporarily not use the template until these issues are fixed. Lê Duy Quang (Make some words | Contributions) at 10h04:30 – 7 | 29/2/2020 (UTC)


 * Since when has the template not had a way to handle fortune? It's obviously there on all the applicable ore pages. - User-12316399 (talk) 12:08, 29 February 2020 (UTC)


 * The namespaced ID refers to the name of the loot table while source is the actual block. I don't see an issue there. And yeah, it handles fortune just fine already. -PancakeIdentity (talk) 16:40, 29 February 2020 (UTC)
 * If there are 8 cases, for example with pumpkin stem, then the Namespaced ID and Source will repeat 8 times. That's the issue. Lê Duy Quang (Make some words | Contributions) at 2h18:36 – 8 | 1/3/2020 (UTC)
 * Source should probably be able to repeat, with the block state value clarified as in Snow. It would probably be best if we could find a way to have Namespaced ID be merged into the same box though, and also would appreciate if we could do a similar thing with XP drops as well since having that be repeated also doesn't help. - User-12316399 (talk) 02:22, 1 March 2020 (UTC)

Reflecting after implementation
(Yes I know it's not fully implemented yet, but we've put it on most pages and we're getting there.) I've noticed a lot of complaints about the new system from myself and other users. Here's a bit of a summary:


 * It's a lot of space to convey simple information. The wood page, for example, is just a huge template to say "Wood blocks drop themselves." (Especially when lacking a summary such as described below).
 * Related, there's no easily readable summary for the loot. This is especially a concern with average readers who likely don't care about the nitty-gritty details, IDs, and percentages and just wanna know they can get (for example) 2-5 potatoes from a fully grown crop.
 * It's not mobile-friendly. These tables can get pretty big and be a pain to read through on mobile.
 * Lots of repetition. There just seems to be a lot of extra fat that could be trimmed from these tables.
 * Various parts don't look very good and/or aren't readable. These tables can just look like a big jumble of numbers

This proposal did get great support (from myself included), but I think it was easier when it was just coal ore. I support documenting all these details, but the issue is how it costs readability and accessibility. Ideas I've seen have included adding a simpler summary above the table and auto-collapsing the table. This would make the simple version accessible for those who only care about that and keep the tables from chewing up page space when they're large. Some have suggested this as well as moving the loot table names and stuff down to the Data Values section.

What are your thoughts and suggestions? -PancakeIdentity (talk) 01:49, 12 March 2020 (UTC)


 * I did have them collapsed by default when I started adding them, until I realised that all I had added up to that one point were basically one- or two-line tables that really didn't need to be collapsed by default given they took up barely any space, so I decided to leave them open. Of course, anything longer than about three lines with no unexpected drops is a candidate for being collapsed as to not take up extra space, whereas anything that length or shorter can probably be kept open for viewing by default. And summaries would probably be useful as well for basic info at a quick glance. - User-12316399 (talk) 02:01, 12 March 2020 (UTC)


 * (Unrelated, but since crafting recipes take up even bigger amounts of space, what's to say we can't have those be collapsed by default as well?)


 * I think auto-collapsed should be default with an option to change it to not auto-collapse.
 * Recipes are much more basic survival information, are easy to look at, and aren't filled with details the average person won't care about. And we actually do collapse them on some pages such as Dye. -PancakeIdentity (talk) 02:14, 12 March 2020 (UTC)


 * Some users on discord have suggested just saying the formula and distribution type instead of every single chance. I would support this personally. It keeps the huge cells of percentages from existing while still allowing the exact information to be accessed using an online calculator. -PancakeIdentity (talk) 21:12, 19 March 2020 (UTC)


 * For some cases it should be fine to keep the fortune chances in the loot table template (e.g. Gravel, Diamond Ore), while also mentioning how the percentages are calculated, but for bigger cases like lapis lazuli and nether gold ore I think having an external accompanying table would be a better option (collapsed by default if it's a nuisance). I think the rates should still be directly documented though, for Fortune 0-3, since I doubt anyone would go to the effort of actually calculating said rates, but the formula would still be there if anyone wanted to see what Fortune 743 would drop. - User-12316399 (talk) 21:57, 19 March 2020 (UTC)

Creation of Tutorials/Experience farming
Hello,

Experience is quite an important thing in Minecraft. However, experience farming doesn't have a tutorial page. I do know that there are quite a few farms that provide additionnal experience, but this page could list all the farms that are good at getting it.

Should we do it ? Sagessylu (talk) 18:57, 23 March 2020 (UTC)
 * I know many farm designs for Bedrock Edition, and can help expand such a tutorial. The BlobsPaper.png 21:30, 23 March 2020 (UTC)


 * Generally on wikis, you should be bold! Go ahead and create the article, there should be nothing wrong with it and community consensus is rarely needed for page creation. -PancakeIdentity (talk) 23:19, 24 March 2020 (UTC)

OK, thanks, I'll do my best ! To @TheBlobs : you're welcome, because I'm playing on Java Edition. Sagessylu (talk) 13:20, 4 April 2020 (UTC)

Loot tables and page organization
The result of the discussion was revert. The style guide changes and loot table template will no longer be used. Loot table IDs should be in the Data Values section. See Minecraft_Wiki talk:Community portal and Minecraft Wiki talk:Style guide/Features for more parts of this fragmented discussion.

So, you've probably noticed the changes that are being made to loot documentation and page organization. This section should act as a sort or combined discussion post implementation of the loot table proposal above, as well as this discussion on the style guide (which has been implemented despite a seemingly majority oppose).

So, what're the issues? Many are the same as discussed in the subsection above, though I'd like to focus on a few things.
 * The duplicate tables present on most pages under both "Obtaining/Loot/Block loot" and "Usage/Block loot". The first section is, in most cases, a duplicate or trimmed version of the second. This is duplicating information in the body article in a format most have agreed is not the most appealing. How should we resolve this?
 * Readability of the tables. The tables are big, ugly, and filled with numbers most people won't care about. They're almost completely unnecessary on pages such as wood where every block drops itself. The only reason they're kept is that this table also documents the loot table ID. Auto-collapsing the tables has been discussed, what else could be done?
 * The organization of the sections. The block loot and especially the breaking row don't feel like they belong under "Usage". However, the block loot doesn't really feel like it belongs under "Obtaining" either. How should we organize this info?
 * Section names. A few users expressed distaste towards the number of subheaders on the older style guide discussion. Are there still concerns over this that need addressing?

(Edit: Also discuss the possibility of displaying chances like on Lapis Lazuli Ore for pages that need it instead of using the template. In addition, should we use percents or fractions?)

Discuss these issues and any others you may have with the new template and/or page styling. There's been a lot of arguing over this (especially on discord) and not a lot of doing anything about it. -PancakeIdentity (talk) 00:13, 23 March 2020 (UTC)


 * I really do not like the repetitive confusing tables that are just a convoluted way of saying "X drops itself". The namespaces ID of the drops should be put in §Data values, not §Usage nor §Obtaining, and simple stuff like "X drops itself" is really unnecessary and will just confused readers into thinking it's more complex than what it actually is. The layout was fine before; stuff like this that affects all pages should be discussed on-wiki with many support votes first before being implemented, lordmuzik. <b style=background:#0800aa;padding:2px> <b style=color:white>Nixinova</b> </b><b style=background:#006eff;padding:2px> <b style=color:white>T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 01:37, 31 March 2020 (UTC)


 * I completely agree. I think there's nothing stopping us from moving the loot table names to Data Values, which would remove the only argument for using this template on most pages.
 * In addition, for displaying chances, a table like on Lapis Lazuli Ore could work. However, I would VERY strongly oppose using that table if we're gonna keep using the loot table template, as some users have attempted on Nether Gold Ore. PancakeIdentity (talk) 23:53, 31 March 2020 (UTC)


 * I agree with Nixinova, the layout was fine before. --dr03ramos Piston.gif (talk) Admin wiki[pt] 01:14, 1 April 2020 (UTC)


 * Unfortunately, I don't really feel like I have an opinion on the subject. :( --AttemptToCallNil (report bug, view backtrace) 01:59, 1 April 2020 (UTC)


 * At this point I'm all up for omitting the second instance of the loot table template (#Block loot) from pages entirely and instead linking to the upper section (#From block loot) in cases where both templates are completely 100% identical (e.g. Ancient Debris). Auto-collapsing the first (and therefore only) instance of "redundant" tables over a certain size (like bed) also seems like not a bad idea (non-trivial ones like Dirt would stay open though).
 * As for moving loot table IDs to the Data values section: horrible idea, especially since there's plans to also document recipe IDs for respective recipes alongside their unlocking methods, as those have gone pretty much undocumented since implementation, and having those present in recipe sections yet no loot table IDs for the loot section would be inconsistent and not something I can get on board with.
 * Readability shouldn't be an issue at all if there's a good enough sentence or paragraph above the loot template.
 * - User-12316399 (talk) 05:24, 1 April 2020 (UTC)


 * "...especially since there's plans to also document recipe IDs for respective recipes alongside their unlocking methods..." This has been discussed nowhere. Minor discussion has taken place about possibly including unlocking methods in the recipe template, though nothing has been decided and certainly no plans have been made. And, the IDs were never a part of that discussion. We shouldn't make a decision on a current issue based on a discussion that has quite literally never happened (or at the very least, has not been discussed in a visible place on the wiki). If you have other legitimate concerns about moving the IDs, please, enlighten us.
 * Also, "#From block loot" needs a rename. We shouldn't have prepositions in a header.
 * In addition, why not always auto-collapse the template if the description above is going to be duplicating the information anyway? The template in almost every case is either a) messy and/or b) useless to the average reader. -PancakeIdentity (talk) 05:53, 1 April 2020 (UTC)


 * Referring to some snippets from discord, probably no major on-wiki discussion about it yet. but there may be soon.
 * Auto-collapsing templates would be fine with me if the block either a) always drops itself regardless of tool or b) requires a certain tool/tool tier to drop, but always drops with it or above, and that there's no other different possible drops for it under any other conditions whatsoever (excluding containers dropping their contents). - User-12316399 (talk) 05:59, 1 April 2020 (UTC)


 * Again, we should not make decisions based on "some snippets from discord" or on wiki discussions that you think may happen. -PancakeIdentity (talk) 18:30, 1 April 2020 (UTC)

To address some of the concerns:


 * Duplicate tables: I've went ahead and created for pages about blocks which always drop themselves or require a tool to be dropped, and have no other unique behaviour regarding enchanting or experience.
 * Section organisation: I wouldn't be opposed to having the second block loot section be merged into the same section as the breaking row. Also, the reason most of the sections are prefixed "From" is to have the two block loot sections not conflict with each other when linking to sections (from edit summaries, etc), so if this section is merged in we could safely rename a lot of these sections and remove the From (but then we'd need to discuss how recipe types would be named - "Crafting output", "Smelting output", etc seem a bit janky, and I'm not fond of them being generically named "Crafting", "Smelting", etc. either)
 * Lapis Lazuli Ore/Nether Gold Ore drop chances: Personally I'm a fan of the format being used on pages like Nether Wart, so I'd be all up for going with that layout for said pages.

- User-12316399 (talk) 21:57, 8 April 2020 (UTC)


 * I think the top table isn't needed. The info can stay, but the whole table isn't needed since we link away usually anyway. Why aren't you a fan of just "Crafting"? It makes sense imo, as it's already under "Obtaining". There shouldn't be any confusion about what it means.
 * I would support moving the loot table IDs down to data values in combination with using a table similar to lapis or netherwart (lapis probably as it displays chances still). I also think the lapis table is more practically useful as we can display averages and such. I'd also support a more case-by-case basis approach with multiple table types to pull from, as I don't really think a "one size fits all" solution works here, with the variety of loot models minecraft follows. Doing it this way would also allow clean looking tables such as that on Fortune for weeping vines. -PancakeIdentity (talk) 22:53, 8 April 2020 (UTC)
 * 1. is a completely unnecessary template. 2. "Smelting" and "crafting" are fine, they get the point across simply. 3. I don't really like the format on nether wart either as got three nested column headers that at a glance seem overly confusing. <b style=background:#0800aa;padding:2px> <b style=color:white>Nixinova</b> </b><b style=background:#006eff;padding:2px> <b style=color:white>T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 20:57, 12 April 2020 (UTC)

Chunk Loading overhaul
<div class="boilerplate discussion-archived" style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">
 * The following discussion &#32;of a proposed Chunk loading is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * updated --TreeIsLife (talk) 21:12, 9 September 2020 (UTC)

Hello there. I noticed many community pages, videos etc. (outside of the wiki) talking about (often now older) changes to chunk loading like the 15 seconds chunk loading on the other side of Nether Portal after entity pass trought. And then i noticed that this wasn't even stated anywhere on this wiki.

https://gist.github.com/Drovolon/24bfaae00d57e7a8ca64b792e14fa7c6 This page very nicely states how new chunk loading works and i would like to distribute its information to pages like chunks, nether portal etc. overhauling and renovating them more or less.

And here comes the question...

Is that information real and up to date? Can anyone confirm or deny it please?

Thank you, have a nice day. Klusimo (talk) 06:12, 3 March 2020 (UTC)


 * Information about chunk loading is really needed to be added, and the content in that page you mentioned was obtained from the source code and is still not out of date.
 * And you know, these theories apply only to Java edition. ---Chixvv (talk) 15:44, 4 March 2020 (UTC)
 * Alright ill start punping these informations to pages, ill do it solo i can :D. As for the java vs bedrock, ill add more info needed and let bedrock players test it. Klusimo (talk) 09:05, 7 March 2020 (UTC)

Split in Tutorials/Cobblestone farming and Tutorials/Stone farming
<div class="boilerplate discussion-archived" style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">
 * The following discussion &#32;of a proposed Spliting cobblestone tutorial pages is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * not done. Also, next time, better duscussing this on Talk:Tutorials/Cobblestone farming. --TreeIsLife (talk) 21:25, 9 September 2020 (UTC)

Hello,

I think we should split Tutorials/Cobblestone farming between Tutorials/Cobblestone farming and Tutorials/Stone farming because the cobblestone farming is getting seriously big and also because there is "cobblestone" in the title and not "stone".

Does anyone oppose ? Sagessylu (talk) 19:00, 23 March 2020 (UTC)
 * I would keep them merged, since any stone generator can be used as a cobblestone farms by using a pickaxe without Silk Touch. Conversely, you can use a cobblestone farm as a stone farm by smelting the cobblestone. The BlobsPaper.png 21:29, 23 March 2020 (UTC)


 * In the future, discuss splits and stuff on those pages. There's not really a need to discuss it on the Community Portal. -PancakeIdentity (talk) 23:18, 24 March 2020 (UTC)

@The Blobs : Well, that's a good thing to point out. Something still needs to be done to make this page clearer though.

@PancakeIdentity : I actually already did that, but I did not receive a single answer in a whole month. Not a lot of people seem to look at tutorials talk pages (which I can perfectly understand by the way) : it looks almost impossible, in my opinion, to discuss splits and stuff on these pages, and that's why I put that here. Sorry for the inconvenience :-D Sagessylu (talk) 13:30, 4 April 2020 (UTC)

"Recent wiki news" section of the community portal
<div class="boilerplate discussion-archived" style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">
 * The following discussion &#32;of a proposed New section on Community portal is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * Done --TreeIsLife (talk) 21:28, 9 September 2020 (UTC)

It is currently unclear what is to be included under the "Recent wiki news" section of the community portal. Should it contain policy changes, user right changes, important discussion outcomes, wiki design changes... all of the above? Or should we just remove it completely? Currently the newest item is from September 2019 and the oldest from November 2018. I just figured I'd bring this up here so we could decide what exactly this section should be used for, assuming we don't just remove it completely.--Madminecrafter12 (Talk to me 00:50, 25 March 2020 (UTC)


 * I think just anything that the average editor should take note of should go there. Mostly the stuff you listed. It just needs to be kept up with. -PancakeIdentity (talk) 01:10, 25 March 2020 (UTC)


 * I support PancakeIdentity's propose. We could make a kind of guide to determinates what should be written there... Ma (talk)


 * I think we should list major discussion outcomes or design/layout changes there, since there isn't a clear notice of those outcomes anywhere if you're not keeping up with talk page discussions or recent changes. – Sonicwave talk  06:12, 16 April 2020 (UTC)