Minecraft Wiki talk:Community portal

This is the community's main discussion page.

Talk about anything wiki-related here!

Sign your posts with, add new posts below others, and click "Add topic" above for new topics.

Note that this page is NOT for suggesting new ideas about the game. That belongs on the feedback site.



Clock circuit, Logic circuit, Pulse circuit, Memory circuit, Transmission circuit
Should these pages really be at the location they're currently at? The scope of these pages makes me feel as though these would all be much better as subpages of Tutorials, rather than as top-level mainspace articles. - User-12316399 (talk) 12:30, 12 March 2019 (UTC)


 * . According to MCW:NOTABILITY, "Gameplay strategies, guides, how-to's, etc., should be subarticles of Tutorials." The redstone articles are more like a encyclopedia than most tutorial pages. Tutorial pages are usually aimed more at readers wanting to construct something rather than to learn about something. That doesn't necessarily mean they couldn't go under tutorials though. jahunsbe (talk) 13:30, 12 March 2019 (UTC)


 * . But I agree at the same time, that they're not right in their current state. These pages are not tutorials in the same sense of the word like the other tutorials. They are indeed more about documenting something rather than guiding you through something. These pages are documenting game mechanics, and are using a completely different tone than any other "tutorial". Similar to enchantment mechanics, which has been (in my opinion) erroneously moved to a subpage of Tutorials. I bet there are more examples of this, like anvil mechanics, village mechanics. You can see the pattern here. In my opinion we should rather be looking for a new top level page, like Mechanics (for game mechanics, redstone mechanics, anything about not specifically one particular game object), next to the tutorial one, and then move all these pages as a subpage of that instead. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 14:57, 12 March 2019 (UTC)

Proposal

 * Tutorials ("player guides on how to use or do things")
 * Mechanics ("regular articles about game mechanics")
 * Mechanics/Anvil
 * Mechanics/Dyeing (also see this discussion)
 * Mechanics/Enchanting
 * Mechanics/Redstone
 * Mechanics/Redstone/Circuit
 * Mechanics/Redstone/Components
 * Mechanics/Redstone/Clock circuit
 * Mechanics/Redstone/Logic circuit
 * Mechanics/Redstone/Piston circuits (might want to make title singular and rewrite article?)
 * Mechanics/Redstone/Pulse circuit
 * Mechanics/Redstone/Memory circuit
 * Mechanics/Redstone/Transmission circuit
 * Mechanics/Trading
 * Mechanics/Village (although now contains a ton of outdated pre-1.14 content)

So I propose the following page structure. There may be more pages that should belong in here but I just listed some examples, you may add more if you know of any. – Jack McKalling 09:01, 26 April 2019 (UTC)


 * If what Jack's suggesting is that Mechanics is its own section, not part of Tutorials but on the same level as Tutorials, then I   . &#8212; Memetics  talk &#124; edits 05:58, 27 April 2019 (UTC)
 * Yes that is what I'm suggesting. Currently the Mechanics page redirects to a really old and outdated subpage of Tutorials, and is not the kind of page I was thinking about. I didn't link it for the reason that I'm thinking of a completely new page, similar to Java Edition guides. That one, this new Mechanics page, as well as the Tutorials page, in this proposal, would all be top level pages that provide a neat overview of all their subpages. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:20, 28 April 2019 (UTC)
 * – Nixinova Nixinova sig1.png Nixinova sig2.png 06:26, 27 April 2019 (UTC)
 * - when will we be getting round to doing this? - User-12316399 (talk) 08:47, 1 October 2019 (UTC)
 * If nobody complains I'll start moving these pages to their proposed destinations in around four hours. - User-12316399 (talk) 09:13, 8 October 2019 (UTC)
 * I've went ahead and moved most of them. Should Tutorials/Piston circuits also move? I'll see if there's any others that could potentially be moved and list them here. - User-12316399 (talk) 13:20, 8 October 2019 (UTC)
 * Yes, definitely also move Mechanics/Redstone/Piston circuit. There are some tutorial subpages that might be a better candidate for Mechanics too, but in all those cases they would need to be rewritten so lets leave those where they are for now. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 12:33, 10 October 2019 (UTC)

Continuing with the process of rearranging the pages in favour of the "Mechanisms" umbrella subject, I've marked the current "main" Mechanisms page as requiring attention. Namely, it is currently a redirect to a sort of unrelated tutorial page, however the redirect page should in my opinion be repurposed to displaying an overview of all kinds of mechanisms that are now subpages of it, with possibly a section for somewhat related tutorial links. This way the subpages would make sense, as their top level page shouldn't be redirecting. Also, I've similarly marked the Dyeing page for requiring attention, seeing it currently cannot be moved yet due to the above linked discussion for it. Lastly, the Redstone subpage hasn't been made yet, eventhough we've subpaged it with all the circuit pages. It would be a good idea to add some overview content to that sub-main page as well. – Jack McKalling 12:49, 10 October 2019 (UTC)

Reversion of the proposal
Besides the wiki's consistent insistence on mistreating tutorials (by rejecting both a custom content namespace or, if at all possible, placing them in the main namespace with no prefix), I strongly believe this proposal is similar, has no merit and must be reverted.

At no point is ever any substantial reason for tutorial grouping is provided (policy is not an argument as it is the thing being questioned).

No strong arguments (i. e. beyond opinion and personal preference) have been provided in favour of the mechanics proposal. Arguments against such grouping are problems with searchability (no search bar suggestions, potentially SEO issues as well) and overcomplication of page structure. You have categories for technical and queryable grouping, you have the ability to create a hub page which is not a superpage, and you have the ability to request custom namespaces to be created if nothing else serves your means.

You will definitely have to create mainspace redirects to tutorials and mechanics pages in this structure to avoid searchability issues (but potentially incur new issues with search engines - not an expert, but from what I know their page scoring algorithms are rather unpredictable and often counterintuitive). At this point you might as well put articles there.

Why not group blocks, items and mobs? While with tutorials you had the irrelevant excuse that they do not describe game content, alleging to a defined (in reality, unspecified) aim of the main namespace, mechanics are actual description pages.

P. S. Proponents' insistence on that my arguments must not be considered because I allegedly had half a year to "find" this discussion and participate in it are disgusting. --AttemptToCallNil (report bug, view backtrace) 20:32, 13 October 2019 (UTC)


 * I oppose the current proposal, but I would support moving them to something like Villages/Mechanics (for example). It keeps these pages better tied to their parents, is much more clear, and could help with the accessibility issues by having them clearly linked on their main pages. One problem with the current proposal is that simple redirects don't work. You can't just have Village redirect to Mechanics/Village, as the main village page is still used. -PancakeIdentity (talk) 20:40, 13 October 2019 (UTC)


 * Thanks for you guys' imput. Sad it was late, sorry that this caused frustration, but better late than never. This is yet another case where the com portal's function failed. Please understand your feedback is and will always be welcome, regardless of frustrated reactions. Anyway, I too am not an expert in SEO/searchability/redirects. I should have provided arguments for my proposal though. I've participated in the tutorials discussion too, and because you and others opposed to namespaces, I didn't again suggest it here. However these pages do share similarities with the tutorials, and I wanted to address that. Although I didn't start the discussion, I did have the very same idea before and had clear ideals. I'd gladly hear any other proposals, because my main point is and will be, these pages aren't following the proposed article structure as suggested by the style guide, and this has to be addressed in some way. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 21:06, 13 October 2019 (UTC)


 * I think you had the right idea, but I disagree with the details. I'd propose moving the mechanics to pages like Village/Mechanics, Trading/Mechanics, etc. I would also propose moving the redstone circuits to something like Redstone/Circuits/X. –Preceding unsigned comment was added by PancakeIdentity (talk • contribs) at 22:52, 13 October 2019 (UTC). Please sign your posts with


 * I would actually support that far more than "Mechanics/Village", etc. I believe it is more meaningful to have the mechanics pages be structurally/logically dependent on the thing mechanics of which are described than on the concept of mechanics. I might actually support the same with tutorials, like mob farming and combat tactics as subpages of corresponding mobs, and e. g. "Cactus/Farming". --AttemptToCallNil (report bug, view backtrace) 23:50, 13 October 2019 (UTC)
 * This proposal of PancakeIdentity & ATCN makes sense to me; I support that scheme. &#8212; Memetics  talk &#124; edits 07:30, 26 October 2019 (UTC)
 * Here's the fact. Tutorials are community-made guides that guides you in the game. They are never official guides by Mojang or in the game. Logic gates, redstone circuits are all community-made concepts, they're not coded into the game. Mechanics in the other hand such as enchantment mechanics are mechanics that are coded in the game. I can't think of a good proposal, but I'll  because it makes much more sense.-- skylord_wars (talk) 16:36, 28 October 2019 (UTC)
 * I would also support making them subpages when available.  Nixinova  T  C  01:45, 6 November 2019 (UTC)


 * Great, I also like this proposal better than mine. It's good to have consistency, and giving each article that has specific mechanics its own /mechanics subpage makes sense and keeps these related and close together. I agree that is better than keeping all mechanics subpages together instead. Now that I've seen the latter in action in page titles and links, it doesn't even look right after all anyway. For readers it makes more sense to go from for instance "village" to "village/mechanics" than to "mechanics/village", because it's a completely separate top level page. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 15:15, 11 November 2019 (UTC)
 * moving pages to Mechanics/x and having redstone circuits as tutorials, per the arguments described above. I am wondering if, for example, the Village page should transclude its mechanics page using LoadPage. The BlobsPaper.png 23:06, 5 January 2020 (UTC)


 * moving mechanics pages to the Village/Mechanics format for reasons given above. I'm not sure about tutorials though, since there are some tutorial topics that don't have a clear root article (e.g. Tutorials/Tips and tricks) and they tend to contain more subjective information than regular articles. We could add a template to the top of all tutorial-style articles to inform readers that the article is a tutorial or has community-made content. – Sonicwave talk  01:35, 5 February 2020 (UTC)


 * I've gone ahead and the village, enchanting, and anvil pages to the format "X/Mechanics" because I feel like there's a pretty clear consensus to do so.


 * I'm not clear on what needs to be changed about Trading and Dyeing, because if these two pages were moved as is, neither would have a base page. For trading, are we suggesting that it should be moved to Trading/Mechanics and have Trading redirect there? If so, that seems unnecessary and by that logic, the enchanting, brewing, and smelting redirects should exist only as redirects to their mechanics subpages. And for Dyeing, dye is actually a collection of items in the game so moving that makes even less sense; is the suggestion to split the dye page into one article about the items themselves and another about the mechanic?


 * I haven't moved the redstone pages yet because I don't think it's clear yet from this discussion whether they should be mechanics subpages of Redstone or tutorial pages.--Madminecrafter12 (Talk to me 15:22, 5 February 2020 (UTC)


 * I see no reason to enforce a pointless redirect scheme for the sake of ensuring page relation consistency. If the mechanics are not descendants of a base something, they are a base something. Support leaving the above as is (without any moves or redirects). --AttemptToCallNil (report bug, view backtrace) 15:33, 5 February 2020 (UTC)


 * Yeah, that's what I was thinking.--Madminecrafter12 (Talk to me 23:35, 5 February 2020 (UTC)


 * Re:dye; I think that was the idea. I would support just having a "Dyeing" page and no mechanics subpage. -PancakeIdentity (talk) 05:08, 6 February 2020 (UTC)


 * About the redstone pages, I having them be subpages of redstone rather than tutorial pages. Putting them under redstone keeps them all better organized in one place. It would, however, probably be helpful to have links to the pages in Tutorials and maybe Template:Tutorials. I think the "Redstone/Circuits/X" format mentioned above would work well with Circuits having a list of subpages. jahunsbe (talk) 15:11, 10 February 2020 (UTC)

Aim of the wiki and other titles in the franchise
The result of the discussion was carry out the proposal suggested by AttemptToCallNil in the last section. This closure primarily reflects the participation of that discussion in particular, but I've also briefly looked throughout the rest of the discussion to see if any important arguments were made there. Although almost all participants in the discussion of ATCN's proposal have been supporters, I have taken in mind the concerns pointed out (particularly by Violine) when evaluating this consensus.

There's a pretty strong consensus to keep Minecraft Dungeons pages on this wiki but move to the namespace Minecraft Dungeons, with both Dungeons and MCD as namespace aliases. The discussion makes it clear that Dungeons content should not be covered fully in the mainspace, so the only slight question would be whether it should be moved to a new namespace or a new wiki completely. Editors have pointed out several issues with a new wiki for MCD: you need a new community with people willing to administrate, it will likely have a worse SEO, and it would possibly be hosted by Fandom which could cause further complications, etc. which in my opinion overrule the argument that was briefly brought up, that there would need to be separate templates and technology if Dungeons were to stay on the wiki. In addition, it's far easier to have Dungeons in a separate namespace and later move it to a new wiki if documenting it here becomes a problem than the other way around.

Minecraft Earth was a lot less clear; I only see a weak consensus to keep them in mainspace, simply as a separate page if needed. Although this suggestion was in the original proposal, very few of those supporting advocated for why this would be more productive than having a separate namespace like we would for Minecraft Dungeons. But the proposed resolution for Earth in particular was made very clear, so if anybody strongly believed that it really needed it's own namespace I would presume they would have said so. So for now the proposal for Minecraft Earth still stands, but if anybody disagrees with it, they are welcome to create a new discussion to determine the status of Earth in particular.--Madminecrafter12 (Talk to me 14:36, 23 April 2020 (UTC)

This Discord message is the reason I'm posting this here. Since the introduction of an entirely separate game, Story Mode, questions have been raised about whether we need to provide detailed coverage of other Minecraft titles, or delegate this task to other wikis and settle for brief descriptions instead. Given the upcoming release of Minecraft: Dungeons, it would be better if this question was finally answered.

The aim of the wiki was implicitly and informally defined too long ago, when what is now Java Edition was the sole work titled Minecraft. As such, it cannot be said that we document Minecraft and therefore only the main game. This statement could be made broader, to the point that since what we call Bedrock Edition is the sole work officially named "Minecraft" without any other words in the title, we could say that this wiki should only document Bedrock Edition and delegate coverage of other editions to other wikis. While such an approach isn't going to be taken because of substantial similarity between Minecraft editions, something not true for completely independent titles in the franchise, it underlines the main issue with this argument: "Minecraft" in "we document Minecraft" isn't defined. And I have started this very topic specifically to help the community determine what definition is appropriate.

I support documenting other titles on this wiki. Content pages for these titles could be placed in subpages or separate namespaces (like UESP does). --AttemptToCallNil (report bug, view backtrace) 14:51, 11 June 2019 (UTC)


 * franchise as a whole, as I already stated on discord. I'd prefer just subpages, rather than separate namespaces though, so they can be found better with the search then. FVbico (talk) 15:12, 11 June 2019 (UTC)
 * UESP definitely supports search suggestions for other content namespaces. There are server configuration options for enabling them as content namespaces and as namespaces to be searched by default. --AttemptToCallNil (report bug, view backtrace) 15:42, 11 June 2019 (UTC)
 * Uninvited, seriously I want to comment on this topic. I thought carefully about new community, the independent community is more new and dynamic, knowing how to running with scissors, like today Singapore and Japan. Singapore's approach gives a community the opportunity to develop independently, the new community is more focused on the gameplay writing of this new game.


 * A point of view made against : A new game released by Mojang must have much gameplay in the future, if it is not advisable to take many subpages, the reader will only be busy looking for the subtitle page, rather than a complete wiki. Looking at the previous Minecraft Wiki and not preparing any subpage for Minecraft:Story Mode, it is obviously not appropriate to outline the entire page with a whole game.


 * I quote words from Gamepedia suggesting wiki interface:


 * "At Gamepedia, our goal is to provide the #1 wiki resource for gamers spanning all genres and platforms. Whether you are starting a brand new wiki or moving an existing one over, gamepedia will provide your community with all the necessary tools to create a great wiki. Please answer the following questions to give us a better understanding of your preferred involvement."


 * FANDOM has the same wiki: https://minecraftdungeons.fandom.com . Why couldn't set up a new wiki on Gamepedia by interfering with the right of others to establish a wiki freedom?


 * So my opinion is given, sorry. All in all, we need to listen Gamepedia wiki managers and project creator's suggstion. --Angrydog001 議(Talk)/誌(Logs)/勛(Contribs) 17:41, 11 June 2019 (UTC)


 * I'm sorry, but I can't understand this post. I'm unable to see links between its parts, and sorry for being blunt, but it doesn't sound coherent enough. --AttemptToCallNil (report bug, view backtrace)


 * ^That being the case, we reserved our respective views. Besides, what BD saying is what I thinking. --Angrydog001 議(Talk)/誌(Logs)/勛(Contribs) 02:45, 12 June 2019 (UTC)


 * . If Minecraft Dungeons has a lot of content that differs than the main game, and will receive constant updates, then it may be better to have a separate wiki for it. If the game is similar to the main game then it should be on here, as a subpages of Minecraft: Dungeons. We didn't have this discussion about story mode because it didn't add enough content but now with 2 new games on the horizon this is quite different. – Nixinova Nixinova sig1.png Nixinova sig2.png 19:22, 11 June 2019‎ (UTC).


 * How much is too much? Given this question is not answerable, this topic is not about whether to make a new wiki for MC: Dungeons, but about the scope of this wiki, and thus whether titles like Story Mode or Dungeons should be documented here in detail. --AttemptToCallNil (report bug, view backtrace) 20:07, 11 June 2019 (UTC)
 * I think this will should be more about the franchise as a whole, but I'm not sure of the extent we should document other games on here. I think subpages are the best idea at the moment for eg Dungeons exclusives. Story Mode can be easily described in one page. Though, what is technically the difference between bedrock, console, java, and dungeons? All are completely different games that just have similar content. To answer the main question... "probably". – Nixinova Nixinova sig1.png Nixinova sig2.png 21:07, 11 June 2019 (UTC)


 * I think I can't formally answer this question. Because first, I'd like to know how we could even document other games in the first place, and make it fit on the wiki. But seeing we're still stuck on the wiki-wide refactoring of edition-specific information already, I'm not seeing how we're going to get consensus on how to document an even wider scope. So generally speaking, it's my opinion we should discuss at least how we could achieve this, before deciding whether we should do it. But for what it's worth, depending on whether it could be done with a clear distinction between each game, I'd be leaning towards the whole franchise. Because although they might not be the same game, if they are part of the same franchise, they essentially are still "Minecraft"-y. But I'm heavily concerned about the implementation of this. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 21:27, 11 June 2019 (UTC)


 * Whether it is implementable is definitely not a problematic question. Documenting substantially different titles requires even less integration with main-game articles than edition refactoring. A custom content namespace or a subpage system (I'd prefer the former, I guess?) is not impossible, and integration into main game articles could be achieved with a dedicated section (such as "In other titles"), which briefly describes the subject's involvement in titles like Dungeons or Story Mode (also, why wouldn't we document books as well?) and links to more detailed dedicated articles. --AttemptToCallNil (report bug, view backtrace) 21:42, 11 June 2019 (UTC)


 * . Having too many articles dedicated to a particular game (Dungeons) or series of games (Story Mode) will basically make this wiki a huge mess. When I first began making the Story Mode article back in 2014, I had felt like that it would be best if information about the game was kept to that article, with the exception of trivia or pictures pertaining to the game in other articles.
 * Its simply unnecessary for numerous articles that are basically part of spin-offs to be included in this wiki. It would be better off if any additional information (e.g. locations / characters in Story Mode or items/armor/potions in Dungeons) be kept completely separate from this one. -BDJP (t 23:26, 11 June 2019 (UTC)


 * . Story Mode is a standalone game created by another company, Telltale. They only acquired the rights to use Minecraft franchise for their game. Aside from that, Story Mode is a linear progression storytelling or basically just a point and click game, it's not worth documenting each character in the first place. As for Minecraft Dungeons even though it's a Mojang game, it's not suitable for this wiki. Every items, mobs, and mechanics will conflict with the base game. Sure we can utilize namespaces as the solution, but Minecraft Dungeons has a very different genre, it'll be 100% better to just separate the wiki, more efficient and maintained separately.
 * Back to the topic, yes this wiki documents the Minecraft franchise as a whole, hence why we have Minecraft Dungeons and Minecraft Story Mode articles. But this wiki isn't suitable to document all the contents and gameplay of another game, we should keep this wiki to only document the main game and only the titles of another game. – ItsPlantseed ⟨₰|₢⟩ 05:24, 12 June 2019 (UTC)


 * . Unlike Story Mode, I think Minecraft: Dungeons is actually an indie game with enough new content that it's likely to contain a lot of diffenent content information. Even if it is the same thing as the vanilla, it must contain different information from the vanilla one. Putting them in subpages means there will be tons of subpages and subpages of subpages, so why not make it a standalone wiki? — SagvinXC   讨论(Talk)/贡献(Contribs) 02:40, 13 June 2019 (UTC)

Once again, the question of this topic has no relation to specific titles whatsoever! The question is the scope of the wiki. All conversation in this topic is basically people pushing incoherent, unexplained, and often false reasons why this wiki should not have extensive coverage. Since the question is the scope of the wiki, nothing about non-primary titles matters: their number, their content, nothing. The only thing that matters is to what extent we should document, for the purposes of this discussion, an unknowable number of titles with unknowable content, of which the only thing known is that they're part of the Minecraft franchise. For an example similar to non-primary titles, take mods. If not for the aggressive vanilla-elitist position of the community and disturbingly poor admin strategies during this wiki's first few years, this wiki could have become the source of information not only on vanilla Minecraft, but on a wide variety of mods as well. This has irrecoverably failed, and people are now pretending like mods were never within the scope of the wiki to begin with. Technological limitations are most definitely not a problem with documenting many titles. Neither is "creating a mess", content organization is solvable. What's not easy to solve is involved editors. I'd rather not resort to pointing out specific titles, but we may as well have lost our chance to provide due coverage of Story Mode – it's too late now for multiple reasons. So the question is, what exactly is this wiki about? --AttemptToCallNil (report bug, view backtrace) 09:02, 12 June 2019 (UTC)
 * What the wiki is about? Ultimately, to have people cooperate together. This conversation isn't a very good example of that. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:31, 12 June 2019 (UTC)


 * As I just said above, this wiki serves no purpose for documenting the contents of another titles. Other titles should have their own wiki separately if they don't share the same gameplay and genre. That's it, this wiki should only document the main vanilla sandbox game, Minecraft. And clearly unofficial community-made stuffs don't belong here, none of them are supported by the official nor the wiki. Mod pages only cover some parts of the community, some are taken care by an individual and most of them are abandoned just to fall into despair. But then again it's just my own opinion and I'm not fully opposing this, there are some of my concerns regarding this move among others:
 * What belongs in the mainspace?
 * The searchability and accessibility of specific titles.
 * If we were about to include namespaces for specific titles, the search bar functionality should refer to the title that people desire (one solution I can think of is to add a dropdown menu that search a specific namespace). – ItsPlantseed ⟨₰|₢⟩ 11:16, 12 June 2019 (UTC)


 * I personally to opening it up.
 * I'm imagining keeping mainspace for the java/bedrock/etc game, and opening new namespaces for each of the other game series: one for Earth and whatever sequels, one for Dungeons and whatever sequels, one for the Story Mode series, and so on.
 * From mainspace articles like Pig, you could have sections at the bottom, near the History / References area, titled "In Minecraft Earth", "In Minecraft Dungeons", and so on. These could have see-also links to and, as well as short summaries perhaps. And then you'd have a nice, clean  with content only from that game.
 * I like this organization because it separates the peripheral content from the main-game content. Peripheral game info won't be sprinkled throughout the page, so when the main java/bedrock/etc game gets its many many updates, editors won't have to gingerly step over all this other content. And those other namespaces won't have to deal with the constant update churn from java/bedrock/etc that's irrelevant to their games. –Preceding unsigned comment was added by Sealbudsman (talk • contribs) at 20:10, 12 June 2019‎ (UTC). Please sign your posts with
 * I would this method. – Nixinova Nixinova sig1.png Nixinova sig2.png 20:15, 12 June 2019 (UTC)


 * I appreciate this discussion, and I thank for raising it.  The question of the purpose and scope of this wiki is at once a philosophical one and a matter of history, preference, and practicality.
 * First, the Ship of Theseus comes to mind - What exactly defines Minecraft the game, and at what point does Minecraft the game become something other than itself? Are Java Minecraft and Bedrock Minecraft the same game?  Well, yes and no.  How I see it is that essentially they are the same - a player's experience with the game involves mostly the same kinds of adventures and interaction with the game interface in both versions, despite that there are minor (and sometimes not so minor) differences.  Should they have separate wikis?  Probably not.  I liken this to how I may act somewhat differently in different social contexts, such as at work, with family, among friends, on this wiki, etc.  Am I a sufficiently different person in each context to be called a different me?  No, I don't think so.  (YMMV.)
 * I have a brother, and he's a lot like me but also very much his own man. I see Minecraft and Minecraft: Dungeons (etc.) in this light: Part of the same family, but not the same individual.  So then, when people are seeking information about Memetics, are they looking for information about only one kind of me, about the various "me"s, or about me and other members of my family?  I guess it depends on the seeker.  I personally only really care about finding information here on the core game we call Minecraft.  But sometimes I might look elsewhere for information on tutorials, on mods, on related games in the franchise, on Minecraft stories (official books), on toys, and so on.  Why should I have to look elsewhere for this information, I wonder?  Why can't I find it all here, on the official Minecraft wiki?
 * And here's where I arrive at my position of . To the extent that we can be a comprehensive and most-useful information source for all things Minecraft, I think we should be.  I believe we can and should stay focused primarily on the core game but that we also can be so much more.  I believe we can solve the technical challenges that this change will pose (and by "we," I mean "you, all you people with better technical ability than me," though I'll pitch in my $0.02 here and there).  And I believe that this expansion of focus will help us to attract a much broader cadre of dedicated editors, which in my view can only serve to make this place a healthier and more vibrant community with more long-term staying power.  &#8212; Memetics  talk &#124; edits 06:35, 13 June 2019 (UTC)


 * I oppose this idea if the wiki continues in its current state. I've mentioned before that I think the wiki can already be extremely messy due to 5+ versions of Minecraft that have been, or are being, developed. However, if we do eventually find a good way to represent these differences without making these extremely messy pages, I would be more likely to support this. The wiki just doesn't need more mess, but if we can do it well, I'll support. –Preceding unsigned comment was added by PancakeIdentity (talk • contribs) at 02:40, 14 June 2019‎ (UTC). Please sign your posts with

AttemptToCallNil's proposed resolution
I believe there is one most significant argument of those who opposed covering other Minecraft titles on this wiki in detail, and it is great difficulty in manage articles if they had to include other titles' information.

It does not seem to be a real challenge, however. I believe this to be even easier than managing editions of a single base game. Separate articles can be created and referenced from the main game article in a short section.

For organizing the separate articles, we could create subpages (not good for search) or use disambiguation in parentheses (this may have other issues), and we also have the option of a separate custom namespace. I do not believe there is substantial difficulty for wiki managers in configuring a separate namespace for each title, which are not expected to appear in significant numbers. Wikis which have to manage content from multiple titles use both namespaces and parentheses to various degree of success.

For examples of such coverage, I provide the Fallout wiki on Gamepedia (known as The Vault), Unofficial Elder Scrolls Pages (UESP), and its Fandom counterpart (Gamepedia does not have a general TES wiki).

For the Vault, a single weapon type, a 10mm pistol, has many different implementations in the many titles of the Fallout franchise. There is even a common article for all those variations, which provides links to articles about such items in specific games.

One example from UESP is the Azura's Star, an artifact which makes appearances in four major titles. There is a lore page for it, a subsection for Daggerfall, and three articles for Morrowind, Oblivion, and Skyrim.

A second example from UESP is the Light Armor skill. It also appears in four titles (but not the same four titles) and has a separate article for each of them: Morrowind, Oblivion, Skyrim, TES Online.

The Fandom Elder Scrolls Wiki uses a more conventional parenthesized disambiguation. Azura's Star has a disambiguation page, and separate pages for Daggerfall, Morrowind, Oblivion, and Skyrim. An identical approach is used for light armor: a disambiguation page and articles for Morrowind, Oblivion, Skyrim, and TES Online.

These examples indicate it is possible to manage such content without creating a huge mess.

In particular regarding Dungeons, there is a reason I would strongly prefer not creating a separate wiki. A separate wiki would mean reduced interactions between base game and Dungeons editors, reducing flow of users from one wiki community to another, and creating possibilities for a greater split in the general Minecraft community. In this case, there would be a blank wiki with little to no established policies and a new administration team (much more reliance on GRASP for recent changes patrolling, less effective admin tools use – there has even been a concern than a certain non-English editor has a non-constructive approach to opening a Dungeons wiki in their language).

Since Fandom acquired Gamepedia and later announced Project Crossover (referred to by some people as "Project Gelatinous Cube"), which involves potential merges of same-subject wikis between the two wiki farms, the possibility of integrating the existing Minecraft community on Fandom (which is smaller and lacks the advantage of being official) into the one on Gamepedia has been discussed. In light of this possibility, proposing a further split of the Minecraft community seems counterproductive to me.

Another issue is caused by existence of non-English Minecraft wikis (but please don't joke about having them deleted, it's inappropriate). If a separate wiki is created for English coverage of Dungeons, it will be implicit encouragement for other wikis to delegate Dungeons coverage to separate Dungeons wikis, which may have undesired effects on their communities. Even if a non-English wiki defies this encouragement (which could even be named borderline denial of agency) and covers Dungeons on their wikis, a separate Dungeons wiki in that language could be opened, thus creating an ineffective system of content duplication (once again, something against the aims of projects like Crossover) and splitting the community.

I propose detailed coverage about Dungeons, and likely Story Mode as well, to be provided on this wiki, in separate custom namespaces.

Please note I would strongly not appreciate unargumented opposition – you're basically saying "your reasoning is faulty, and I won't tell you why". Also I ask you to avoid repetition of arguments provided above (that coverage here would be a mess – I have provided evidence to the contrary, or something among the lines of "there should be no coverage because there should be no coverage" – this is even worse than no argumentation because it's lack of reasoning that doesn't necessarily look invalid). --AttemptToCallNil (report bug, view backtrace) 21:29, 24 June 2019 (UTC)


 * per my resolution as stated below. -BDJP (t 04:53, 30 June 2019 (UTC)

BDJP007301's proposed resolution
The aim of this wiki for far too long has been about the similar editions of Minecraft that have been released on everything at this point. Computers, tablets, smart phones, game consoles; you name it. Then, out of nowhere, we get Story Mode (heck, it was revealed in a "game" released on Mojang's website), and the same with Dungeons and Earth; both are basically revealed without any proper tease or information beforehand. They are also revealed to be coming to basically the same devices, but how the games play out are completely different.

Both Story Mode and its sequel are not sandbox games, but instead are point-and-click and driven by a narrative. While they do have a similar visual style, they are completely different at their core, with stuff that is not possible in the sandbox game, such as animated facial expressions, fluid movement, a third-person camera constantly following the player at various angles, voice acting, etc. Also, as stated by ItsPlantseed, characters / mobs from a game other than the sandbox game are not suitable for this wiki (heck, there is already a separate wiki that we can move over to Gamepedia).

As for Dungeons, it is also not a sandbox game, but an action-adventure RPG. Again, while it does have a similar visual style to the sandbox game, it is completely different at its core, with stuff that is not possible in the sandbox game, such as a top-down camera, in-game currency that is used throughout the game as a whole (not just the Marketplace in the sandbox game), completely different weapons / items / mobs, powerups, etc.

As for Earth, it is also not a sandbox game (per se), but an augmented-reality game. Again, while it does have a similar visual style to the sandbox game, it ends up becoming different at its core. First and foremost, unlike the previous two, this is exclusive to iOS and Android. Secondly, while the gameplay is similar to the sandbox game, it is impossible in the sandbox game for there to be a 360 degree camera without the need for virtual reality (sorry, Bedrock Edition on Gear VR doesn't count), or for real people to be implemented into the world.

Simply put, Story Mode, Dungeons and Earth do not share the same gameplay or genre with the sandbox game, and as such, are completely different, and therefore must be completely separate from this one. For the fact that both Dungeons and Earth have separate Twitter accounts as well is something of note.

Managing articles to include information different from the sandbox game (which is what this particular wiki covers) will cause massive confusion among visitors. Having articles / subpages for Dungeons, Earth, and Story Mode will make this wiki more focused on editors than visitors, be much more difficult to maintain, and said articles may eventually become abandoned and suffer from all kinds of internet rot (I'm looking at all the mod pages that have been made and then eventually deleted because of being left abandoned). It will especially become difficult when, exaggeratingly speaking, that a major update for Dungeons, Earth and the sandbox game are all released on the same day, meaning that it could take days, let alone weeks, for all the information to be updated (instead of it currently taking around a day or less for us to update the articles with the major updates to the sandbox game).

As for Dungeons in particular, keeping the information separate will help tremendously as it'll avoid editing conflicts with this wiki as a whole, will make this wiki easier to maintain, and avoid internet rot (I'll be happy to help set up the Dungeons wiki if need be).

While I was not able to provide good examples of information being separate (as some wikis I have been looking up haven't been updated in 2+ years, and also for the fact we aren't Wikipedia), it will be easier to have the information completely separate overall for the reasons as stated above.

'''I vehemently oppose any coverage about Dungeons, Story Mode, or Earth on this wiki, with the exception of one article having a brief explanation about each game. This wiki is meant to be about the sandbox game, not the Minecraft universe as a whole.'''

I end with this quote from Jasper Boerstra (this one and this one):

-BDJP (t 04:53, 30 June 2019 (UTC)


 * In other words, here are the key points of this topic:
 * Story Mode (SM) and Dungeons (D) are completely different games than Minecraft, and therefore must be described separately.
 * Having any sort of SM/D information on this wiki (implicitly – regardless of arrangement) will be excessively confusing to readers.
 * This wiki will not be able to maintain SM/D articles, and they will be abandoned (implicitly – as opposed to if they were hosted on another wiki, where they would be better off).
 * Evidence of that imminent abandonment is mods.
 * Maintaining SM/D articles will divide the attention of existing editors (implicitly – as opposed to if the articles were hosted on another wiki), which will harm main game coverage.
 * This wiki is only about the sandbox games.
 * All the points presented above are refutable, and thus so is this entire proposal.
 * Point 1. No logical link. Once again, I must refer to Fallout and Elder Scrolls, where there is no evidence of decisions that games outside their typical RPG form must have separate wikis. TES: Blades and Fallout Shelter, I believe, are described on the same wikis as other games in the Minecraft universe, which both SM and D are explicitly stated to be part of. A factor weakening my position may be absence of a base series of games in the same universe prior to the release of dissimilar titles, though, 1) sandbox games rarely get sandbox sequels due to the nature of the genre, and 2) other points remain unaffected by this.
 * Point 2. That "implicitly" part in my point is key. I have presented _two_ arrangements in my proposal which are demonstrably not disastrous for readers. One point, however, I have not covered, is searchability of SM/D content (think SEO). Since it should be expected that people will initially come to SM/D articles from search engines, how close to #1 will the wiki be will determine whether it remains functional. I am not remotely knowledgeable on SEO, so this is just my relatively-layman hypothesis: being associated with an active wiki is likely to be a positive factor, but so may be having a separate subdomain, and/or association with Gamepedia. I will ask for expert advice.
 * Point 3. The "implicitly" part is again key; even if you have not said this, your argument – that a separate wiki is better – is automatically invalid without it. Having SM/D articles on this wiki is likely to improve the chance of current visitors, whether editors or readers, finding them, thus helping these articles to stay alive. The searchablility factor is still applicable.
 * Point 3.1. There have been many contributing factors to mods becoming unused here. Their less-searchable arrangement (as opposed to, say, a custom namespace). The core community's negative attitude towards unofficial content (including the popular non-sequitur "we're the official wiki and therefore can't cover unofficial content"), to the point they were effectively subject to unstated exemptions from all rules (then-admin Kanegasi told me that in 2013). The presence of separate, official mod and mod pack wikis, including the FTB Wiki (which would make this wiki just a secondary source of information). Probably other factors as well.
 * The Russian wiki had a different situation for all the listed factors. There are still mod articles being developed, and even though they aren't updated very well, neither is base game information. This is, however, not necessarily applicable to the English wiki for one of the factors I listed: managing a non-English language project or a wiki is something almost no single mod wiki does at all, much less something they do effectively.
 * A more important analogy to see with content rot is, yes, non-English language projects (typically referred to with terms which imply their derived, dependent status on the English wiki, a despicable trend of marginalizing people who don't speak English; I deliberately avoid such terms as "translation project" or "language wikis"). Why did so many translations on this wiki become inactive and had to be purged? Because they didn't have enough editors. There are, once again, many reasons for that, and not being a separate wiki isn't necessarily among these reasons. Some translation projects did get their wikis, even recently. Are they more active now? Some may be, but definitely not all. Could we have done things better for them? Yes. For one, listing non-English versions on top of each page would have contributed to influx of a new editors.
 * Point 4. That's a mostly flawed model of editors. Typically, wiki editors, especially on relatively large wikis, have areas in which they work. They may not have or like all the games or editions, they may do something that few other can, or they may be bad at something people are often good at. If an editor is focused on updating command documentation, writing change logs, or editing tutorials, they will be mostly unaffected by there being a separate namespace.
 * I said "mostly". The editors whose attention will be divided are those metapedically focused: tracking discussions, managing templates, clearing backlogs (yet most of those isn't the work which greatly peaks with updates, that would be content writing). What would happen if there was a separate wiki? They'd need a metapedic setup: people who can create and revise rules, guidelines, policies, templates, content layout... and where will they take these people from? Who will they ask for assistance? Will there be a "they" even? Capable wiki maintainers are much less common than your average article creators, and we have quite a bit here. The topic of dividing the community was one I covered in my proposal.
 * Point 5. That's just what the dragon left for his treat. Because it's simple: figuring out what this wiki's about is the aim of this discussion. This hasn't been decided yet.
 * We have screwed up with mod coverage, we have screwed up with translation projects, we have screwed up with Story Mode. I believe proposals like this can lead us to screwing up with Dungeons, Earth, and whatever comes next as well. I have nothing left in my life than these few communities online I still believe I can help, and it seems to me people are pushing, in good faith, for something that is likely to deal irrepairable harm to these very communities. --AttemptToCallNil (report bug, view backtrace) 22:52, 1 July 2019 (UTC)
 * We have screwed up with mod coverage, we have screwed up with translation projects, we have screwed up with Story Mode. I believe proposals like this can lead us to screwing up with Dungeons, Earth, and whatever comes next as well. I have nothing left in my life than these few communities online I still believe I can help, and it seems to me people are pushing, in good faith, for something that is likely to deal irrepairable harm to these very communities. --AttemptToCallNil (report bug, view backtrace) 22:52, 1 July 2019 (UTC)


 * I think non-core-MC content (SM, Earth, Dungeons) shouldn't really be documented fully in this wiki, but wouldn't mind if they were. Also, these massive 6KB text walls aren't really encouraging discussion here. – Nixinova Nixinova sig1.png Nixinova sig2.png 02:51, 2 July 2019 (UTC)


 * Trying to stay on a discussion of scope of the wiki: I think the wiki would be better, and more of something to take communal pride in, with more of the official franchise in it.
 * Imagine: you'd look at a page like Sheep, and you're not just reading about how it works in the core sandbox game, instead you have access to sections about the other games right there, and you can get a glimpse how the Sheep plays its part across all Minecraft worlds. That's lore, that's interesting stuff fans would love. And that goes for Dungeons readers too! They get to know the Sheep as it was in the original game. It's a much richer page.
 * And then we look back on that a few years later and can be proud we made that transition and made it all that much richer.
 * I read BDJP's piece, and while I don't really feel much of it actually discourages me from supporting opening the project up, I think his point about internet rot is an interesting one to consider. Ultimately with that though, you can never predict beforehand what editors will come. We've had times when we wished we had more Bedrock and Console editors, but over time they did come. I'm optimistic about Earth and Dungeons editors; we had a fantastic Story Mode editor after all ; ) – Sealbudsman talk | contribs 01:49, 18 July 2019 (UTC)


 * I've added a few bits of trivia to pages such as pig and mooshroom saying that muddy pigs and mooblooms exist; since Earth runs in Bedrock there's not any exclusive functionality afaik so no need for any sections or anything. – Nixinova Nixinova sig1.png Nixinova sig2.png 02:17, 18 July 2019 (UTC)


 * This is a tough issue with no easy answer. Both (all) sides have persuasive points.  I'm comfortable with us being "Minecraft-the-sandbox-game documentation," a comprehensive user manual with text and pictures.  I'm also comfortable with that being just one facet of a wiki that covers the entire Minecraft universe, because I am convinced that we can manage successfully the complexity of such a wiki with our current leadership at the helm.


 * So since a choice is required, I'll keep my original stance. I like the idea of us being the comprehensive, go-to wiki for all things Minecraft.  I think we ought to be more than just a fancy user manual for the core game.  I concur with Sealbudsman (18 July) and lean toward the solution AttemptToCallNil has proposed, with separate namespaces.  I think that needs to be accompanied by a distinct page style for each namespace, if possible; the pages' look and feel - i.e., color scheme, head banner, maybe page structure - will help people tell at a glance which specific Minecraft "species" (sandbox game, interactive story, novel, toy, whatever) the particular page is about.  This should be accompanied by clear infoboxes or whatever identifying the "species" at the top of each page.


 * As long as we continue to document the ever-evolving core game(s) effectively, I believe (as I said before) that expanding our scope will result in a larger, healthier community of editors and, if managed properly, will not result in the confusion we wish to avoid. I even asked my nine-year-old daughter about this issue and read her the various opinions here.  She said at first that it might be confusing to have the expanded scope, but then she brightened and declared with enthusiasm that she thinks it will be fine because we can label the information to make it clear which Minecraft thing the information is about.  She even mentioned a wiki for another game where this is done.  So if she can distinguish such information without confusion (and with enthusiasm, even), then I am confident that the vast majority of our readers will have a similar experience.


 * Also worthy of note: We must make this decision based on reason and evidence if we want to make the best decision. However, we have to acknowledge, I think, the emotion behind this: Our feelings of what scope is best are tied up with our involvement and history with the game(s), and with the wiki, and with the various communities involved.  Whatever decision we make, we are going to feel uncomfortable with it to some degree, and some people will be affected more than others, no matter what we decide.  We have to acknowledge that that's a normal and expected part of the process of change here and to be prepared for that.  We have to do our best to proceed with patience and empathy, and with a degree of compromise, regardless of the outcome.  Having said that, we can only make a good decision here by doing our best to acknowledge and then set aside our emotional associations with Minecraft and engage in the rational basis for what our scope ought to be.  What is best for the wiki and for its user community?


 * Whatever the wiki's scope, I think we'd generally agree that readers of the wiki usually arrive here because they're seeking information about Minecraft. They want to learn.  To best inform and educate readers, then, the wiki needs to have content that is clear, accurate, current, complete, and easily accessible.  Some of the arguments laid out so far raise concerns that expanding our scope would make achieving those goals more difficult.  But I'm more persuaded by the arguments that if we organize the information carefully and systematically, the potential problems will be minimized and that we will gain more in the benefits, which would include a more active, healthy community of editors, some of whom would focus on parts of the wiki more narrowly and some of whom would be more broadly involved.


 * Therefore, the reasoning and evidence overall say to me that we ought to go ahead with expanding our scope to cover the whole franchise: the Minecraft universe (or the whole Minecraft Tree of Life, if you will, not just one branch). We need to evolve just as Minecraft evolves.  It won't be easy, but it promises to be worth the effort.  &#8212; Memetics  talk &#124; edits 15:40, 18 July 2019 (UTC)

Earth

 * (New section to differentiate from the text walls above)

Minecraft Earth is now out and since it runs on Bedrock, all Bedrock features apply to Earth. There are a couple of exclusive features - mooblooms and muddy pigs - but otherwise features are the same. I think it would be fine to have info about mooblooms and muddy pigs documented on their respective parent pages (pig and mooshroom), since there isn't that much (Muddy Pigs jump in Mud and Mooblooms plant dandelions when they walk), and for a page on Mud to be created. – Nixinova   22:34, 19 July 2019 (UTC)


 * At first thought, I'd be fine with documenting those here. However, it's the gameplay that really separates Earth. Do we document how to get each type of block, if there's chances or only specific locations? What about combat? Monster spawning, if it happens? And for small stuff like the two new mobs, Earth is in a closed beta right now. It could receive lots of new features by release or in future updates. Etc, etc. It just opens up a big can of worms that we *really* aren't ready to deal with, at least not until we figure out how we're gonna deal with the already varied versions of the base game. So,, at least until we figure some more stuff out. -PancakeIdentity (talk) 00:06, 20 July 2019 (UTC)
 * Pages for Mud and Mob of Me have been created while this discussion has fizzled out; should these be kept, and other Earth exclusives be documented? Since Earth runs on Bedrock there won't be many more of these new pages created.  Nixinova</b> </b> T</b> </b> C</b> </b> 05:54, 29 August 2019 (UTC)

The de facto consensus at the moment (based on the fact no-one seems to have said anything about the recent pages) seems to be to create pages on Earth info but not to incorporate it into main-game pages, which seems to be working. For Earth-exclusive information about main-game features I think we should add a "In Minecraft Earth" section to avoid the confusion already created by only sometimes. This discussion needs to have some sort of conclusion by now since the game is already out.  Nixinova</b> </b> T</b> </b> C</b> </b> 07:26, 30 August 2019 (UTC)

Reactions to full-franchise coverage
Support:
 * 1) AttemptToCallNil – supports as the writer of the proposal (diff)
 * 2) FVbico – support (diff)
 * 3) Nixinova – conditional support (diff)
 * 4) Sealbudsman – "wouldn't be opposed" (diff)
 * 5) Memetics – support (diff)

Oppose:
 * 1) Angrydog001 – oppose (diff)
 * 2) BDJP007301 – strong oppose (diff)
 * 3) ItsPlantseed – oppose (diff)
 * 4) SagvinXC – oppose (diff)
 * 5) PancakeIdentity – conditional oppose (diff)

Other:
 * 1) Jack McKalling – could not answer the core question (diff)

Points made
For coverage of other titles on other wikis:
 * 1) It is too difficult to manage articles about similar content on one wiki when it appears in different titles with major differences.
 * 2) Other titles may have, or are known to have, radically different gameplay requiring similarly different wiki coverage, and this may be confusing to readers.
 * 3) Covering other titles will require a new set of templates for every such game/series, which is about the same as making a whole new wiki.

For full-franchise coverage on this wiki:
 * 1) It is possible to cover substantially different implementations of the same entity in different titles on the same wiki (provided examples: parenthesized disambiguations on the TES Fandom wiki and the Fallout wiki, custom content namespaces on UESP) – refutes opponents' point 1
 * 2) Having all titles under the same wiki-roof is likely to bring the community together (as opposed to potentially causing a split). There will be easier access to experienced users: those who monitor recent changes and revert bad edits, and to those who can help with wiki/technical things if needed.

Further discussion
Assuming we still want to discuss this further. --AttemptToCallNil (report bug, view backtrace) 21:09, 27 October 2019 (UTC)


 * I'd be less opposed to covering everything on this wiki if we didn't try to Frankenstein like 5 different games' version of a mob/block/whatever on to one page. It's already messy enough covering Java and Bedrock on the same page in some cases, and they're essentially the same game. I think it could work much better if we keep everything separate (even if still on this wiki) by creating separate pages (or sections on pages). If we did put everything on this wiki, I'd say we should put other games under their own namespace, like Minecraft Earth/Cluckshroom or whatever. Documenting things on the same page can be slippery. Sure, some new Minecraft Earth mobs might be similar to existing mobs, but this might not also be the case in the future. Also, there's vastly different gameplay mechanics, like obtaining blocks. I think more separation is, in this case, better than less. Not saying completely different wikis, but yeah.


 * Also, I'm much more open to have Earth on this wiki than something like Story Mode or Dungeons. Earth at least uses the Bedrock engine and has similar(ish) gameplay. Story Mode and Dungeons are much different games that are better described as using Minecraft as a setting rather than being Minecraft. -PancakeIdentity (talk) 21:36, 27 October 2019 (UTC)
 * Sectioning is definitely a good idea if we go down the route of documenting everything on this wiki and will avoid the "$$../.." spam we have currently.  Nixinova</b> </b> T</b> </b> <b style=color:white>C</b> </b> 21:43, 27 October 2019 (UTC)


 * Reviving this, I'd support Nixinova and ATCN's ideas. My biggest concern is just mixing everything together too much. -PancakeIdentity (talk) 03:21, 5 April 2020 (UTC)


 * Of course; can't speak for other supporters, but I never meant for base game articles to provide spin-off coverage, hence the TES/Fallout examples. Though a mention of the separate article would be useful, I think. --AttemptToCallNil (report bug, view backtrace) 21:42, 27 October 2019 (UTC)
 * Earth and Dungeons seem to be completely different games; the gameplay at MINECON Live had pretty different gameplay from standard Minecraft. Perhaps they should have their own wikis, once we learn more about them. We could still mention them in Trivia sections, similar to Story Mode. The BlobsPaper.png 22:50, 27 October 2019 (UTC)

Confused idiot rambles about coverage
I've only skimmed over the furious debate that went on above, but here's my opinions on the matter that I wish to add, despite this probably making it worse.

(Java, Bedrock, Console, Pi, 3DS, etc.) - pretty sure we can all agree on this one

coverage of Earth on this wiki. While presented in a different way, MCE is at its core still a sandbox game, and shares tons of elements with the main series game - blocks, mins and the like. I currently don't see any problem with it. That being said, I haven't actually seen any MCE info be implemented into existing pages about non-MCE-exclusive objects, though, so I'd have to see such an implementation in action to make a satisfactorily informed decision. That being said, I wouldn't oppose there being a separate wiki for Earth content (earth.minecraft.gamepedia.com) if said wiki doesn't have an unreasonably high amount of duplicate content.

- Dungeons is a considerably more distant game from normal Minecraft - it's less of a differently presented version of Minecraft and more of completely different game which is designed to visually look like Minecraft. Plenty of things that would be considered notable in Minecraft terms would be completely unnotable from a Dungeons viewpoint; grass blocks have a lot of important properties in the base Minecraft game, whereas they're to my knowledge nothing more than a background object in Dungeons. (Reminds me that Story Mode had a lot of blocks in the background which are not at all present in the real game - should we document these in some form or another?) Likewise there are things in Dungeons that will not apply to the original game at all, so their notability here is questionable at best. I think it would be better overall to have Dungeons content covered over at another Gamepedia wiki (dungeons.minecraft.gamepedia.com), preferably with sufficient linking between the two wikis where desirable.

This is all probably nonsense though, so make what you will of it. - User-12316399 (talk) 16:55, 7 March 2020 (UTC)
 * I have concerns about that you say "Document all main editions"; what qualifies an edition as main? If Mojang announce Bedrock is the "main" edition, and Java is somehow "secondary", would that affect our decision to describe that edition at all? I assume you meant all editions of the base sandbox game?
 * As for notability, it is apparently a new way to look at the issue, but I don't see how it is relevant given this wiki's scope - what this topic seeks to define, and therefore cannot address as a basis for decisions - pretty much is notability.
 * Mostly a side note as I believe the rest of my opinion on the topic of separate wikis for Earth and Dungeons is extensively documented above. I'm pretty sure making the wiki like "dungeons.minecraft.gamepedia.com" would be impossible, it would have to look like "minecraftdungeons.gamepedia.com" or something similar (that is, a further subdomain level is not something I have ever seen Gamepedia do). --AttemptToCallNil (report bug, view backtrace) 17:36, 7 March 2020 (UTC)


 * Pretty sure we only document Bedrock, Java, and Education (with Education as a variant of Bedrock). Other editions are only documented in history sections.
 * As far as Minecraft Earth, this uses the Bedrock Codebase, so it would be documented as a variant of Bedrock Edition. It would only be specified when there is a difference from Bedrock. The BlobsPaper.png 20:47, 7 March 2020 (UTC)


 * . --dr03ramos Piston.gif (talk) Admin wiki[pt] 03:40, 5 April 2020 (UTC)

Final closure: in one week
This has gone on too long. In multiple places, even. (Not to mention the Discord server - or several.)

Thus far, every point made by opponents of on-wiki coverage was either questionable or refuted. This wiki has good search engine rankings and is known as a place for Minecraft information. It has a somewhat-working infrastructure and an active community. None of this will be present on a new wiki, which furthermore will likely have to be hosted on Fandom (potentially as part of the existing MCD wiki there), because due to the UCP project, new Gamepedia wikis (with exceptions that do not seem to apply) will not be created. There needs to be a profound, as of yet unknown, factor that would make using a separate wiki a better option.

This discussion represents a commonly occurring failure of Minecraft Wiki's discussion system; where there are groups with irreconcilable views, the discussion can continue indefinitely without a conclusion. And with the beta release of Dungeons, a decision should be made promptly. As such, I consider this measure necessary.

If in one week, no such profound factor (as I stated in the second paragraph) is stated here, I consider that this topic can be closed by any user with the following resolution:
 * 1) Minecraft Earth and Minecraft Dungeons should be documented on this wiki.
 * 2) Mechanics and game elements unique to Minecraft Earth should be documented in the main namespace.
 * 3) If a similar, but different, mechanic or element exists in the base game, the Earth one gets its own article, preferring the   disambiguation format.
 * 4) All mechanics and elements of Minecraft Dungeons should be documented in the   custom namespace, which is set to a content namespace and searchable by default.
 * 5) The namespace may be renamed to   if necessary, with   made a namespace alias.
 * 6) Earth and Dungeons should only be mentioned in base game articles as short references, such as disambiguation hatnotes or short "also appears in" sections. The format may be standardized at a later date; development of a complete standard is out of scope for this discussion.

Post here any refinements to the closure text, or (far less likely) overwhelming reasons that require going in the opposite direction. --AttemptToCallNil (report bug, view backtrace) 17:44, 16 April 2020 (UTC)


 * . Thanks for putting an end to this. -PancakeIdentity (talk) 17:52, 16 April 2020 (UTC)
 * to bringing this discussion to an end and I agree with the listed resolution. Using  as a Namespace would be better though.   and maybe a shorthand like   can of course be added as aliases.   HorseHead.png Gamepedia icon.png MarkusRost (talk) 18:10, 16 April 2020 (UTC)
 * --Capopanzone (talk | contribs) 18:13, 16 April 2020 (UTC)


 * – I just finally got around to reading (most of) the discussion above, and the custom Dungeons: namespace idea seems like a good solution of avoiding clutter in base game articles (which was the main argument against covering Earth/Dungeons here, if I'm not mistaken). Editors not interested in Dungeons can hide the namespace in recent changes. Like ATCN said, we can use most of the rules/policies and infrastructure that's already in place (instead of having to set it up again on a different wiki). – Sonicwave talk  18:16, 16 April 2020 (UTC)


 * I probably won't participate in this but rather close it after roughly a week, based on what the consensus is then (which based on what it is now would likely be to carry out the change). But we will need to decide the exact name of the namespace: Dungeons: or Minecraft Dungeons:? Either way we could have the other, as well as abbreviations such as the MCD that Markus pointed out, as a namespace alliance. The creation of a new namespace is a pretty big deal (given that it can only be done by staff) so it would be nice to be clear on what we'd name it.--Madminecrafter12 (Talk to me 18:25, 16 April 2020 (UTC)


 * . — Thomanski | t | c | 18:27, 16 April 2020 (UTC)


 * – I don't think that just using a name space for Dungeons is a good long-term solution. The game is going to grow over time, just like Minecraft itself is, and we have only had access to a small portion of the content so far, so I think we're underestimating how much there is to document. The dungeons articles will probably require a completely separate set of templates and technology to go with them, which will in my opinion cause larger issues in the future. Apart from that, not everyone interested in Minecraft will be interested in Dungeons as well, BUT there's still only one admin team that will need to take care of everything. The same can be said about earth. I'd personally prefer if both Earth and Dungeons would get their own wiki (and I personally heavily disagree with the fact that Earth is to be documented in the main namespace), but it seems like this conversation has already run its course. Btw, just saying "this discussion is taking long and the arguments against using a namespace is invalid and therefore we'll just do it that way" is not really a good way to solve a discussion in my opinion. | violine1101(Talk) 20:58, 16 April 2020 (UTC)


 * Rethinking what I had advocated before, I'd it. I consider MCD a totally new and completely different game, but Minecraft Dungeons: seems like a plausible solution. --dr03ramos Piston.gif (talk) Admin wiki[pt] 01:57, 17 April 2020 (UTC)
 * - I have to agree with what violine1101 said above: "this discussion is taking long and the arguments against using a namespace is invalid and therefore we'll just do it that way" is not really a good way to solve a discussion" <font face="Ubuntu">ILeon ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs -  de.Wiki Admin  08:14, 17 April 2020 (UTC)


 * I have not been keeping up with this discussion, but I agree we should document Earth on this wiki. While it is different from the base game, the core mechanics are similar enough that we can treat it as an edition. I think it should definitely be on the same wiki.
 * For Dungeons, I agree its basically a new game. However, if we do not provide a place either on wiki or on another Gamepedia wiki, its going to lead to content ending up all over the wiki where it does not belong. Namespace sounds like a decent solution, as it makes it easy to replace the namespace with an interwiki if it does migrate to another wiki in the future. – KnightMiner  · (t) 14:22, 17 April 2020 (UTC)


 * this resolution. Though, how are you proposing Earth be documented in articles? An h2 "In Minecraft Earth" or something? And why not put Dungeons in mainspace with "Minecraft Dungeons" disambig (not that a namespace would be bad)? <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> 08:31, 19 April 2020 (UTC)


 * I think, this is Minecraft Wiki, where all things from Minecraft (except mods & servers) must be presented. Thankfully, this is ending. That project Minecraft Dungeons could be moved onto main NS with prefix "Dungeons:" before article name) --Treeislife2 (talk) 09:57, 19 April 2020 (UTC)


 * 'main NS with prefix "Dungeons:" before article name' The "...:" before an article name is a namespace... FVbico (talk) 10:16, 19 April 2020 (UTC)

Mass deletion of mcspotlights videos
The result of the discussion was update overview videos. A new project has been started, and the new Video Policy no longer supports the inclusion of MCSpotlights videos on pages.

I hope this is the correct venue for this topic.

I've noticed a rather aggressive effort on the part of to delete those helpful little 1-minute summary videos created by mcspotlights. They mostly appeared in many of our articles about individual blocks. I've reverted a few of these deletions (for example, this removal of the planks video, and this removal in sugar cane) because the content of the video is still valid and true, not out of date, but possibly incomplete due to software updates.

PancakeIdentity and I have engaged in a bit of discussion about this on my comment board but I thought this should be discussed in a wider community.

My position is this:
 * If the information in the video is valid and true, then it should be kept.
 * The fact that information is incomplete isn't a good reason to remove it, unless the missing information is so significant that viewers may be misled by watching the video.
 * If the information in the video is misleading, it should be removed.

My viewpoint is based on my personal experiences with my child, who had difficulty reading these pages when he started playing Minecraft, but could use a browser and watch videos. These little 1-minute summary videos were extremely helpful to him. Even now that he can read better, when he looks something up on this wiki, the first thing he does is scroll down to see if the article has a video by mcspotlights.

We may all be adults creating content here, but young children use this Wiki also. Information that is still useful to them should be kept.

What say others? ~ Amatulic (talk) 18:16, 13 June 2019 (UTC)


 * I guess I personally don't see their use if they're incomplete. It doesn't provide a good overview of the item/block/whatever then. The videos are kinda weird for the wiki, and feel very out of place imo, tbh I'd support removing them entirely but I really don't see them happening. When I watched the first one, it struck me as extremely out of place, maybe better fit for some type of tutorial page. If we are insistent on providing video overviews, I'd say we should find/create completely updated videos. Otherwise, I'd say they're not really too useful and should be removed.
 * I will say though, I do think floor/ceiling placement for item frames is important enough for the video to be considered outdated.
 * I would also like to clarify, I have been watching all the videos without outdated notices and have kept the accurate and up to date ones On the pages. -PancakeIdentity (talk) 19:01, 13 June 2019 (UTC)


 * Going in on "If we are insistent on providing video overviews, I'd say we should find/create completely updated videos.", I suggested this recently in the discord:
 * "Since so many videos are outdated (and now removed), should we try to make new videos altogether, and try to keep them updated? I'm open to try, but I've never actually video edited anything."
 * Since I posted that, pointed out we should alter Minecraft Wiki:Wiki rules/Video policy first.
 * The wiki admins would be in charge of the video process then, though editors would be able to help by providing scripts for the videos or alike. FVbico (talk) 19:11, 13 June 2019 (UTC)


 * It's just weird to me that Curse videos are exempt from the typical video policy. Also, how are the overview videos serving a business purpose? I'd be more supportive of overview videos if they were done professionally and essentially rehashed the wiki page's content. -PancakeIdentity (talk) 19:25, 13 June 2019 (UTC)
 * The videos being deleted seem professionally-enough done to me. They are nice and concise overviews of the main points in an article. Little details that are missing, like the ability to place item frames on floors, are easily discovered by player themselves and don't detract from the educational value, particularly for kids like mine who want to see them. That's rather the whole point of a concise overview; you can't include all details and still be concise. They don't need to be comprehensive, just informative.
 * We may as well argue that a video has no value because it was made with Java Edition while Bedrock has the larger installed base. I don't buy that line of reasoning (and by the way, I and my child play Bedrock and we still found those videos helpful), and I don't buy the reasoning that a perfectly valid video should be removed because more details became available in a software update. I'd rather keep them, adding a notation about changes, and delete only the ones that are now completely wrong (such as villages needing doors). ~ Amatulic (talk) 19:49, 13 June 2019 (UTC)


 * I mean, I would argue that, although not for the same reason. That's not what we're talking about though so I won't bother. From my understanding, we as a community had reached a consensus to remove out of date videos (See above topic). Even if I disagree, I do see your argument about keeping incomplete videos. More of the community would have to chime in. In addition, "completely wrong" is too strict a criteria for removal imo. The wiki should not promote any out of date information whenever possible, unless the page is dedicated to an older version (such as the new Trading before Village and Pillage page). Like I already said, I think the best solution to make the most people happy is creating up to date videos and removing outdated or incomplete videos (even if I personally still dislike the current videos). Incomplete videos are incompetent as overviews, especially in the case of something like item frames, where the missing information is pretty essential to the current function of the item. We're gonna have to undo most of my edits if we decide to promote videos that don't showcase basic functions of an item. I've stated my opinion, and I think we need more community input before moving any further. -PancakeIdentity (talk) 00:44, 14 June 2019 (UTC)
 * I had just restored the video in chest and then I saw this reply. OK, I'll stop restoring them for now, if no more get removed.
 * My choice of words "completely wrong" was poor. I'm in favor of removing videos that have obsolete information (that is, information that is now wrong because things have changed, such as beds now defining villages instead of doors), but if the content is still all correct, it serves as a concise overview.
 * We disagree that a new capability to put an item frame on the floor is a critical feature. It wasn't before, and it isn't now, it's just an enhancement that isn't necessary for a concise overview video.
 * Ultimately, we disagree about what constitutes "out of date". My position is, if the content of the video is still valid and correct, and it covers most of what a young player needs to know, it isn't out of date yet, it's a keeper. ~ Amatulic (talk) 02:16, 14 June 2019 (UTC)


 * I'm really glad the videos helped your child, but I'm just not sure we should specifically cater towards that audience. Maybe we should instead focus on increasing the wiki's readability? I know a lot of articles could really use it. Maybe as a separate project, but I digress. I don't know, the videos just feel very out of place to me, especially when missing good amounts of information. I really hope some other people chime in.


 * I also wanna say, I got the impression from the videos that they mostly focused on how to obtain the item and how to use the item in gameplay. It's when that information is missing is especially when I feel they should be removed. Especially since I would say most provide a good, solid overview for when they were released, whereas now, they can be missing info that I feel the creators wouldn't have left out if making them today.-PancakeIdentity (talk) 02:35, 14 June 2019 (UTC)
 * Having watched many of these with my son, I can say confidently that they (at least the ones by the mcspotlights team) are concise yet thorough overviews, covering one specific block or item: what it is, how to obtain/craft it, the primary things you can do with it, and other considerations if there's any time left (these videos seem to be disciplined about running less than 90 seconds). Basically they give a new player all the basic information they need to know in far less time than it takes to read the article. This isn't about catering to children who have difficulty reading (but why not do so? Minecraft appeals to a wider age range than any other game). It's about providing information choices. For the comprehensive details, you read the article, which covers everything known about a topic. If you just want to get a quick understanding, those videos are extremely useful. They're professionally-done, well-scripted overviews. Overviews don't cover all information, by definition. And in many cases the videos aren't out of date. ~ Amatulic (talk) 15:24, 14 June 2019 (UTC)


 * I see both sides and at first blush fall somewhat in the middle. When I first started using this wiki, I absolutely loved those little video overviews, as did my daughter (we had an experience similar to Amatulic's).  But lately, it has become somewhat disheartening to see the frequency of tags identifying videos as out of date.  It makes the pages with videos feel out of place.


 * The rub of the problem seems to be this: If the videos are a core part of the wiki, i.e., an expected element of the basic content and structure of key pages, then most pages should feature current, accurate overview videos - at least the pages about the basic elements of the game, as the videos seem intended for bringing beginners up to speed. If the videos are not a core part of the wiki, then they should not be embedded in the pages at all, as having them on some pages sets up an expectation that they will be present on most pages.  This expectation is reinforced by the way the current videos refer to other videos in the series: they present a comprehensive structure of video content about current basic game elements and mechanics, a structure that simply doesn't exist anymore now that so many of the video "nodes" in that structure are out of date.


 * And that to me seems like the bigger problem: Taken as a whole, the set of mcspotlights videos is no longer about the current game. As a whole, it's historical content, individual remaining videos notwithstanding.  The old scheme for how our wiki pages were structured, including overview video content near the end, is no longer viable.  As much as still I like the videos and appreciate their professionalism and consistency, I reluctantly have to conclude that it's time to pull them all until we have an active project creating a comprehensive set of up-to-date videos.  Meanwhile, we can work on making the rest of the page content as accessible and user-friendly as possible.  (Honestly, it seems as though the video content should be its own living project with an active maintenance team, one to which the wiki can point; otherwise, as the game is under constant development, we'll run into this issue of stale videos over and over again.)


 * If the community's consensus is to keep videos that are still accurate (even if incomplete), then I wouldn't oppose that, though I think the larger issue of the wiki's overall stylistic consistency would still need to be addressed. &#8212; Memetics  talk &#124; edits 11:56, 18 July 2019 (UTC)


 * I completely agree with you. Having a continuing project for creating updated videos would be great, but if it doesn't happen, I'd rather just remove them altogether. -PancakeIdentity (talk) 23:27, 18 July 2019 (UTC)


 * I guess we could try to launch such project then, as I stated in the above comment thread early on, I actually suggested doing it, but it kinda stopped there.
 * If we were to make videos, I suggest making scrips for videos a subpage of the project (eg Videos/Stone for the video about the Stone page).
 * I'd gladly record it, but I suck at making scripts and never video edited anything, so this will need a collaborative effort nonetheless. FVbico (talk) 23:38, 18 July 2019 (UTC)

Chemistry
(See Also: User:Blobs2/Renewable resources)

Many pages have recipes involving elements or compounds because of crafting usage. However, this implies that the player can obtain these items, which is not true since the chemistry GUI blocks are not legitimately obtainable (they can only be obtained in Creative or with commands, and the player must be in a world with "Education Edition" enabled). We should have a template that explains this, which would be used to describe methods of obtaining certain blocks and items, including when crafting is used. It could look like this:

cannot be obtained in Survival without commands and can only be obtained in Education Edition, or in Bedrock Edition worlds with "Education Edition" enabled. Therefore, the same rules apply to.

I have written a similar paragraph on the Element page, but I would want to extend it to all chemistry pages. The BlobsPaper.png 15:19, 3 August 2019 (UTC)


 * this as the chemistry blocks are not renewable. — Hayden Bob Mutthew ( talk, contribs ) 04:43, 19 August 2019 (UTC)

Sound file attribution
This was discussed before in this archived thread, but didn't get very far. Samuel Åberg's twitter ("slamp0000") describes him as the lead sound designer for Minecraft; however most sounds on this wiki have License C418 slapped on them. In addition, this minecraft.net attribution page shows that some sounds were taken from Freesound.org, though likely edited afterwards. Since it's not clear which sounds were created by C418 or slamp0000, perhaps all non-music sounds (not taken from Freesound) should simply be tagged with License Mojang; the sounds listed on the "Sound attributions" page would instead be tagged with the license listed there. – Sonicwave talk  19:03, 27 August 2019 (UTC)
 * Not a licensing expert, but I agree with this proposal. --AttemptToCallNil (report bug, view backtrace) 19:05, 27 August 2019 (UTC)
 * I might go ahead and begin slowly changing the non-music sound descriptions to use License Mojang instead of License C418. I'm not sure how to figure out which sounds are from Freesound without listening to everything on the attribution page and seeing what sounds familiar, since the files don't have attribution info in their metadata (unless I looked in the wrong place).
 * Also, License C418 says "In agreement with C418, Minecraft sounds are allowed to be hosted on the wiki. All music must be shortened to the first 30 seconds"; is this agreement publicly viewable or was it made through something like a private IRC channel? – Sonicwave talk  06:11, 5 October 2019 (UTC)

Some changes I've made to infoboxes
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 Bexrock 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)

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 [ Grid Book and Quill.png Grid 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)

Ginormous maintenance categories
Have a butcher's at these things:


 * Category:Information needed
 * Category:Verify
 * Category:Unknown version history
 * Category:Stub

These maintenance categories have grown to contain hundreds of pages needing attention. Yet, despite this, it seems as though few people are actually trying to fix the issues with these pages. I'd think that the sheer size of these categories for one is one of the main contributing factors to how these have grown out of control - why bother with fixing these pages when there's absolutely hundreds of them and it would take hours of arduous effort?

I think this calls for a split of these categories. I'm not sure how to do Information needed, Verify and Stub, but Unknown version history seems rather basic; splitting by edition and then by development period would probably dice it up into manageable chunks. Of course, it's no secret that the history template itself has a fair share of other issues that need working out, so maybe this category splitting thing could be done en route. Does anyone have any ideas as to how the other three (and any other problematic categories) could be divided up into bite sized chunks? - User-12316399 (talk) 09:02, 8 October 2019 (UTC)


 * I don't know information needed or verify either, but at least stub could be gone through and split on a case by case basis by adding an additional argument into the template call, such as a particular type of page (like content, project, person, version, etc). Of course it can already be split between full-page and section-specific, by detecting whether or not that argument was specified. Good idea to start with these categories before any big history template overhaul, because missing information always makes things like this difficult. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:09, 8 October 2019 (UTC)


 * Every so often I scroll through Category:Verify and fix what I can. I do agree that it should be split more since I just deal with modern Java when I go through the list. There should be a verify or something to exclude history verifications, and unknown v.h. should definitely be split by edition; that doesn't seem difficult to do. <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> 00:38, 9 October 2019 (UTC)
 * Since history already checks which edition is being referred to, it should not be difficult to have categories for "Unknown Bedrock Edition version history", "Unknown Java Edition version history", etc. The BlobsPaper.png 01:22, 9 October 2019 (UTC)
 * Category:Testing needed and Category:when are out there, too. – Sealbudsman talk | contribs 01:43, 9 October 2019 (UTC)

I've done a kind of sloppy split of the missing version history category, which does seem to work. There might be some formatting edge cases screwing it up somewhat that I haven't accounted for yet though. - User-12316399 (talk) 10:35, 9 October 2019 (UTC)

I think we should also somehow distinguish between things that we don't know but can currently test, and stuff we can't currently test due to reasons (e.g. the version a change happened in not being archived). This should be easy to do for templates like verify. I'm not sure how we'd deal with this in the history template. If anything we should start a discussion of revamping the history template sooner rather than later. - User-12316399 (talk) 09:30, 29 October 2019 (UTC)
 * I have an idea to further split unknown version history. We have already proposed to distinguish editions, but we could also distinguish releases from development versions. If we know which release a change was made in, but not which development version, that is better that a completely unknown version history. The BlobsPaper.png 00:14, 3 November 2019 (UTC)
 * One category per release version then? - User-12316399 (talk) 09:32, 3 November 2019 (UTC)
 * Yes. We would have Unknown Bedrock Release, Unknown Bedrock Beta, Unknown Java Release, Unknown Java Snapshot, Unknown Education Version, and Unknown Legacy History (for Legacy Console, and New Nintendo 3DS). The BlobsPaper.png 14:50, 3 November 2019 (UTC)


 * For unknown development versions would it be possible to categorise by version and not just development stage? - User-12316399 (talk) 07:50, 9 March 2020 (UTC)


 * Okay, did that and we now have even more unknown version history categories, and it seems to be working mostly as intended, so this should split things up into yet more manageable chunks. - User-12316399 (talk) 12:56, 9 March 2020 (UTC)

Module/database thing for infobox values
Currently, blast resistance values are added to infoboxes via being loaded from a module Module:Blast resistance values, while all other block-related values are specified manually on the page. On discord yesterday I proposed that this concept could be expanded to other values related to blocks (and, by extension, items, entities and other stuff), and it raised a head or so. Would this be useful at all?

The values we'd need to implement into this new module table thing of doom:


 * Blast resistance (number) (already done)
 * Hardness (number) (already done, but in a different way that isn't inherently called by the infobox)
 * Luminance (number)
 * Flammability (number)
 * Fire encouragement (number) (not yet in infoboxes)
 * Catches fire from lava or not (boolean)
 * Slipperiness (number) (not yet in infoboxes)
 * Entity movement multiplier (one or two numbers, as some blocks like cobwebs can have different y and xz movement speed modifiers) (not yet in infoboxes)

For items (and blocks that exist as items):
 * Renewability (boolean)
 * Stackability (number)

Other stuff, like the needed tool and the IDs, would probably still be specified manually, and yet other stuff, like drops and experience, will probably be deprecated as I've mentioned here before. Are there any other notable values that we could add? - User-12316399 (talk) 12:01, 10 October 2019 (UTC)


 * Why does the word "Cargo" come to mind? --AttemptToCallNil (report bug, view backtrace) 14:54, 10 October 2019 (UTC)
 * I definitely support the new parameters, such as movement speed and slipperiness. The hardness and blast resistance values are used outside of infoboxes, but not all parameters are. I would support having a module in this case so we get the same value across pages. I would not support a module for renewability because the Renewable resource and Non-renewable resource pages would still need to list the items manually. The BlobsPaper.png 23:51, 10 October 2019 (UTC)

About transparency and documentation of its behaviors
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. <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> 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 tryashtar 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)

Having old sprite textures on, for e.g, snapshot pages
Hello, should we use old sprites textures for old content like snapshots before Texture Update ?

Thank you, 78.193.28.136 10:04, 20 October 2019 (UTC)


 * All visual content such as screenshots and renders should have up to date textures whenever possible. The only exception is when displaying content that is exclusive to an older version. -PancakeIdentity (talk) 17:21, 20 October 2019 (UTC)


 * OK then, I will take in charge some snapshots. 78.193.28.136 12:34, 21 October 2019 (UTC)


 * Up-to-date content should be used on non-historical pages/sections. Version pages are historical pages, and therefore it would make a lot of sense for images to remain accurate to that version, which can be more easily done with images being separately versioned now. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 08:22, 4 November 2019 (UTC)

Definition of "Partially Implemented"
The Bedrock Edition mentioned features page defines partially implemented as features that "had been shown by a Mojang staff member, but either had no further development or were canceled shortly after". (I think the Java page uses a similar definition). This is not intuitive to readers. In fact, it is contradicted by saying that Java Edition 1.9 combat mechanic have been partially implemented with shields and the off-hand slot.

I think the meaning the phrase "partially implemented" is obvious enough to most readers if it refers to combat mechanics and similar features. What we should do instead is rename the "Partially Implemented" sections. Since these features were "added" shortly after being mentioned, I propose the term "Mentioned with partial implementation". However, feel free to give other suggestions. The BlobsPaper.png 04:21, 23 October 2019 (UTC)
 * I think the best option will be in section "Deleted features" --Rychlik (disc) 12:17, 23 October 2019 (UTC)
 * Many readers would confuse that with removed features. The BlobsPaper.png 13:44, 23 October 2019 (UTC)

Java Edition guides expand
In last 2 months (September - October) we created 7 new guides, but now there are only 2 guides to compleate Full Release guides, so it will be good idea to add new sections for Alpha and Beta Java Edition Guides. Now, I need only your support. Thanks. --Rychlik (disc) 13:50, 24 October 2019 (UTC)

Discussion management: existing measures aren't working
Since the hot discussions list on the community portal and the #talk-highlights channel in Discord don't get much attention, an idea was proposed to have a dedicated page on the sidebar.

Draft: User:FVbico/Open discussions.

My feedback is that we should probably not overcomplicate the classification (so maybe no minor/average/major) and rename "Moderation" to "Policies and guidelines".

Any other comments? --AttemptToCallNil (report bug, view backtrace) 15:17, 28 October 2019 (UTC)


 * Just for info, I added the minor, major average as in how much it would affect the wiki; changing NBT tag is much less significant than refactoring edition specific info. FVbico (talk) 16:09, 28 October 2019 (UTC)


 * How would one determine the scale of changes some discussion involves, if they want to know which of the three categories to put an entry into? Or what if someone decides to dispute the categorization as minor/etc? --AttemptToCallNil (report bug, view backtrace) 16:27, 28 October 2019 (UTC)


 * "How much would this affect the wiki as a whole?", the answer eould be the section to put it in. You got a point though, but I thought it'd help keep the focus with the biggest things. FVbico (talk) 22:53, 28 October 2019 (UTC)


 * First, a more indepth explanation for each of the categories could be phrased in the lead section, and second, you could also rename them in a more concrete way, such as wiki-wide, page, template. Or use multiple choice labels instead of single-parent categories. Just some tips for this page. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 23:09, 28 October 2019 (UTC)


 * I like the idea of having summaries of important discussions. Some time ago I proposed (on Discord) to occasionally add links to important discussions to the top of recent changes, although I'm not if that would be considered too intrusive. – Sonicwave talk  05:34, 3 November 2019 (UTC)

On sounds
All sounds should now be split into a dedicated section which provides much more information than was given for them in the infobox. There's a few things that need cleaning up now:

File names
File names for sounds don't seem to be standardised like many images tend to be. Is there a standard for sound naming, and if not, what should it be?

Missing sounds
The splitting of sound sections has helped to highlight what sounds are missing from pages, organised into a maintenance category Category:Pages with missing sounds. This should give a better idea of what needs uploading than the table on the associated wiki project.

Pitches
For sounds which are always played in-game with a different pitch than their actual sound file, should we only upload the original sound file and let the table's pitch parameter do the talking, or should we upload an artificially pitched up/down version of the sound instead?


 * I've brought up the idea of sounds being artificially pitched up or down using a script, would anyone else agree with this? - User-12316399 (talk) 09:27, 21 November 2019 (UTC)

Block sounds
Sounds for the placement, breaking, destruction, walking on and falling of blocks should be next up to be uploaded (except for slime blocks, which are already sorted). These can be found at Category:Pages with missing sounds/Blocks. I've only added tables to one page per material type so that it doesn't become a particularly gigantic maintenance task, as the table with filled in sounds can then be pasted onto other pages. So if anyone's willing to upload these sounds I'd be more than happy.

Block sounds are pretty much done now - the only ones remaining are a few edge cases which will need more investigation, as well as jumping sounds exclusive to Bedrock Edition, with the discussion of how Bedrock Edition sounds will be represented still underway; see section below. - User-12316399 (talk) 09:27, 21 November 2019 (UTC)

Parity
The tables I've added are based solely on information from Java Edition. If we're also to document Bedrock Edition sound related information where differences exist, how should we represent it? Should we create separate tables for Java and Bedrock Edition values, or mix them into the same table?
 * We should put them in the same table. I assume most, but not all, of the sounds match, so having them as separate tables would result in a lot of duplication. The BlobsPaper.png 13:57, 30 October 2019 (UTC)


 * I believe that Bedrock uses completely different sound IDs ( instead of , for example). We could make another column for it (making the table wider than it already is), or put the JE and BE IDs on different lines, which would probably lead to lots of [only] tags. – Sonicwave  talk  05:59, 3 November 2019 (UTC)

The more I think about it, the more having two separate tables becomes the more appealing option. Given that there's still some new types of columns I want to add to the tables, having all the info being mashed into a single table does not sound useful. - User-12316399 (talk) 19:48, 13 November 2019 (UTC)

I've added an example section to Stone which utilises separate tables for Java Edition and Bedrock Edition. I'm going with this since sound events seem to be always naked differently across versions, as well as the fact that certain sounds are version-exclusive (such as the jump and land sounds shown), that Bedrock Edition doesn't have subtitles, pitch and volume values being different across versions as well in some cases (usually being ridiculously long and precise in Bedrock) and that the attenuation distance parameter also seems to be Java Edition exclusive. If people would still rather have them be mixed into the same table then say so, but it's not what I think we should go with. - User-12316399 (talk) 08:57, 19 November 2019 (UTC)

Historical sounds
There's also plenty of cases of sounds which have changed throughout the game's history, such as skeleton sounds, and there are also sound differences between the history of the editions, such as breaking blocks in the alpha versions of Java, iOS and Android. These should also be uploaded eventually.


 * Created Category:Pages needing sounds/Historical sounds, which should cover most of the stuff (the block sound differences seem to be merely pitch based). - User-12316399 (talk) 09:27, 21 November 2019 (UTC)

Anyway, that should be about it for sound-related topics. If anyone wants to start work on any of these or comment on them then please do. - User-12316399 (talk) 08:53, 30 October 2019 (UTC)


 * The "Min. Volume" column should be removed, since it's not a field in sounds.json (at least for Java Edition) and only applies to the playsound command, not sounds played by the game by default. Sounds that play at different pitches in-game than the sound file should follow the in-game pitch, since that's what people would expect to hear (and some of them can quite different and hard to "derive", such as the zombie pigman's angering sound).


 * I'm still not sure about the "Pitch" and "Volume" columns; they specify the sound's ingame pitch/volume relative to the sound file, instead of relative to other sounds (which one might expect). There should at least be a tooltip explaining what they specify. – Sonicwave talk  05:48, 3 November 2019 (UTC)

Add item icons to infoboxes where the item has a different texture than the block
Should we add item textures to infoboxes where the blocks/items have different textures? Pages like string, crops, campfire, bell, etc. I would also like to do this for entities, like boats and armor stands. It seems there was support for doing this with crops in above talk sections, and I personally would doing this for all items.

The main argument against this that I'm predicting is that there's an invsprite in the infobox showing the item textures. While this is true, item-only pages, such as diamond, have both the large icon and the invsprite. -PancakeIdentity (talk) 00:28, 10 November 2019 (UTC)


 * FVbico (talk) 00:30, 10 November 2019 (UTC)
 * as the full-sized images are quite useful for people quickly wanting to download texture files. <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> 06:20, 10 November 2019 (UTC)
 * - the only reason that items display large versions of their texture files in the infobox is because that's the image that describes the item the best and there's no better image. Having a massive item texture there alongside the existing 3D render would just clutter the page and add nothing of value. - User-12316399 (talk) 13:56, 10 November 2019 (UTC)
 * "Would just clutter the page and add nothing of value" – This has never seemed to stop you before. <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> 04:48, 12 December 2019 (UTC)
 * for both blocks and entities. --Capopanzone (talk | contribs) 10:21, 11 November 2019 (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 <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> 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)

Articles on Mojang staff and related persons - do we really need them?
Except for perhaps the most notable people, do we really need articles that get almost no editor attention and rarely exceed a couple short sentences? I don't see how most of them are even relevant. Even spin-off titles like Story Mode or Dungeons are more relevant, I think. --AttemptToCallNil (report bug, view backtrace) 18:56, 23 November 2019 (UTC)


 * I feel like, at best, we should try to expand the articles as much as possible, much like how Wikipedia does it with their policy on biographies of living persons, making sure that information about them is backed up be reliable sources. I do recall mentioning back in 2015 that we could possibly use LinkedIn profiles as a source for reliable information, though discussion never went anywhere beyond that. -BDJP (t 21:30, 23 November 2019 (UTC)


 * We mention devs pretty often in history sections, and it might be useful to have these pages in those cases. Especially when they commonly go by nicknames (i.e. Jeb or Dinnerbone). Other than that, I don't know. I would like to see the general staff page updated though. -PancakeIdentity (talk) 04:41, 27 November 2019 (UTC)


 * Other than the obvious ones I think there should just be an "employees" page that lists mainly job-related info; this also avoids the BLP issues we've had in the past. <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> 06:03, 27 November 2019 (UTC)


 * I would support having a Mojang employees page, consolidating the short pages there, and having a link from there (after a brief overview) to longer pages like for Jeb. &#8212; Memetics  talk &#124; edits 22:42, 10 April 2020 (UTC)

Official Minecraft wiki
The result of the discussion was the issue was addressed. Mojang will not call this the official wiki as they do not own it.

So, if you visit the minecraft.net Community page https://www.minecraft.net/en-us/community and scroll nearly to the bottom, above Discussions & Help, there is a link to the "Unofficial Wiki"... which goes to this wiki.

I did a little search of the wiki here and found no mention of this unofficial link.

Discuss.

Sorry for being lazy and not creating an account. 49.178.46.161 13:40, 30 November 2019 (UTC)


 * User:FVbico mentioned on the wiki Discord that he contacted User:HelenAngel (the community manager) about this, as she has previously stated in a Discord private message that "the wiki is official and officially endorsed". While most of the content here is written by community members and Mojang doesn't take part in day-to-day editing activities, they do maintain some official documentation pages. – Sonicwave talk  18:19, 30 November 2019 (UTC)


 * Okay, I asked about it, and minecraft.net is right; the web team was told that since Mojang doesn't own the wiki, it cannot be called official. FVbico (talk) 16:42, 3 December 2019 (UTC)


 * Interesting. What does that mean for the opening... Welcome to the Official Minecraft Wiki on the homepage? --Thefakesheep (talk) 23:03, 3 December 2019 (UTC) (OP here)


 * While it is not technically an official wiki, it is probably the most credible Minecraft wiki, since the developers have acknowledged (and even created) the necessary pages. The BlobsPaper.png 04:10, 4 December 2019 (UTC)


 * This somewhat implies that they consider what is official, and there is a possibility Mojang will have their own "official" wiki/resources. It will be otherwise if they don't care about the wiki being the official nor non-official. – ItsPlantseed ⟨₰|₢⟩ 07:51, 4 December 2019 (UTC)

Cannot do the ScreenShoot Licence Project
The file MediaWiki:Msu-comment cannot be edited and I would like to licence it with "free art". --Andrew36903690 (talk) 08:59, 11 December 2019 (UTC)


 * That would change the default license for every file uploaded using msupload, which we can't be sure about the correct license. You will need to edit the file pages manually after the upload add the license or use Special:Upload.  HorseHead.png Gamepedia icon.png MarkusRost (talk) 09:42, 11 December 2019 (UTC)

Make templates for common NBT practices.
NBT have several basic tags, and there are many common practices in Minecraft: Java Edition based on those tags. Mojang does use some functions to parse these practices accordingly, I showed three of them here using yarn's mappings:
 * Boolean-like TAG_Bytes: Parsed by . They are technically TAG_Bytes. They use   to represent , and all the other possible values to represent  . e.g.   tag for entities. I've made a possible template User:SPGoding/Sandbox/Nbt practice/boolean for them:
 * UUID: An TAG_Int_Array with four TAG_Ints which represents the bits of an UUID. I've made a possible template User:SPGoding/Sandbox/Nbt practice/uuid_longs for them:
 * Block state TAG_Compounds: Parsed by . A TAG_Compound with a TAG_String named   and a TAG_Compound named   with all the block properties stored. e.g.   tag for enderman entities.

Currently we have Template:Nbt inherit for inheriting NBTs from a parent, but we don't have similar things for those common practices, which leads to copy-pasting similar texts for many times. Thus, I propose to make templates for these practices. -- SPGoding [  Talk  ] 19:34, 21 December 2019 (UTC)


 * How they function may be similar, but this would result in complicating the NBT providing even more (it's already complicated for people unfamiliar with the wiki to provide or correct NBT info). Additionally, UUID tags are extremely invonsistent in java, it's one {l:,m:}, another time Least:,Most: and another time UUID:""; you cannot template that.
 * In short, it'd complicate the most complicated part of the wiki even more, needlessly. FVbico (talk) 20:17, 21 December 2019 (UTC)


 * Thanks for your quick reply. However, I don't think this template would complicate things too much, to the contrary, it would make changing similar stuff easier. For instance, the function Mojang used to get a  has been called for 5 times. Let's see how many times they have been changed on this Wiki:
 * Chunk_format/Vehicle
 * : Optional. The custom block in the minecart.
 * : The namespaced ID of the custom block.
 * : Optional. The block states of the custom block.
 * : The block state name and it's value.
 * Edit 1243175: First introduced.
 * Edit 1255212: Change the format of.
 * Edit 1379673: Change  to.
 * Chunk_format/Projectile
 * : Optional. The block the arrow is in.
 * : The namespaced ID of the block.
 * : Optional. The block states of the block.
 * : The block state name and its value.
 * Edit 1243162: First introduced.
 * Edit 1255211: Change the format of.
 * Edit 1379671: Change  to.
 * Edit 1379674: Change uppercased  to.
 * Piston/BE
 * : The moving block represented by this block entity.
 * : The namespaced ID of the block.
 * : Optional. The block states of the block.
 * : The block state name and its value.
 * Edit 1242720: First introduced.
 * Edit 1255215: Change the format of.
 * Edit 1379679: Change  to.
 * There are still two pages (Sand/BE and Enderman/ED) with the similar situation, but I believe there's no need to put them here anymore. I'm sure everyone can find where the problem is: people have to update the 5 pages individually if they want to improve the content of the BlockState structure. I believe this is much more complex than simply updating one universal template, and I believe you are more aware of this than anybody else because all these awesome changes are just made by you. Moreover, the function used to read boolean-like TAG_Bytes has been called 84 times, which means if anyone want to update the current description of it, they have to change tons of pages seperately. However, if we had a template for those common cases, this would no longer be a problem.
 * Here is all my opinion, I really appreciate for your patience. Merry Christmas! -- SPGoding ( Talk ) 23:10, 21 December 2019 (UTC)
 * Edit 1379679: Change  to.
 * There are still two pages (Sand/BE and Enderman/ED) with the similar situation, but I believe there's no need to put them here anymore. I'm sure everyone can find where the problem is: people have to update the 5 pages individually if they want to improve the content of the BlockState structure. I believe this is much more complex than simply updating one universal template, and I believe you are more aware of this than anybody else because all these awesome changes are just made by you. Moreover, the function used to read boolean-like TAG_Bytes has been called 84 times, which means if anyone want to update the current description of it, they have to change tons of pages seperately. However, if we had a template for those common cases, this would no longer be a problem.
 * Here is all my opinion, I really appreciate for your patience. Merry Christmas! -- SPGoding ( Talk ) 23:10, 21 December 2019 (UTC)


 * . I think it's the right idea, and if you can solve FVBico's objection to UUIDs where "you can't template that", then I feel it's got no major problems. Yes, doing the nbt templates is complicated, but I don't see this adding significantly to that, relative to the benefit. – Sealbudsman talk | contribs 15:47, 4 January 2020 (UTC)


 * Just wanted to say, the UUID issue is fixed in the 1.16 snapshots. -PancakeIdentity (talk) 06:04, 17 March 2020 (UTC)
 * I've updated the demo template. Thanks for telling me! SPGoding  ( Talk ) 01:51, 21 March 2020 (UTC)

Trading information on pages
Hello! My suggestion is make a template to automatically insert trading informations on the page from a database, like LootChestItem already do. For example:


 * Leather page == Usa ge == === Tradi ng ===

I hope you got it. This would make it a lot easier when adding new blocks and items or even in a new makeover in the trading system.(Mojang is unpredictable)

Thank you! --dr03ramos (talk) Admin wiki[pt] 21:51, 1 January 2020 (UTC)


 * Not sure how we'd make those, but FVbico (talk) 21:54, 1 January 2020 (UTC)


 * that would be really useful so -Hanzepic (talk • contribs) 14:53, 4 January 2020 (UTC)


 * If you can do it, that would be great, yes – Sealbudsman talk | contribs 15:37, 4 January 2020 (UTC)


 * though I'd much prefer a dedicated template for trading like with crafting. - User-12316399 (talk) 16:05, 4 January 2020 (UTC)


 * If you can get someone willing to do it, this would be very helpful. -PancakeIdentity (talk) 00:16, 5 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. -- <b style="color:aqua">DigiDuncan!</b> (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)

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 [ Grid Book and Quill.png Grid 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)

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)

Chunk Loading overhaul
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)

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)

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)

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)

Remove Spawn Chunks page
Note that I wrote my original suggestion in big hurry and i felt it was bad so I rewrote it here.

Hello. I updated chunk loading and still am and i realised how much outdated/wrong spawn chunk page was. I suggest its removal and here are my reasons:

1) Spawn chunks are not special, but normal chunks that are loaded by the world spawn that gives them "Start" load ticket. They are not special on their own.

2) They are all the same as chunks loaded by player or forceload. Something Ill edit in forceload too. They are exactly the same in every load regard, but loaded by different thing. This is because they all get load level of 31 or bellow, which makes them "entity ticking" and that is the highest level of loaded chunks. They dont spawn mobs thought, BUT that is only if and because player's area where mobs despawn/spawn is away.

3) Actually there is only one chunk that gets loaded by the spawn but the load levels spread to adjacent chunks until theyre weak enough to not load chunks. This start ticket is just strong enough that it activates lot of chunks.

4) There are more unique chunk loading things similar to spawn chunks, if we would need page for spawn chunk need another like 3+ pages which is useless.

These are my reasons, I think removing that page and seriously improving ita section in chunk page will do better. Thank you for your time. Klusimo (talk) 07:04, 9 March 2020 (UTC)


 * There are already a page for bedrock edition - ticking area, why not create another new page with title like processing chunk only for java edition, and move all the information about chunk loading to these two pages. Then create a disambiguation page contains chunk, ticking area, processing chunk, commands/forceload, commands/tickingarea, and so on. That Spawn chunk can be redirected to processing chunk. These are my suggestions so you could take it if you like. -Chixvv (talk) 10:50, 9 March 2020 (UTC)
 * Not bad idea but rather that "processing chunk", i think Chunk loading would be better. But I think its too complicated when we have it in chunk page (also not much would be left in the chunk page). In both scenarios removing spawn chunk page is what would be optimal.Klusimo (talk) 11:09, 9 March 2020 (UTC)
 * i think Java edition and bedrock editon should not be treated differently. so we can merge ticking area to chunk, or create a new page for java edition. since there isn't much useful information in ticking area(it only introduces that in ticking area events are processed and other chunk not), perhaps merge ticking area to chunk is also a choice. In doing so, both spawn chunk and ticking area page should be removed.-Chixvv (talk) 11:39, 9 March 2020 (UTC)
 * Agree, I will definitely add it there. So now we also have suggestion to remove ticking area once i merge it. forceload should be removed too. Klusimo (talk) 08:07, 10 March 2020 (UTC)
 * Added ticking area to chunk page. Now we only need to remove spawn chunks forceload and ticking area page. (Definitelly not their command pages).Klusimo (talk) 08:33, 10 March 2020 (UTC)
 * Ok, so update to my suggestion, since their pages are stubs and it is already in chunk page now, i suggest removal of spawn chunks/forceload/ticking area pages(not their commands pages though). Klusimo (talk) 08:35, 10 March 2020 (UTC)
 * deleting these pages, at least with Chunk's current state. Spawn chunks are only described by the brief start ticket section. To figure out how the spawn chunks work, a reader has to read technical information about chunk levels and level propagation. The spawn chunks page may need updating, but it readily provides the size of spawn chunks, what runs in spawn chunks, and where entities work in the spawn chunks. I don't think all of this information is easily available on the chunks page. There is not enough information about ticking area either. The ticking area page provides information about which events can run and which events are suspended that isn't described on the Chunk page. While it would be possible to merge more information into Chunk, I don't know if that would be a good idea as I feel like it would make it more difficult to find information.
 * Instead, I would say that the Spawn chunks page should be updated with more recent information. It should be explained that the spawn chunks have a level of 22 which means that "All game aspects are active." A table or image should be made which shows level propagation in the spawn chunks. It can then be explained how the edges of the a spawn chunks do not process entities since they have a level of 32. All of this should link to the Chunk page for more a thorough and technical explanation. jahunsbe (talk) 19:12, 12 March 2020 (UTC)
 * I get what youre saying but instead of that you can create secction in the chunk page. Its a stub after all now and it needs alot of testing, editing etc. so we can easily add more info about spawn chunks here. The thing is you can update several pages or have one page with all the info. It just needs more edits. You can contribute yourself. Klusimo (talk) 08:51, 14 March 2020 (UTC)


 * I'd oppose deleting it on the basis of "it's short and incomplete/outdated". The solution should be to update and expand the article, not remove it entirely. -PancakeIdentity (talk) 19:23, 3 May 2020 (UTC)

Changes to the upcoming template (and similar)
From here on out, Bedrock and Java will match version numbers. I was thinking that to avoid spam and compress those ugly upcoming tags, we could just allow, for example, upcoming to be used. Individual versions could still be used for version exclusive features, of course. This would help compress those editor notes which can make pages look ugly and harder to read (See Log for example). I think this, along with the proposal above about modifying the in template, would help us greatly improve the readability of articles. -PancakeIdentity (talk) 04:50, 17 March 2020 (UTC)
 * We could have "1.16" redirect to Nether Update, to include both editions. The BlobsPaper.png 15:16, 17 March 2020 (UTC)
 * . --dr03ramos Piston.gif (talk) Admin wiki[pt] 21:03, 18 March 2020 (UTC)


 * A couple notes from a discussion on discord: INUpcoming and inUpcoming could say "In the Nether Update (1.16), ...". In the normal upcoming template, we could also say "Nether Update" as opposed to "1.16". Just a couple more ideas. Personally, I'm neutral on these specific suggestions. -PancakeIdentity (talk) 02:19, 19 March 2020 (UTC)
 * unless Mojang doesn‘t keep up this consistency. I'd be happy to update/create/fix templates like in etc if needed. <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>


 * I tried implementing something like this, but I couldn't get it to work. I could get Nether Update, but not the other way around. If someone who has more template knowledge than me wants to give it a try, you can edit User:PancakeIdentity/UpcomingMockup. -PancakeIdentity (talk) 23:05, 10 April 2020 (UTC)


 * Yeah, I think it's too long to type "upcoming JE 1.16 & BE 1.16.1" a million times. I'll try to see if it works, your suggestion. 13:48, 25 April 2020 --106.201.186.23 08:18, 25 April 2020 (UTC)


 * These templates are functional in my userspace. User:PancakeIdentity/UpcomingMockup, User:PancakeIdentity/UntilMockup, User:PancakeIdentity/InUpcomingMockup, User:PancakeIdentity/InUntilMockup. They could be implemented, but they no longer accept a 2nd version argument so cleanup will need to be done. -PancakeIdentity (talk) 01:18, 22 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 No unique drops 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. No unique drops 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)

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)

Split in Tutorials/Cobblestone farming and Tutorials/Stone farming
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
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)

Should sprite files be interlaced?
Currently, sprites (like [[Media:InvSprite.png|InvSprite.png]]) are not interlaced, which means they will load downwards. If you have a slow connection (or enable slow network simulation in browser inspector), you can see content on the top show up first. So, in a normal page, those sprites coming in later versions will take a while until anything show up. After interlacing these pngs, we can expect the sprites to show up immediately blurred and then fully displayed after loaded, as the pixels are downloaded in a chessboard pattern. (check this for detail)

tl;dr: With interlacing, the sprites load up faster but will start blurred. Without interlacing, the sprites in the bottom will take a while to show up. Should we interlace the sprite files, or rearrange most-used sprites on the top?

-- CuervoTalk 06:27, 25 March 2020 (UTC)


 * I would support interlacing. Otherwise we would need to update the sprite positions, and the incorrect sprites may appear for the next day due to server cache. The BlobsPaper.png 15:15, 25 March 2020 (UTC)


 * Do we even still need sprite sheets? --AttemptToCallNil (report bug, view backtrace) 17:15, 25 March 2020 (UTC)


 * I doubt it, unless InvSprite pulls directly from that big image. -PancakeIdentity (talk) 21:14, 25 March 2020 (UTC)


 * PancakeIdentity@undefined The sprites are directly pulled from the large images; deleting these images would break the templates. The BlobsPaper.png 02:18, 26 March 2020 (UTC)


 * I meant, why not go back to the old system of individual files per image? The performance issues seem to no longer be substantial (there are issues if you're using, like, _hundreds_ of different images per page). As for the sprites in navboxes, they're not really needed; the large navboxes themselves could be candidates for deletion as they aren't very effective for navigation (a task better accomplished by a well-designed category system).
 * I should also note that there's the possibility that with the transition to UCP, functionality critical to the sprite system may become unsupported without any replacement (except to use individual files). --AttemptToCallNil (report bug, view backtrace) 09:42, 26 March 2020 (UTC)


 * iirc, sprites are introduced to optimize numbers of HTTP request, thus reducing protocol overhead. And on the SEO side, search engines seem to favor well-written sites. I know HTTP protocol has been overhauled in recent years but I'm not a web developer, so I don't know if these theories are still true today. For templates, it's true templates aren't intended for navigation on MediaWiki, but the readers would prefer easy-to-read template rather than plain category page imo. CuervoTalk 16:39, 27 March 2020 (UTC)


 * I'd this, although the Sprite editor would have to be changed to support this feature. Also, is there a variation of progressive JPEGs for PNGs? These first load a really low quality version of the image before scaling up the resolution once more of the image loads (for 16x16 images it wouldn't appear much different at all). <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:42, 31 March 2020 (UTC)

Names for wood variants
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)

Test and add new mood algorithm for cave ambience
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)

Cleaning up the meaning of "1.16"
Should we change pages such as the 1.16 disambig page to be a bit more useful?

Recently on discord, said that the classification of the old Playstation versions of 1.16, completely unrelated to the upcoming Nether Update, were confusing (link image). I agree with this sentiment; especially now that version numbers will match on Java and Bedrock, listing these old versions prominently with the Nether Update 1.16's in places such as 1.16 and Java Edition 1.16's sidebar can be very confusing.

In addition, were we to implement the above suggestion of allowing 1.16 and similar formats to be used, the "1.16" page would be really nice to have directly linked to the Nether Update page.

This change would also obviously any future (1.17+) versions, though I don't think it'd be necessary to apply it to older versions, as many of these issues don't apply there. -PancakeIdentity (talk) 02:22, 1 April 2020 (UTC)
 * I don't see the issue here. I fixed the wording of the version nav to be less confusing, and the disambiguation page is just leading to different 1.16s. <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:36, 1 April 2020 (UTC)


 * My main concern was with the possible new 1.16, linking to a disambig page where 1/2 the pages linked aren't about the intended version might not be a good idea. We could do something like "1.16 redirects here. For other versions numbered 1.16, see [links to the PS 1.16s]." -PancakeIdentity (talk) 05:56, 1 April 2020 (UTC)


 * this. Redirect 1.16 to Nether Update, and put a hatnote on the top of the page to something like 1.16 (disambiguation). Thomanski (talk) 14:16, 1 April 2020 (UTC)


 * Yeah, this is what I was thinking. -PancakeIdentity (talk) 23:06, 10 April 2020 (UTC)
 * I think it's too soon to do stuff like this. For all we know Bedrock could once again start releasing nothing updates again. "1.16" as a disambiguation works fine and in my opinion is the least confusing way; when you search "1.16" you get a disambig instead of a short page that makes it look like (on first glance) that a comprehensive changelog page doesn't exist, which may be off putting for readers. Putting the year in front of the disambig items also alleviates confusion as to whether PS 1.16s had the nethere update, etc, or not. <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:15, 20 April 2020 (UTC)


 * Except they've literally said they intend to keep Java and Bedrock version numbers in line from here on out. Everything else, I understand. But I don't think it makes sense to assume things will change for no reason when they've said otherwise. But yeah, I don't really think it's needed anymore. ATCN managed to solve the upcoming template issue which was my main concern. -PancakeIdentity (talk) 05:42, 20 April 2020 (UTC)
 * I know what was said, but Mojang have said a lot of things like that which don't end up happening. Especially when the quote is "That is the plan…" instead of something like "Yes, that is what we'll be doing from now on". Anyway, whatever. <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> 05:48, 20 April 2020 (UTC)

Amount of detail covered in version pages
The result of the discussion was implement revised proposal. An agreement was reached regarding a revised proposal and it has been added to the Style Guide.

The amount of detail covered for the addition of specific blocks, items, mobs, and gameplay features in version pages is very inconsistent. Many of the newer update pages (such as Java Edition 1.16) are very long because they contain extremely detailed information about every feature. For example, the addition of Piglin in the mobs section has 20 total bullet points covering it, which obviously takes up a lot of space. However, I've noticed that many of the older update pages don't go into nearly this much detail. For example, Java Edition Alpha v1.2.0 contains simply a list of blocks and items in the Additions section, although it does go into a bit of detail in the mobs section. Java Edition 1.0.0 is sort of in between the two pages; most of the new features in this update are covered in 1-3 short bullet points.

Another factor to consider is named update pages. In the past, the named update pages have only listed features and contained no detail at all, with the actual numbered version pages having the detail. For example, see Redstone Update and World of Color Update. However, recently even these types of pages have started having a substantial amount of detail (although admittedly not quite as much as the equivalent version page(s)), as seen with Update Aquatic and Village & Pillage.

My proposals are:


 * Condense all new additions in any full update page (includes minor updates but not snapshots or update title pages) so each feature is covered in 1-4 short bullet points. I think doing this would allow for the best and most useful overview of the update. Not covering any detail at all would not be ideal imo because someone wanting an idea of what the update is about would only see a bunch of names listed and no description of what they are/do. However, the level of detail we cover now I feel is way too much; it's difficult to find everything the update has added because there is so much information on the features themselves. Furthermore, there's no reason this should be necessary; nearly all Additions have their own pages that are linked to right there, so having 10 or 20 bullet points for every feature is basically just copying those individual pages over in a different form.
 * The exception to this is the rare case that the Addition does not have its own page. In this case, it seems reasonable to put as much detail as needed.
 * Changes can be as detailed as needed while still being useful unless they have their own page. The features mentioned in the Changes section of version pages typically don't have their own page and therefore describing them on the version page would be the best situation. However, for the rare cases that the change is substantial enough to have its own page, just summarize the change on the version page and link to the more detailed page.
 * I'm not sure what the best case would be for snapshot pages. While I don't necessarily see a reason why we need to go into much detail there either, they're also generally fairly short so it wouldn't hurt to do so.
 * I'm also not sure about named update pages. I definitely think the descriptions of features should be at least as short as those of version pages would be, but I don't know if having the 1-4 short bullets or simply no description at all would be better. No description at all is what has been done in the past, but named update pages aren't typically much longer than their equivalent numbered version pages, so I doubt having the same short descriptions would hurt anything.

Just curious of any thoughts on this matter, as for a long time I've noticed the inconsistencies among version pages as well as how unnecessarily long the more recently created version pages have been. Note that even if everyone shuts down these suggestions, we still need to establish some kind of consistency. For example, if it is decided that 1-3 short bullet points is not enough, it would make sense to have to make the feature descriptions longer for every version page, not just the more recent ones.--Madminecrafter12 (Talk to me 16:11, 3 April 2020 (UTC)


 * Why does this remind me of how we're recommended to write introduction sections? Perhaps the same approach to writing introductions could be applied to condensing huge description lists?
 * Pages don't need to be long; I think this condensing should apply to snapshots regardless of article length. --AttemptToCallNil (report bug, view backtrace) 16:22, 3 April 2020 (UTC)


 * I definitely agree with condensing the amount of detail on version pages, Java Edition 1.0.0 looks like the right amount of detail to have. I also agree that this should apply to snapshot pages as well, especially given that content is usually just copied from there onto the full version page. – Sonicwave talk  16:27, 3 April 2020 (UTC)
 * That level of detail belongs on the page about the features, not the versions. On snapshot pages, we can add details if they are different from the latest snapshot (for example, hoglins dropped rotten flesh in the first 1.16 snapshot). The BlobsPaper.png 16:39, 3 April 2020 (UTC)
 * Just adding that whatever we decide here will probably also involve adding to, changing, or clarifying the versions style guide.--Madminecrafter12 (Talk to me 16:41, 3 April 2020 (UTC)


 * Please no. any change. The articles should contain the same amount of detail as be version articles currently do, i.e. "as much as is needed". It's just so much more useful when browsing through old snapshots to see exactly what this feature does at this time. About what Blobs said, ~"we should go back and change it when its changed in a later snapshot"~ would never work in practice, it's hard enough to get the history sections fully maintained let alone tons of snapdhot pages. And who cares if the pages are long, they should be, it's a good thing, that's the target; its really not an issue. Even 1.8 is fine to navigate. <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> 22:53, 3 April 2020 (UTC)


 * , Nixinova said it well. ―HalfOfAKebab (talk, contribs) 20:31, 14 April 2020 (UTC)


 * What Nixinova said, . I agree it's inconsistent, but that was also like at least 7 years ago. The wiki has become much bigger and game has become much more open. Although I don't think we need every little thing, detail is useful and important. We have the guides and the named update pages (such as Nether Update) for overviews. Version pages should be detailed, especially snapshot pages. I oppose this change much more for snapshot pages, but I still very strongly oppose it for releases as well. If anything, we should go back and fix old version articles to be more consistent with what we have now. And yeah, there's no way we're gonna be able to stay on top of updating old snapshot articles. In terms of active editing, they're usually forgotten about after their week is up.
 * I think we should state somewhere that pages such as the Nether Update page should be more condensed and act as a general overview. The guides should act as a general reader-friendly, guide to the update that's simpler than the version page but more in-depth than the name page. The version page should contain all the detail needed to describe the change/feature. -PancakeIdentity (talk) 03:07, 4 April 2020 (UTC)


 * I appreciate both of your comments; you brought up an issue I honestly hadn't thought about. However, I still maintain my support for this idea. The purpose of history sections is to document what a feature was previously like, so I feel like doing the same on both the version page and its snapshot pages is redundant. However, I do agree that only listing qualities of a certain feature that have been changed in future versions, like Blobs said, would be difficult to do and therefore I would not support that. As I said above, I wouldn't be opposed to having full detail on snapshot pages, especially now that there has been a reason proven why it would be useful.


 * Even if we do decide that a lot of detail is necessary, we still need to control just how much it is. Current individual pages on features often contain paragraphs and paragraphs about their usages, especially mob ones. So how much of that should we include on the version page? By the logic of your arguments that the version pages need to show everything a feature does at that time, we would need to include all of it, because any of it could change. In fact, it's often the smaller details that change; those that we may not even think to include in a version article. So to be completely thorough we would have to put all the details in those paragraphs of prose into bullet points, but in many cases that's likely to be very impractical, especially when there are 100 other features introduced on that same page. For example, do we include mining times? Sounds? Achievements?


 * That's why I think it would be simplest and make the most sense to just put a few bullet points for each feature on the version page and put as much detail as needed on the pages themselves, leaving the previous properties of those items to the history page. Again, though, I would not be opposed to putting more detail for snapshot pages since they're so short anyways.


 * Apologies if I explained and organized this in a kind of weird way, but I couldn't think of a better way to do so.--Madminecrafter12 (Talk to me 18:10, 13 April 2020 (UTC)


 * Just another comment: regardless of how much detail we do decide to put, it might be a good idea to make a project for updating the version pages, as it could take quite a long time to get version pages to the length/detauk we determined here.--Madminecrafter12 (Talk to me 18:14, 13 April 2020 (UTC)
 * Already exists: MCW:VC. <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:48, 14 April 2020 (UTC)


 * I guess I agree we don't need every little detail, but I'd be opposed to removing too much. I think generally 1.14 has a good amount of detail for mobs. Appearance, health, drops, a few basics about behavior/function. Maybe they could be reduced a little, but I don't think it's too much. I'd also say 1.16 generally has a good amount of detail as well (though piglin bartering should be removed or moved to the bartering section (edit: I've gone ahead and made this change.)). -PancakeIdentity (talk) 22:18, 13 April 2020 (UTC)


 * . I really do not think we should have any less information than the 2019-20 snapshot pages do currently. It would be really annoying to have to scroll through history sections to find information in a snapshot. The information in recent snapshots may seem redundant, but see how useless pages like Java Edition Beta 1.4 are where they have only barebones info. And if you're scrolling through versions, youre not going to want to open a dozen tabs to see how all the features worked in that version. <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:58, 14 April 2020 (UTC)


 * I didn't realize that MCW:VC exists, thanks. So yeah, depending on the result of this discussion we could add controlling the amount of detail in version pages as a component of the project. As for everything else, I don't really have much to say other than what I've written already, other than a reminder that we could always have snapshots more detailed than the main version pages. We could also maybe say 4-6 bullet points or something for the version pages instead of the 1-3 I originally proposed (which we already have done for some features in recent versions, it's just mainly the 8+ bullet point ones that I think are excessive). I will say that looking at the Piglin section of the Java Edition 1.16 (since I pointed this out in particular in my original post), we could probably condense the 15 points into maybe a good 8 quite easily without losing too much information.--Madminecrafter12 (Talk to me 02:08, 14 April 2020 (UTC)
 * Yeah, I think the Piglin info could probably be condensed. What I don't what is an explicit "thou shalt not have more than 6 lines" because that would just encourage nuking half the page. A guideline of "try to condense the information as much as possible without losing meaning, on major release pages" may work, though. <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> 21:50, 14 April 2020 (UTC)
 * I'd support a statement like this and an effort to condense current and old pages. I'd oppose any sort of explicit line limit. -PancakeIdentity (talk) 22:36, 14 April 2020 (UTC)

New proposal
Although I personally still think that condensing each version feature into a 1-3 bullet point description or so would be the most effective for the reasons I described above, and  have strongly opposed this for valid reasons. So for an alternate proposal, how about we'd add the following to the versions style guide?


 * Each feature of a numbered update or snapshot version should be described using a bulleted list. For any additions, this list should be mostly comprehensive, including any major details about the feature, but should also be as condensed as possible for easier readability. Most additions should be covered in 8 or fewer bullet points and should rarely ever be more than 12. Any changes, as well as the rare case of additions that are not covered on their own page, should include all relevant details, even less important ones, although they should still be as brief as possible without losing any information. For abnormally large changes, such as the Flattening in Java Edition 1.13, it may be desired to split them into a separate page and summarize them briefly on the version page.


 * Named update pages, such as Update Aquatic, should only list individual additions, not describing their usage or behavior at all, and summarize any changes as briefly as possible.

Thoughts? Improvements?--Madminecrafter12 (Talk to me 14:54, 16 April 2020 (UTC)


 * . -PancakeIdentity (talk) 00:59, 20 April 2020 (UTC)
 * that wording. <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:08, 20 April 2020 (UTC)
 * FVbico (talk) 21:19, 21 April 2020 (UTC)
 * . Added to the versions style guide and will also add "making version pages consistent to the style guide" a task for the versions project.--Madminecrafter12 (Talk to me 16:57, 6 May 2020 (UTC)

Organization consistency
MCD has its own organization and MCE is currently in the mainspace. Other discussions either have covered or are covering these issues.

I noticed this article: Minecraft Wiki:Projects/Minecraft Dungeons Wiki/Nameless One.

It's an article about an entity, in a non-article namespace, two sub-pages deep.

What's with that? There are a whole slew of pages in Category:Minecraft Dungeons Wiki like this. I assume that once the game goes live, the articles will get moved to article space.

My question is, will they be sub-pages, or just get mixed into main space like the Minecraft Earth articles? ~ Amatulic (talk) 02:49, 5 April 2020 (UTC)


 * I think the plan is keep it in the subspace for now. We haven't even decided to cover MCE officially. See the above discussions on coverage if you wanna talk about this more. -PancakeIdentity (talk) 03:22, 5 April 2020 (UTC)
 * Well, it seems that User:Minecraft loot just unilaterally moved most of the Minecraft Earth articles to Minecraft_Wiki:Projects/Minecraft Earth Wiki.
 * I'm not sure I agree with this move. Unlike Minecraft Dungeons, Minecraft Earth is live, being played, and has a huge overlap with Minecraft. There are things in it such as the Furnace Golem that are exclusive to Earth at the moment but won't be in the future, so it makes no sense to split it out to another project. This really needs discussion. can you shed light on what happened? Was there a discussion that I missed? ~ Amatulic (talk) 01:11, 7 April 2020 (UTC)


 * (Pings don't seem to be working since the notification system updated last August, so I notified Minecraft loot on his talk page. – Sonicwave talk  03:45, 7 April 2020 (UTC))

I do not understand what the problem is, Minecraft Earth is a whole different game like Minecraft dungeons so it makes sense to give it a separate wiki instead of treating it like an edition of Minecraft. also, I do not see anything that says that the Furnace golem is coming to Minecraft or Dungeons. P.S. if you want I can combine the earth and dungeons wiki project and call it the "new game wiki project" or something but I don't like that idea. Minecraft loot (talk) 03:12, 7 April 2020 (UTC)


 * First, there is no consensus for the unilateral changes you just made. See the extremely long and lively debate titled above, with all of its subsections. Please read it and the points of view expressed; it's a long read.
 * There was some consensus to avoid putting Earth-specific content in regular articles and write separate articles in main space about Earth-specific content, and that's how things were going until the recent mass-moving.
 * There was also some discussion about giving these Minecraft relatives their own namespaces for easier navigation, like "Earth:" or "Dungeons".
 * I suggest you restore everything back to what it was. This new organization isn't an improvement at all. The page titles are now too unwieldy; I don't see anything in the discussion above that justifies it. ~ Amatulic (talk) 05:41, 7 April 2020 (UTC)

Proposal: Limit animations in infoboxes
Unless they're extremely short (like, 2 or 3 elements), they may not be a net benefit for user experience. They can't be controlled by the reader, so if you have 16 images and you need the previous one, you have to wait 15 seconds. That's not considering _really_ bad cases like villagers and elements (they have been split since).

I propose limiting JavaScript animations in infoboxes to at most 3 images. If there are more, the images should be extracted into the gallery section. The infobox then would have one image of the most "basic" variant (white for color, oak for wood, wood for tool material, etc). --AttemptToCallNil (report bug, view backtrace) 03:27, 5 April 2020 (UTC)


 * . I don't think this is constructive. What I'd rather have is something that was discussed earlier in a way to stop and control which images are shown. Hovering over the image should stop it from cycling and maybe the invsprites could be used as a way to jump to that image. Or we could have arrows that would allow users to scroll back and forth between the images. It's an issue that needs addressing, yes, but I don't like this solution at all. -PancakeIdentity (talk) 03:32, 5 April 2020 (UTC)
 * Arrows would probably be a better approach, but they require much more JavaScript and make it more important as opposed to the gallery solution that may work even if JS is for some reason not working. I would support arrows instead if people think the JS factor is insignificant. --AttemptToCallNil (report bug, view backtrace) 03:35, 5 April 2020 (UTC)
 * I'm not a web designer, but I'm not sure why it would be too big of a deal. The initial implementation would be a big hurdle but after that, it should be fine, right? Not to mention, if it automatically added the arrows if there were multiple images, we wouldn't have to go through and edit every infobox with multiple images in them. At the very least I'll say if the gallery thing does end up happening, I'd much rather it be a style guide thing than a built-into-the-template thing. -PancakeIdentity (talk) 03:42, 5 April 2020 (UTC)
 * The other concerns are: 1) someone may (and likely will) need to maintain it in the future, extra complexity = more difficult to maintain; 2) it's possible Fandom/Gamepedia staff restrict how JavaScript works. Currently we can apply any JS to all readers; it's likely we'll at least have our JavaScript edits reviewed for security in the future, and some features may become unavailable in addition to that. For example, Fandom does not currently support any mobile skin customization (including CSS and JS), apparently because it caused some kind of extremely negative technical consequences. It isn't impossible the new platform will retain this restriction. Though very little is actually decided yet, and staff constantly assure us the platform will be as good as possible, and way better than our worst predictions say. --AttemptToCallNil (report bug, view backtrace) 04:39, 5 April 2020 (UTC)


 * If there is a large number of images, then it is true that an animation could pose the problem you described. However, separating them would make the infobox less compact. I think we need to have a few animations by "category". On the villager page, we have the adult and baby animations. However, we could split the baby animation into Bedrock and Java, so you have 3 animations of 7 each. The BlobsPaper.png 16:40, 5 April 2020 (UTC)


 * limiting animations. Also, I oppose creating a gallery section for other types of the same block, like all the types of arrows or spawn eggs. --dr03ramos Piston.gif (talk) Admin wiki[pt] 16:51, 5 April 2020 (UTC)

Proposal: replace pseudo-headings based on definition lists
Pseudo-headings like ;Header are semantically correct and may produce invalid HTML, which is likely to interfere with assistive technology (like screen readers). Such pseudo-headings is commonly found on version history pages.

I propose to replace them with actual headers (hidden with depth-limited tables of contents if needed) or, if impossible for some reason, with &apos;&apos;&apos;-based bold text.

Linking to wp:Manual of Style/Accessibility as that provides some more information. --AttemptToCallNil (report bug, view backtrace) 17:16, 14 April 2020 (UTC)


 * Is there an easy way to make headings under a certain level not appear in the table of contents? One problem I can immediately think of if we replaced these pseudo-headings with real smaller headings is pages like Java Edition 1.9 would have an extremely cluttered TOC (although we could simply convert the headings in cases like that to bold I guess).--Madminecrafter12 (Talk to me 17:32, 14 April 2020 (UTC)
 * We have TOC limit. --AttemptToCallNil (report bug, view backtrace) 18:13, 14 April 2020 (UTC)


 * or . I see the benefits, and I guess I don't see any issues with the actual idea. I honestly always just thought that was the correct way to do it. I don't feel strongly about this at all though. -PancakeIdentity (talk) 22:34, 14 April 2020 (UTC)
 * on practicality. While Wikipedia needs to be 100% accessible by blind people I wouldn't think MCW needs to be; if you're blind you're not going to be playing video games like this and as such won't be reading the wiki. I don't think it's worth the effort for the 6 people who would read the wiki that need it. Unless I'm missing something in the reasoning. <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> 21:20, 21 April 2020 (UTC)
 * If this is really an issue I'd much prefer using JavaScript to replace definition lists with regular bold text over restricting the whole wiki and having to reteach everyone what to do. <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> 21:24, 21 April 2020 (UTC)

Reworking the LootChestItem template
This template is currently a pain to read whatever it outputs. See Armor and Iron Ingot for examples. There's lots of text with lots of numbers, organization is bad, spacing can be weird, etc. I propose that we rework this template to use tables, preferably somewhat modular, like breaking row is. Even if we don't use a table, I think we can agree the current state of this template is less than idea. What should we do to fix this? -PancakeIdentity (talk) 23:04, 15 April 2020 (UTC)


 * I'm pretty sure the French wiki already does something like this. This would also have tied in to the whole loot rework I've been trying to do, so I'm definitely in support of this (the exact same lines of text being repeated over and over is annoying as hell, and tables just look a hundred times better anyway with said information). I don't think we should account for luck though, since it isn't a survival feature as far as chest loot is concerned. - User-12316399 (talk) 23:13, 15 April 2020 (UTC)


 * It's not even a non-survival feature outside of fishing. -PancakeIdentity (talk) 23:17, 15 April 2020 (UTC)


 * User:Sealbudsman seems to have a work-in-progress on his userpage (which uses Template:LootChestItem2 and Module:LootChest2); perhaps we could expand off of that? – Sonicwave talk  03:48, 16 April 2020 (UTC)


 * Those look like they have potential. -PancakeIdentity (talk) 19:12, 16 April 2020 (UTC)


 * I changed the template to use the base3 (table) version of the module a day or two ago, which is much better, while Sealbudsman's template is still in development. <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:11, 20 April 2020 (UTC)
 * The template still has issues. Whenever a loot table is the same across editions, this template only lists them under Java edition. This makes it look like they can only be obtained from woodland mansions and (in 1.16.0) ruined portals. However, I know for a fact that they can also be obtained from desert temples. It is even more confusing because the chance of getting an enchanted apple from a mansion chest is the same across editions only other parts of the loot table are different. The BlobsPaper.png 17:27, 20 April 2020 (UTC)
 * The old text-based template had this exact same issue. It's something that needs to be fixed, yes; but it's not a reason to not use the table template. -PancakeIdentity (talk) 17:35, 20 April 2020 (UTC)
 * Personally I wouldn't mind having duplicate information if it's the same in both editions, you'd have a section with every chest loot info for java and a section with every chest loot info for bedrock.--Capopanzone (talk | contribs) 19:39, 21 April 2020 (UTC)
 * Most readers will just look at the list for their preferred edition, so listing the same chance on both would be simpler. The BlobsPaper.png 20:28, 21 April 2020 (UTC)
 * My only worry with this is the possibility of big tables with lots of repeat info, especially if Bedrock loot tables are made to generally match Java's. What I think would be a good solution would be a general section without a version bar for info that's the same in both. And then, both a Java and Bedrock section that displays entries that are different from each other. -PancakeIdentity (talk) 22:28, 21 April 2020 (UTC)


 * I made some adjustments to Module:LootChest. Now, the loot table is given to both editions, even when identical. When using LootChestItem, the table explicitly lists loot for both editions. I would like to have a way to more simply state that the loot table is the same across editions, but the module uses several functions that I am not familiar with.
 * I am not sure if there is an easy way to implement this, but we could document when the loot tables only have minor differences. For example, ruined portals can have glistering melons in stacks of 4-12 in Java Edition, while they come in stacks on 1 in Bedrock Edition. Even worse, the chest loot is almost identical for woodland mansions, but the weights are scaled up by a factor of 5 in Bedrock Edition. The BlobsPaper.png 18:35, 9 May 2020 (UTC)

List of all additions on Java Edition pages (1.12 - 1.16)
On Java Edition version pages, , , and , probably same user (85.247.222.38 & Groovy goose) added on these pages inventory with all "blocks, items and spawn eggs" added in that version. I'm really disappointed about these edits, as those inventory tables look really confusing and we already have guides for Java versions and for Bedrock, we will have soon. So I suggest to remove them from these pages. --Treeislife2 (talk) 09:12, 16 April 2020 (UTC)
 * for these additions. We already have guides + it is only for inventory items with the inventory textures. --Treeislife2 (talk) 09:12, 16 April 2020 (UTC)
 * But, if it will be on guides pages. --Treeislife2 (talk) 09:42, 22 April 2020 (UTC)
 * . I don't really see any problem with them. — Thomanski | t | c | 18:09, 16 April 2020 (UTC)


 * /. I don't see a need for them, but I always am not totally opposed to including them. -PancakeIdentity (talk) 19:11, 16 April 2020 (UTC)


 * for major updates only. I honestly think it provides a nice overview of all the items added in the update (not all readers know that you can easily find a direct list of the features added on the corresponding named update page) and isn't too much clutter imo. The only reservation I have is looking at the former Java Edition 1.9 on my phone with desktop view, the left side of the inventory of items is completely cut off, and since it's not in the form of an image you can't just click on it and see it in a bigger view. If we could add a parameter to Template:Inventory to make fewer cells per row that might fix it, but then again all different devices are different and this is likely an issue we can't fix for everybody.--Madminecrafter12 (Talk to me 19:32, 16 April 2020 (UTC)


 * You say inventory grid gets cut off, you can't see all 9. How many can you see? – Sealbudsman talk | contribs 20:11, 16 April 2020 (UTC)


 * I see 7 clearly while the furthest to the left is completely cut off and the remaining slot directly to the right can only be partially seen. Scrolling and zooming do not help. Again, though, this likely varies different between mobile devices.--Madminecrafter12 (Talk to me 20:35, 16 April 2020 (UTC)


 * Yeah, that's a problem. – Sealbudsman talk | contribs 21:43, 16 April 2020 (UTC)


 * having it, but not heavily so, even though I did like it. I'd be interested in why they were confusing. As for the observation that we already having guides .. well, these lists aren't guides, they're quite unlike a guide except having similar subject matter. And having the same information in two different forms in two places on the wiki, it's somewhat common I think. – Sealbudsman talk | contribs 20:11, 16 April 2020 (UTC)


 * Looks quite good, and provides a neat little overview over everything that's been added. It can also be used as a shortcut to the respective article if you're interested in reading more about a certain item or block. | violine1101(Talk) 16:35, 19 April 2020 (UTC)


 * on major releases, as it's a useful overview. It definitely shouldn't be on pages that have only one or a few new additions (like in Indev) that are obvious by a quick glance at the additions section. <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:12, 20 April 2020 (UTC)


 * for using a inventory image or Template:Inventory to list blocks. The item form of a block is not equal to the block itself. Many blocks don't have a item form, and also many blocks do not exactly correspond to the form of the item. Such as bubble columns in 1.13, in, there is a bubble columns in inventory. This is totally wrong, bubble columns have no item form in java edition, and the sprite of it in Template:Inventory is only for bedrock edition. Another thing, using new textures on pages of old game versions is also very inappropriate.
 * But I for adding a neat little overview. However, use game screenshots or block renders to list blocks.--Chixvv (talk) 08:28, 20 April 2020 (UTC)


 * for these additions. (Sorry for the bad english) We already use a picture alongside the link, and a brief description of the block/item/mob, and I personally tink that this is more intuitive:

Thanks, RosilloGames (talk) 19:06, 21 April 2020 (UTC)
 * Furnace Revision 1.png Furnaces
 * Used to smelt blocks and items.
 * Replaces the old smelting system.


 * That format may be used on other language wikis, but that's not done on the English wiki. IMO, of the two systems, the fake inventory works better as everything is in one place at the top of the page. -PancakeIdentity (talk) 22:26, 21 April 2020 (UTC)
 * as it can improve the readability in some ways. -- LakeJasonFace.png Lakejason0  (Talk • Contribs) 06:44, 22 April 2020 (UTC)
 * But it will broke entire page on mobile. --Treeislife2 (talk) 09:55, 22 April 2020 (UTC)
 * + It looks like old creative inventory from Minecraft Beta 1.8.1. If small inventory OK, but if this type of inventory, then no. And entire broking page also happen. --Treeislife2 (talk) 09:58, 22 April 2020 (UTC)
 * Works fine with mobile on Chinese Minecraft Wiki pages. But maybe not all the mobile devices, so maybe we can just hide this thing for mobile devices if necessary. -- LakeJasonFace.png Lakejason0  (Talk • Contribs) 05:36, 23 April 2020 (UTC)

Displaying mob spawning info on biome pages
I'm working on a template (at User:Sonicwave32/Biome spawn table and Module:Sonicwave32 test) to display mob spawning information for each biome, as currently the wiki doesn't mention the spawn weights given in the code. The intent is for this to be added to all of the biome pages. However, there's some issues that I wanted to get some feedback on:


 * The mob category headings (e.g. "Hostile mobs", "Passive mobs") might need changing, as they reflect which spawn category a mob was placed into, not the classification of the mob itself. For example, ocelots are in the "monster" category in the jungle's code, despite being a passive mob. Edit: Changed them to "Hostile category", "Passive category" etc.
 * I have no idea how Bedrock mob spawning works, it would probably require a separate table (assuming that you can even extract this information from the code like with Java).
 * Edit: Looking at Spawn, it appears to be similar to Java (in terms of weights and group sizes), though the specific values given on that page are different.
 * Since notes can be long, it might be better to display them as footnotes instead of a separate column, though I'm not sure how to support that in the template (especially for multiple rows referencing the same footnote). Edit: This change has been made.
 * How should snapshot mobs be listed? Since adding mobs changes the chances for other mobs, it may be better to display separate tables for snapshots; but that might add too much clutter (especially if we're already displaying separate tables for Java and Bedrock).

Other feedback on the template (e.g. syntax and appearance) or whether or not we should display this information at all is also welcome. – Sonicwave talk  05:22, 22 April 2020 (UTC)


 * (By the way, the reason this uses a module and everything is enclosed in a single template call is so that you can input the weights and have it calculate the spawn chances automatically.) – Sonicwave talk  06:07, 22 April 2020 (UTC)


 * . A "Chance" section would be useful (for those who don't understand "weight", aka most people). For footnotes, you can reuse them using FN. This info should also be put on the specific mob pages. <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> 05:45, 22 April 2020 (UTC)


 * Just realized that the "weight" column is supposed to be "chance" (as it shows the weight as a fraction of the total); fixed. The template automatically puts everything before the first  into, so I don't think I could easily add normal footnotes there without changing it to have people add  manually; though I just had an idea to have a separate "field" for them. – Sonicwave  talk  06:07, 22 April 2020 (UTC)


 * . Hover text could probably work to describe the mob categories well. It'd keep notes out of the header cells at least, which I think would look nicer. I do think removing the notes column and using foot notes would be better, especially for any possible cases where the note is longer.
 * As for snapshot mobs, I think we're treading upon the larger issue of some of our templates/modules not having support for multiple values (such as breaking row). I wonder if something just like "$10/46$<\br>$10/51$" could work. I don't really know though. -PancakeIdentity (talk) 06:59, 22 April 2020 (UTC)


 * I feel like that might get messy if multiple rows have upcoming information, which will probably be the case if a new mob gets added to a biome with more than a few mobs. The ideal solution IMO would be to have a "tabbed" design where you can click on something to switch between upcoming and release information, though I'm not sure how doable this is. If we have separate upcoming tables, we could make them collapsed by default to reduce clutter. – Sonicwave talk  06:37, 23 April 2020 (UTC)
 * Hover text should never have important content unless it also has a mobileonly footnote. <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> 03:04, 26 April 2020 (UTC)


 * . But it will be better if it will be "Spawn Chance", not only "Chance" (if possible and if isn't breaking page). --Treeislife2 (talk) 09:51, 22 April 2020 (UTC)


 * This will give readers a better sense of where to find what mobs. The BlobsPaper.png 16:00, 22 April 2020 (UTC)


 * We could also maybe develop a similar table for the mob pages. It could be used to compare the spawning of a mob in different biomes (like Blobs2 said above). -PancakeIdentity (talk) 17:10, 22 April 2020 (UTC)


 * I updated the link to a draft of the template documentation (which shows an example output at the bottom). I agree with having another template for mob pages; wondering if it would be possible/worth it to have it automatically generate the information based on information given on biome pages, similar to how crafting usage works. – Sonicwave talk  18:51, 23 April 2020 (UTC)
 * That would be nice and almost certainly possible, considering that crafting usage does work. -PancakeIdentity (talk) 21:32, 23 April 2020 (UTC)

Add page Mods/Sphax Pure BDCraft
The result of the discussion was do not create. It's a resource pack, not a mod, and we don't cover either on the wiki.

I actually don't know if it's counted as a mod or what, but it has to be mentioned somewhere. –Preceding unsigned comment was added by 106.201.186.23 (talk) at 20:07, 25 April 2020‎ (UTC). Please sign your posts with
 * Mod pages are being exported off this wiki, so no, we won't create that page. Go to the ftb wiki for mods. FVbico (talk) 08:15, 25 April 2020 (UTC)

Minecraft wiki logo.
In case you haven't noticed, on any Minecraft dungeons page the wiki logo changes to suit Minecraft dungeons. there should be a Minecraft earth variant for Minecraft Earth pages as Minecraft earth is a different game like dungeons.--Minecraft loot (talk) 02:28, 26 April 2020 (UTC)


 * Well, the discussion to separate Minecraft Dungeons into its own namespace also decided to keep Minecraft Earth in the main namespace (see the top discussion). Most Minecraft Earth features would be merged into their main counterparts, or if different enough they would be their own pages, but I don't think it would be enough of a difference to have a whole different logo, as it would just create confusion as to when it should be used imo.--Madminecrafter12 (Talk to me 14:07, 26 April 2020 (UTC)


 * I'd this if we do end up moving it to its own namespace. -PancakeIdentity (talk) 04:42, 8 May 2020 (UTC)

Changing gallery functionality
This has bugged me for a while... The galleries being formatted such that clicking on an image opens a whole new page, so I have to go forward and back all the time, is very inconvenient. Is there a way they can be converted to a popup "slideshow" with image page links at the top? I'm not sure if I'm describing it right but basically I think the way my MSPA Wiki does galleries is very user-friendly and intuitive. I think having the same format here would be helpful. I posted this message on a mod's talk page and they directed me here. They also implied it might be tricky to do? Which I didn't know, I thought my wiki's gallery format was the default. I also don't have access to our css myself... But in any case, what do we think of this idea? Aepokk (talk) 17:22, 25 April 2020 (UTC)
 * On desktop, you can hold ( on Mac) when clicking the image, to open in a new tab. On mobile, the image already uses its own interface, and you can tap the X in the top-right corner. The BlobsPaper.png 00:31, 27 April 2020 (UTC)


 * Given that Fandom and Gamepedia are (currently) different platforms, it's likely that wiki's system is their default and our wiki's is ours. While I don't have any issues with changing this, you have to find someone who both can and is willing to make that change, which may be unlikely if it's complicated. -PancakeIdentity (talk) 00:42, 27 April 2020 (UTC)


 * https://help.gamepedia.com/Advanced_images#Optional_gallery_attributes so either for a slideshow, but one has to click on the middle icon to show previews. Or maybe using https://www.mediawiki.org/wiki/Help:Extension:Media_Viewer, for example this causes those 6 images just above the gallery link to semi-overlay on the help wiki, i bet there's bunch of other settings in that extension. quickedit: https://help.gamepedia.com/Extension:SlideBoxLightShow is already installed on this wiki Niutp (talk) 12:49, 27 April 2020 (UTC)


 * I believe you that it's already installed, but I'm not sure how to turn it on if that is the case. Also, re: previous comments, given the recent notices about gamepedia and fandom merging, this may just automatically resolve soon anyway? Also if I'm reading this right the format I'm used to is mode="packed-overlay" . Aepokk (talk) 20:32, 27 April 2020 (UTC)

Minecraft earth mainspace (again)
recently, we decided to have Minecraft Dungeons to have its own mainspace, and Earth to be part of the main. however, someone told me that it was somewhat shaky, and that I could start a new topic on it. So here is my argument on why Minecraft earth should have its own mainspace:


 * Minecraft Earth, like Minecraft Dungeons, has unique mobs.
 * Also like Dungeons, it has mobs from the main game.
 * Earth is a different game and moving it to its own mainspace will help clarify that it is not an edition.
 * Earth doesn't receive the same updates as the base game.

--Minecraft loot (talk) 03:53, 8 May 2020 (UTC)
 * I should note I do not actually oppose a new namespace for Earth. --AttemptToCallNil (report bug, view backtrace) 03:56, 8 May 2020 (UTC)
 * , it would be more consistent with Dungeons. I do feel that making a namespace will lead to non-exclusives being documented in an Earth namespace just as an obvious by product of having the namespace, which I wouldn't oppose but is in disagreement with what was decided in the earlier text walls. <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> 03:58, 8 May 2020 (UTC)
 * . More consistent with Dungeons; Earth is still a different game and we have decided to keep Earth content off other Mainspace articles. Works best for consistency imo. Also prevents stuff like the mud bucket showing up on the Dirt page. -PancakeIdentity (talk)
 * But, please, make final decision, because I'm tired from this discussing. It took so long and we are not done! --Treeislife2 (talk) 20:01, 8 May 2020 (UTC)

Fake webiste found
Hi. I'm bringing to your attention this fake website http://www.finbit.org/Minecraft_Wiki/eAHLKCkpKLbS18_NzEtNLkpMK9FLT8xNLUhNyUzUS87P1feFiceHZ2ZnAgCXuxF4 which is a copy of this wiki. --Treeislife2 (talk) 20:06, 8 May 2020 (UTC)
 * I reported the site to staff and got a notice that the legal team will be notified. --AttemptToCallNil (report bug, view backtrace) 05:01, 9 May 2020 (UTC)

Handling of Legacy Sprites
So, a recent discussion on discord has had regarding handling legacy sprites on the wiki. As the discord is not a replacement for on-wiki discussion, I thought I'd bring it here. Should we hold legacy block sprites on the wiki (not image files), and if so, how? Should they be in BlockSprite (and similar), or should there be dedicated templates for these legacy sprites? These sprites would mostly be used in history sections and old crafting recipes where needed.

Personally, I'm mostly neutral on all this. I'd weakly support having them on the wiki somewhere, but I don't feel strongly about it and I don't really care how it's done if we decide to do it. -PancakeIdentity (talk) 01:13, 9 May 2020 (UTC)

Currently, the BlockSprite, ItemSprite and EntitySprite templates all contain a large amount of different textures. A lot of these are left over from updating the template to comply with the Texture Update, and are rarely used, despite them taking up almost half of the space on the sprite sheets in question. This also makes editing them difficult, even in edit sprite form, since they take up huge chunks of space. I'm considering creating dedicated sprite sheets and templates to move these textures to, so that they don't have to take up as much space on the current templates in question and so that the normal ones only hold textures that apply to current Java, Bedrock and Education Edition features. All textures of removed features or outdated textures would be moved t the legacy templates instead.

By default, specifying the name of a block without stating what revision it is would default to the version of that texture as it were on Java Edition prior to the Texture Update, but further details could be specified if a different version of the texture is desired.

I will take 100% responsibility in splitting these sprite templates into the current and legacy versions as well as converting existing pages that use legacy sprites to use the correct templates.

Would anyone explicitly oppose such a change, or would I be free to go ahead with it? - User-12316399 (talk) 01:30, 9 May 2020 (UTC)


 * The spritesheets are too large so I splitting off the legacy sprites. <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:17, 9 May 2020 (UTC)
 * for splitting off the legacy sprites. --Treeislife2 (talk) 19:42, 9 May 2020 (UTC)
 * I see no reason to keep the sprites in any form (split or not); we already have revision renders, and aside from invsprite in version pages and history sections, I see no use for them. FVbico (talk) 19:51, 9 May 2020 (UTC)
 * So we're ignoring pages like Java Edition 1.13/Flattening then, which use modern sprites despite the fact that they have no business using block sprites from a year ahead of what they document? - User-12316399 (talk) 20:22, 9 May 2020 (UTC)
 * I'm not ignoring them, those can be changed to the renders instead of the sprites. FVbico (talk) 20:24, 9 May 2020 (UTC)
 * I mean there are examples of things like historical crafting recipes and such, I'm not sure if they can use renders. If they can, then yeah, I don't see much a need either. If they can't, is it worth all the effort to fix it? -PancakeIdentity (talk) 21:33, 9 May 2020 (UTC)
 * While they could be replaced with renders on pages like the mentioned flattening page, the 16x16 block sprites are almost exactly the same size as the text itself, and replacing these with renders would either require scaling them down to being indecipherably small or having them be bigger in a way that unneccesarikyntretches the template out. Since blocksprite has them at just the right size to be able to convey the neccessary information, I'm still sticking with keeping the legacy sprites in a dedicated template. - User-12316399 (talk) 21:40, 9 May 2020 (UTC)

If there aren't any objections within the next 12 hours I'll go ahead and split the three relevant sprite templates; if the consensus later turns to just outright removing legacy sprites, the legacy templates can just be deleted anyway to achieve the same effect. - User-12316399 (talk) 21:42, 12 May 2020 (UTC)


 * As there hasn't been any opposition in the given time frame I'm proceeding with the split of templates. Again, since both parties agree with having legacy sprites removed from the main template this shouldn't be controversial, and the dedicated legacy templates can just be deleted if that side wins. - User-12316399 (talk) 12:35, 13 May 2020 (UTC)