Minecraft Wiki talk:Community portal/Archive 29

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 [ Book and Quill.png 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 [ Book and Quill.png 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  T  C  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> 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)?  Nixinova</b> </b> T</b> </b> 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)

Proposal: Limit animations in infoboxes
The result of the discussion was strong opposition from all sides (except the original proposer)

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)

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)

Displaying mob spawning info on biome pages
The result of the discussion was to implement the template. No further comments for a month and this seems to be well supported, and most of the issues I brought up originally have been resolved. Further discussion can go on the template's talk page. – Sonicwave talk  07:21, 23 May 2020 (UTC)

I'm working on a template (at Template:Spawn table and Module:Spawn table) 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)

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 don't 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 you're saying but instead of that you can create section in the chunk page. Its a stub after all now and it needs a lot 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)

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)

Fake webiste found
The result of the discussion was staff notified. Gamepedia staff were notified and any further action is out of our control and not worth discussing.

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)

Minecraft earth mainspace (again)
The result of the discussion was Make Minecraft Earth a new namespace, as proposed. Any Minecraft Earth-exclusive features should be documented in a new namespace, for better organization, ease for readers to look up features exclusive to one edition, and consistency with Minecraft Dungeons. Although the discussion before resulted in Minecraft Earth being documented in the main namespace, this was simply because this was stated in the original proposal and no one had opposed it. In this discussion, the original proposer of the previous discussion actually noted that they would not oppose a new namespace of Minecraft Earth. Although namespace details have not been discussed, it would very likely be Minecraft Earth with MCE and Earth as aliases.

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)
 * I feel like documenting Earth in the main name space is just confusing for players who just want to look for information about the "vanilla" game, and makes it harder to find information for players who would like to know more about Earth. | violine1101(Talk) 10:10, 16 May 2020 (UTC)

Minecraft wiki logo.
The result of the discussion was update the logo. The Earth namespace now uses a different 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)

well earth got its own main space like dungeons so can an admin give Minecraft Earth its own logo.--Minecraft loot (talk) 01:54, 17 May 2020 (UTC)

Removal of the Java Edition part on snapshots and Bedrock part for beta.
The result of the discussion was no change. There was an enormous discussion about this and the turnout was for consistancy, doing it because it's unique is very feeble and weak statement.---HumiebeeDiscuss anything with me Look at my edits 21:00, 8 September 2020 (UTC)

In the snapshots and betas, the title includes the edition's name (e.g. java edition 20w28a and bedrock edition beta 1.16.20.50). This isn't needed as there are only snapshots in Java and betas in Bedrock. Also, most of the links to the page are just the snapshot and beta part (20w28a and beta 1.16.20.50). The wiki should remove the Java and Bedrock part and just have the name of the snapshot or beta-like the development versions on the left side and the history section on pages. --Minecraft loot (talk) 01:15, 13 July 2020 (UTC)
 * We had a massive discussion about this last year. It would be incredibly confusing to have to guess what version you're clicking on, and that's hardly future proof, so it's better to just be explicit whenever possible. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  01:26, 13 July 2020 (UTC)


 * I think it just looks a lot neater when it's like that...It helps people who are new to the Wiki and Minecraft understand if it's Java Edition or Bedrock Edition. Also, it just looks formal. 182.65.74.243 14:00, 17 July 2020 (UTC)


 * per previous discussions and Nixinova's comment. -PancakeIdentity (talk) 04:12, 21 July 2020 (UTC)

Translation Wiki
The result of the discussion was strong oppose, unnecessary.

Hi folks,

I recently had the idea that we make all currently wiki translation projects into a separate translation wiki at minecraft-translate.gamepedia.com with different namespaces (eg "sv:" for the Swedish wiki translation project, so one for each language. The articles should then be located there, for example "en: Boat", and when the wiki translation projects are finished, we can create a new wiki for this language. The namespaces should be: „Sk:“ for the Slovak Wiki translation-project, „sv:“ for the Swedish wiki translation-project, „vi:“ for the Vietnamese Wiki translation-project. For ex. the Slovak wiki article about the bowl should be in the translation wiki there: „sv:Miska“ or the Swedish wiki article about the sheep should be here in the translation wiki: „sv:får“ or the Vietnamese wiki article about the egg should be there in the new translation-wiki: „vi:Trứng gà“. Please don’t forget to install the translate extension for the new Minecraft-translation-Wiki. Answer would be really nice.

Atten007 (talk) 07:54, 14 July 2020 (UTC)


 * no no no No No No NO NO NO, theres no point and we already have the translations in the wiki. NO Its simply a waste of time, you never even said why so its USELESS

The BumblebeeBee.png 21:53, 16 July 2020 (UTC)


 * We already have the projects page, why would we make a new wiki for translations? You didn't say. Sagessylu (discuss | edits) 09:36, 19 July 2020 (UTC)


 * . Don't see a reason for this. The current project system works well and I don't see any need for a need for a separate wiki. -PancakeIdentity (talk) 04:14, 21 July 2020 (UTC)


 * . We still have many incomplete translations and creating an entire new website would only cause inconsistencies. Also, it would be harder for users of a foreign language to get from the English Wiki to the Wiki of their own language. It would be better to work on the pages themselves than to create copies of these pages and paste them back.Fadyblok240 (talk) 01:46, 2 August 2020 (UTC)

file 'Revisions'
The result of the discussion was the files are already being moved. It may take a while, but all revision files will be moved to this system.

I propose to change ALL revision files, aka ones that say like idk, ex:cake revision 1.png like why. why not cake je1 be1.png it's so inconsistant like some are revision # but others are JE# BE#. Please, move all the block and item files to be consistantl Humiebeetalk contributions 21:12, 3 August 2020 (UTC)
 * They're all in the process of being moved to JEx BEy, it's just a tedious process. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  21:15, 3 August 2020 (UTC)

Bedrock edition flattening & history
should we put things that are going to be added in the be flattening in history tables?? like for example, effects dolphins grace, luck, bad luck, and glowing, in the history tables, should we put upcoming bedrock edition on the header and be flattening on the side? Request by Humiebeetalk contributions 17:26, 4 August 2020 (UTC)
 * Probably not, since there are no betas for the flattening. The BlobsPaper.png 18:53, 4 August 2020 (UTC)


 * Given we don't yet know for sure what will and won't be flattened, this doesn't make much sense. No betas have included that flattening and anything else would have to have a direct source saying something like "we will change X to Y". Note that the BE flattening page, while viewed by Mojang, is still community-maintained. -PancakeIdentity (talk) 05:40, 5 August 2020 (UTC)

bedrock edition version numbers.
The result of the discussion was redirects were created where possible. 4 "digit section" redirects are impossible with the current system.

should we create redirects for all the version numbers? Ex:PS4 1.16.2 was 2.02, no redirect. 1.16.0.2 has no redirect either. (android 1.16.0 versiom number). and 1.16.2.0, win 10 1.16.0 version number. There are sooooo many more but like we already have redirects for PS4 2.01, 2.02, and 2.07, so is it worth the effort?? like new people might see the version number but be confused when theres just a red link. Humiebee 01:10, 31 July 2020 (UTC)
 * For PS4 versions, I think it would be fine, but 4 digit versions cannot be searched on the wiki, so those can't be made redirects. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  01:15, 31 July 2020 (UTC)
 * created all the redirects ---HumiebeeDiscuss anything with me Look at my edits 16:14, 14 August 2020 (UTC)
 * Ditto Nixinova. Additionally, these pages should note at the top that they are the same version. -PancakeIdentity (talk) 05:41, 5 August 2020 (UTC)

Trading information on pages
The result of the discussion was implement proposed idea.

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)


 * – if we do implement something like this, a table format would probably be better than the current sentences describing trades. I'm not too big of a fan of throwing all of the information into a big Lua module though (like with Module:LootChest). The Cargo extension sounds more appealing, though enabling that would likely have to wait until after the migration to UCP. – Sonicwave talk  00:52, 18 August 2020 (UTC)

What is the point for interwiki
The result of the discussion was the question was answered.

like why put interwiki when it's not even visible?---HumiebeeDiscuss anything with me Look at my edits 19:21, 17 August 2020 (UTC)
 * I'm pretty sure that when you look for a page in another language, it lists the corresponding pages based on interwikis. The BlobsPaper.png 19:24, 17 August 2020 (UTC)
 * It is visible; on desktop, in the sidebar, in desktop view on phones, at the far bottom of the page (above the copyright) and mobile view adds a button at the top op the page, which opens a menu with the languages. FVbico (talk) 20:27, 17 August 2020 (UTC)

I don't see it---HumiebeeDiscuss anything with me Look at my edits 20:31, 17 August 2020 (UTC)
 * wait nvm the side bar, oh i see. So all the interwiki links are placed in the sidebar---HumiebeeDiscuss anything with me Look at my edits 20:36, 17 August 2020 (UTC)
 * You can also make a normal link to a different language section, by placing  before the language prefix, as in  . — <b style="line-height:19px;letter-spacing:1px"> Babylon  A S </b> *Happy Camper* 12:16, 18 August 2020 (UTC)

Custom skins for the Dungeons and Earth wikis
The result of the discussion was change the skins to the skins the German wiki uses.

It's been brought up a few times on the discord, so I thought I'd bring the discussion here. Should the MCD and MCE wikis (or, rather, namespaces) have custom skins that better match their logos? We recently added different logos for both these namespaces, but the colors of the rest of the webpage don't match. The German wiki already has a skin for their MCD wiki (https://minecraft-de.gamepedia.com/Minecraft_Dungeons) and they plan to add one for their MCE wiki as well. Should we implement this on the English wiki as well?

I personally fully this. -PancakeIdentity (talk) 08:37, 19 May 2020 (UTC)
 * They have it already --Treeislife2 (talk) 19:41, 19 May 2020 (UTC)
 * They do not. They have unique logos, but not skins. -PancakeIdentity (talk) 01:48, 20 May 2020 (UTC)
 * MCD has --Treeislife2 (talk) 13:27, 21 May 2020 (UTC)
 * . We already made the skin on the Portuguese wiki. I think the skin is cool because it creates a Dungeons look, but it doesn't take away the iconic characterization of MCW. --dr03ramos Piston.gif (talk) Admin wiki[pt] 10:49, 20 May 2020 (UTC)
 * --Minecraft loot (talk) 05:07, 23 May 2020 (UTC)


 * - would make it clearer that you're reading a page about Dungeons/Earth and not the base game, especially if you follow a link to a section in the middle of the page, where you wouldn't see the wiki logo or the page title. – Sonicwave talk  23:35, 25 May 2020 (UTC)

this now exists so shouldn't this be closed--Minecraft loot (talk) 22:43, 28 May 2020 (UTC)


 * I will close it, but there's typically no need to ask for closure in the topic. Closure isn't urgent. Just wait and it'll happen. -PancakeIdentity (talk) 23:34, 28 May 2020 (UTC)

Minecraft Earth and Minecraft Dungeons without "wiki"
The result of the discussion was unneeded. These project pages are mostly obsolete as they have their own namespaces now.

Hi.

I think that we could move Minecraft Earth Wiki project to only Minecraft Earth, and the same could be done for Dungeons. --Treeislife2 (talk) 09:56, 19 May 2020 (UTC)

I this thing. --TreeIsLife2 (talk) 09:56, 19 May 2020 (UTC)
 * They already have gotten their own namespace... FVbico (talk) 09:59, 19 May 2020 (UTC)
 * I said Projects 😃 (Minecraft Wiki:Projects/Minecraft Dungeons Wiki, Minecraft Wiki:Projects/Minecraft Earth Wiki moving to Minecraft Wiki:Projects/Minecraft Dungeons, Minecraft Wiki:Projects/Minecraft Earth) --Treeislife2 (talk) 19:10, 19 May 2020 (UTC)
 * All pages will move the the corresponding namespace; the project pages will be moved out, except the main page, which can probably just be archived instead. FVbico (talk) 19:39, 19 May 2020 (UTC)
 * Got it. --Minecraft loot (talk) 05:13, 20 May 2020 (UTC)
 * Done. --Minecraft loot (talk) 05:23, 20 May 2020 (UTC)
 * The projects aren't finished yet though and archiving a project is not done by clearing the page. The projects shouldn't be archived until they are actually finished. At least the Minecraft Dungeons project is still missing a bunch of pages and both projects need better template support (because namespace) and be reflected on the actual Main Page / get their own main pages.  HorseHead.png Gamepedia icon.png MarkusRost (talk) 11:36, 20 May 2020 (UTC)

Check all planks and slabs in recipes!
The result of the discussion was everything fixed.

To actually make the whole "Matching/Any Planks" things make sense for the new 1.16 Nether Planks, I have changed Module:Inventory slot/Aliases to reflect the new crafting categories. The new behavior is:
 * Matching Planks: Returns both Overworld and Nether variants, the ones you can make wooden tools out of.
 * Matching Overworld Planks: Returns only Overworld Planks, the ones you can make boats out of.
 * Matching Nether Planks: Returns only Nether Planks, the ones you can't burn.

The good thing about it is that you no longer to write "Matching Planks; Crimson Planks; Warped Planks" and such to get it to work. The downside is that some recipes are actually trying to say "Matching Overworld Planks" when it says "Matching Planks", and I need y'all to check for them in 1.16. One example is the Boat, but I am more worried about things without subtypes like the Barrel as that is non-obvious.

Start with Planks and Slab.--Arthur200000 (talk) 06:12, 23 May 2020 (UTC)


 * Anything that doesn't have variants for different types of wooden (barrels, crafting tables, etc) automatically accepts all 8 wood types as they use tags. I think boats and "fuel" are the only things that use overworld planks only. I don't think anything uses nether planks only. -PancakeIdentity (talk) 17:35, 23 May 2020 (UTC)

Minecraft dungeons is out, but on the latest news it is not there!!! I cannot edit it so I'm hoping someone who reads this can.
The result of the discussion was page updated.

Rprentice217 (talk) 21:09, 26 May 2020 (UTC)

it is also not on the 'play it' section like the editions and minecraft earth –Preceding unsigned comment was added by Minecraft loot (talk • contribs) at 00:13, 27 May 2020 (UTC). Please sign your posts with


 * I've added it to the recent news section. The play it section is still WIP on the editcopy so I haven't added that. In the future put this in Talk:Minecraft Wiki, not here. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b> 00:20, 27 May 2020 (UTC)

The Villager Trading page eliminated the 'Globe Charge' for the Java edition Cartographer - it looks like a mistake
The result of the discussion was issue was fixed. The issue was caused by a large in-page merge, which was later reverted.

I'm not 100% sure how to edit a page correctly, so I wanted to point out a recent mistake.

The Globe Banner Pattern has been mistakenly eliminated from the Trading screen.

Refer here:

https://minecraft.gamepedia.com/Trading > Trading with a villager is also the only legitimate method of acquiring the globe banner pattern‌[JE only] ... in Survival mode.

This is backed up elsewhere:

https://minecraft.gamepedia.com/Banner_Pattern > In Java Edition, Master-level Cartographer villagers sell a globe banner pattern for 8 emeralds. The globe banner is not currently available in Bedrock Edition.

https://minecraft.gamepedia.com/Official_pages/Parity_issue_list > Master cartographer villagers sell a globe banner pattern (currently not in Bedrock) for 8 emeralds in Java, while they sell either a flower charge, field mason, or bordure indented banner pattern (all currently not in Java) for 1, 2, or 2 emeralds respectively in Bedrock.

--

However, on https://minecraft.gamepedia.com/Trading#Cartographer, a recent change eliminated the Globe Banner Pattern from the Java edition Cartographer entirely, by making it 100% the same as Bedrock's Cartographer trading tables, and now there is no place where you can actually trade to get it.

This is a mistake - nothing I've seen from Java Edition 1.16 updates indicating this is changing, and I can currently buy the Globe Banner from my own villagers in 1.15.

HTH. –Preceding unsigned comment was added by 84.17.36.141 (talk) at 14:52 1 June 2020 (UTC). Please sign your posts with


 * The mistake happened when we merged the Java trading tables with the upcoming Bedrock trading tables. The BlobsPaper.png 16:31, 1 June 2020 (UTC)


 * I've undone this merge all together. Not sure why it happened, it was extremely misleading. -PancakeIdentity (talk) 18:21, 1 June 2020 (UTC)

Bug report
Is this the correct place for bug reports? <span style="font-weight: 900;display: inline-block; width: 50px; border: 2px solid #a9a9a9; padding-left: 5px; padding-right: 5px;">MMK21 ⓉⒸ 12:40, 2 June 2020 (UTC)
 * 1) I'm assuming there was a recent software change. The vector skin is now completely broken.
 * 2) The search suggestions render above the 'User' popup-hover-menu in the top-right.
 * 3) The CodeEditor's syntax highlighting seemingly cannot be enabled for Wikitext.
 * 4) The 'Select files' button in the editing toolbar is inconsistent with the other buttons: wrong colour, and wrong hover effect.
 * Try contacting . The BlobsPaper.png 18:53, 2 June 2020 (UTC)
 * I'm not sure what's completely broken? It works fine for me, and given the absence of other reports, the issue may be on your side.
 * Cannot reproduce; see point 1.
 * This is not enabled by default. I don't think it was ever enabled for MCW. However, this feature may be requested.
 * Can reproduce. However, it's a rather minor issue, so may be fixed if someone has the time and wants to help. But it's not a priority.
 * Are you sure there aren't some custom CSS rules or browser extensions (ad blocker) interfering? Try using a private tab or disabling some extensions briefly. --AttemptToCallNil (report bug, view backtrace) 19:28, 2 June 2020 (UTC)
 * Can reproduce #1 in a vanilla firefox browser (logged-out): https://cdn.discordapp.com/attachments/569603162739179522/717613049338527844/unknown.png <span style="font-weight: 900;display: inline-block; width: 50px; border: 2px solid #a9a9a9; padding-left: 5px; padding-right: 5px;">MMK21 ⓉⒸ 05:48, 3 June 2020 (UTC)
 * Looks like some CSS isn't loading. I tried using a private window, but it loaded for me... --AttemptToCallNil (report bug, view backtrace) 08:34, 3 June 2020 (UTC)

Remove the exclusive template for Minecraft Earth and Dungeons
The result of the discussion was change. Template was redundant already, it should be removed.

If you go onto some Minecraft Earth and Minecraft Dungeons pages, you will see that there are exclusive boxes at the top for Earth and Dungeons. This is useless as if they are not exclusive, they would not be in the Earth and Dungeons mainspace. The exclusive template should not include Earth and Dungeons, but instead be only used for the editions of Minecraft. --Minecraft loot (talk) 22:46, 11 June 2020 (UTC)


 * This shouldn't even need a discussion, go ahead and remove them. -PancakeIdentity (talk) 00:38, 12 June 2020 (UTC)


 * I know I can, it is just that new pages on the mainspaces always have it in and my edits on it always get reverted so they should just remove the possibiliy of it by making it impossible to do (also, I was hoping a bot could do it to make it easier). --Minecraft loot (talk) 06:12, 12 June 2020 (UTC)


 * As PancakeIdentity said above, go ahead. Exclusive template is pretty much obsolete right now since they have gotten their own namespace. You can navigate through them easily from here and here. – ItsPlantseed ⟨₰|₢⟩ 06:50, 12 June 2020 (UTC)

Removing videos at the bottoms of pages
The result of the discussion was discussion not needed. This discussion was already had, we've decided to remove the outdated overview videos. They also violate the Video Policy.

At the bottoms of some pages, there are videos talking about the page, which I think should be removed:
 * They're usually outdated, with notes above the video saying so.
 * In my opinion they don't really explain anything the page doesn't already.
 * Many newer pages don't have videos, and might not ever get them, causing inconsistency.

This is just a suggestion, and I'd like to hear opinions on it. — Godslayerchickennugget (talk | contribs) 20:34, 25 June 2020 (UTC)


 * After a few discussions, we've actually decided to start deprecating the videos you're referring to and create our own new videos. See Minecraft Wiki:Projects/Wiki videos for more details. You're welcome to help out in any area of the project; script writing is probably the easiest if you're not experienced with recording or editing.--Madminecrafter12 (Talk to me 20:37, 25 June 2020 (UTC)

LOLCAT item names
The result of the discussion was do not implement Discord was opposed and it's a joke language.

I think it would be nice to have the LOLCAT names of items/mobs in the Trivia sections of pages, since it's not mentioned anywhere at the moment. — Godslayerchickennugget (talk | contribs) 14:33, 28 June 2020 (UTC)


 * What is even LOLCAT? Has it something with categories? --Treeislife2 (talk) 16:25, 28 June 2020 (UTC)


 * It's a joke language you can play the game in. You can find it with the other language options in the launcher and in-game. — Godslayerchickennugget (talk | contribs) 16:31, 28 June 2020 (UTC)


 * This was previously discussed on discord IIRC, and generally everybody opposed, because it is a joke language and made by the community. The original discussion was about the other english variants, but those were opposed too with the exception of redirects. FVbico (talk) 17:39, 28 June 2020 (UTC)


 * MCW:SG/F: Trivia related to the feature's in-game name when using translations is not allowed, as translations are not created by Mojang, making them unofficial. -- Hatsuki kiri 〔 T 〕 11:12, 8 July 2020 (UTC)


 * I don't think the Style Guide is a valid opposing argument here. It's not an unchanging, eternal law, and if we decided that we should document LOLCAT names in Trivia, it could easily be changed. -PancakeIdentity (talk) 23:36, 12 July 2020 (UTC)


 * I for one do agree with the style guide's reason though. FVbico (talk) 21:13, 17 August 2020 (UTC)

PRO
The result of the discussion was question was answered.

Since when was i PRO rank here?

Diamonddemon669 (talk) 19:14, 2 July 2020 (UTC)


 * If you edit wikis regularly, you get the PRO rank (which, for your information, disables all ads and proudly shows how you are good). It's just as simple as that! Note that "regularly" isn't as much as you would think... EDIT: Sorry if I misunderstood your question, didn't know if you wanted a date or if you meant "What did I do to have PRO?" Sagessylu (discuss | edits) 11:48, 3 July 2020 (UTC)


 * You will probably get notification in mail from Hydra, with starting


 * Dear "YourName"


 * Thanks for being an active editor...


 * From time and day, when it was sent, you have PRO. So if it was sent on July 7, 2020, from that day you have PRO.--Treeislife2 (talk) 15:10, 5 July 2020 (UTC)

Latin Minecraft-Wiki
The result of the discussion was completely oppose. Latin is a dead language.

Hi Folks,

I'll start a latin Minecraft wiki and I'm searching peoples for this. The minimum requirements for this are:


 * You must be at least know 25% Latin
 * You need to be 25% familiar with MediaWiki
 * You must have learned Latin at school or elsewhere

If you've meet these requirements, pls respond or reply to this post. It would be really nice when I get more people for my latin wiki project. The latin translations can be found here.

Atten007 (talk) 17:23, 9 July 2020 (UTC)


 * This is totally ridiculous. Latin is a dead language, and as such, it is utterly pointless and uselessly time-consuming to make a latin translation of this wiki. This also means that almost nobody can speak or write latin fluently, which makes it excessively hard to translate all the pages of this wiki. Moreover, if you take a look at the translations of this wiki, you see that, for example:


 * the Greek translation (13,000,000 native speakers) doesn't even have its main page entirely translated, and if you take a look at some random pages, they are all in English;
 * the Turkish translation (75,000,000 native speakers) has redlinks everywhere and looks stuck to the 1.14.4 version on the main page
 * the Swedish translation project (10,000,000 native speakers), created in 2011, has 13 translated pages.
 * So, simply, NO. Sagessylu (discuss | edits) 10:34, 12 July 2020 (UTC)


 * How it is possible to measure one's familiarity with the MediaWiki software in percents? 193.210.234.8 11:07, 12 July 2020 (UTC)


 * . What's the point of this? Also, if you're starting a translation project, you don't get to vet who is and isn't allowed to translate. -PancakeIdentity (talk) 23:34, 12 July 2020 (UTC)

Add 'See Also' Sections to Pages
The result of the discussion was already in place. We have both the see also template and the See Also section near the bottom of pages.

Guys, I've seen some other wikis and fandoms that add 'See Also' at the end of their page. Should the Minecraft Wiki also do this? 182.65.74.243 13:56, 17 July 2020 (UTC)


 * We actually already do that, see here for more details on what should be included there.--Madminecrafter12 (Talk to me 14:00, 17 July 2020 (UTC)
 * We usually use the see also template at the top of a page. For example, the Waterlogging page links to Snowlogging. The BlobsPaper.png 17:36, 19 July 2020 (UTC)

gamepedia migration
The result of the discussion was questions were answered.

will we merge with fandom? and what will happen then? or is it just a normal migration. What will happen to the minecraft fandom wiki? From The BumblebeeBee.png 16:00, 20 July 2020 (UTC)


 * We've no idea when they'll move to the UCP, but tomorrow they're going to mess up our logins. The fandom wiki will likely stay as it is right now, the most substantial changes will most likely be to this wiki depending on the severity of the change to the UCP; it depends on whether or not they decide to keep gamepedia mostly the same. We'll probably stay separate from the fan wiki, though. — Godslayerchickennugget (talk | contribs) 16:03, 20 July 2020 (UTC)


 * Wait whats the ucp? The BumblebeeBee.png 16:05, 20 July 2020 (UTC)


 * It's basically where they make new code for FANDOM and try to squash Gamepedia into the same codebase. It's probably more complicated than that but that's basically it. — Godslayerchickennugget (talk | contribs) 16:08, 20 July 2020 (UTC)


 * oh ok thx The BumblebeeBee.png 16:24, 20 July 2020 (UTC)


 * Merging with Fandom wikis is part of Project Crossover and should not be affected by the login system change. As for how Crossover with the Fandom wiki will proceed, it'll likely end with the Fandom wiki merged into this one. The UCP is a project to make a new platform for both Fandom and Gamepedia, though I could say "making new code for Fandom and trying to squash Gamepedia into the same codebase" is somewhat accurate. --AttemptToCallNil (report bug, view backtrace) 16:43, 20 July 2020 (UTC)


 * It looks like fandom is really outdated on the media wiki software so thats why they are doing Project Crossover, thank you! The BumblebeeBee.png 16:59, 20 July 2020 (UTC)


 * No, outdated MediaWiki is one of the reasons for UCP. Crossover is for merging wikis on the same topic between Fandom and Gamepedia. --AttemptToCallNil (report bug, view backtrace) 17:02, 20 July 2020 (UTC)


 * oh thank you for the info! The BumblebeeBee.png 18:57, 20 July 2020 (UTC)

Pufferfish
The result of the discussion was questions were answered.

Alright, let's settle this for good, instead of continuously changing the information on articles. Are pufferfish ever hostile? Do they attack? Are pufferfish passive, neutral, or aggressive?

The problem is, the Wiki doesn't even have an article on "attack". Pufferfish does cause the nearby players to take damage. Does that count as dealing damage? Does all damage dealt by mobs have to count as attacking? Is "attacking" a thing defined in the game's code? I don't know. I have an opinion, which is that pufferfish never attack, nor do they become hostile - thus, they are passive. However, that's merely an opinion, and I'm willing to accept evidence to the contrary.

However, I believe a stronger case can be made against the claim that pufferfish are neutral. A neutral mob is defined as one that, depending on the circumstances, can be both passive and hostile. If the behaviour of pufferfish can be classified as hostile towards nearby players, then it has to be accepted that it is hostile towards all players, as nothing about its behaviour changes when a player gets close to it. It does not chase players, and players too far away would simply be outside its attack range. This is similar to how ghasts are classified as hostile; hypothetically, imagine ghast had a melee attack instead of a ranged one. This would make its behaviour identical to pufferfish, and its absurd to claim that having a ranged or melee attack is the difference between being hostile or neutral. In conclusion, pufferfish should be classified as passive, if the conclusion is reached that it has an aura effect and does not attack, or as hostile, if the conclusion is reached that it does actively attack nearby players. Blue Banana whotookthisname (talk) 21:06, 28 July 2020 (UTC)


 * See the above topic on mob classification. My input is adopting that system, so we don't have to worry about flimsy player-made definitions, as we can easily use the game's provided groupings. -PancakeIdentity (talk) 05:13, 29 July 2020 (UTC)


 * That's true, but pufferfish still has to be defined individually, as there isn't even an agreement on whether it's friendly or hostile. Blue Banana whotookthisname (talk) 13:22, 29 July 2020 (UTC)


 * According to the game's definitions, it's friendly. -PancakeIdentity (talk) 19:09, 29 July 2020 (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)


 * Worth noting that this will likely be somewhat decided by this discussion. If we decide to keep and use legacy sprites, yes, they should be used for historical uses. -PancakeIdentity (talk) 04:41, 20 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)

Dark hydra design in the English Minecraft wiki
Hi folks,

I recently had an idea from a dark hydra design in the header. This does already exists in the German and the Portuguese Minecraft wiki, but I make sometimes edits in this wiki (sometimes in the Night), but the default hydra design is at night too bright for me, that‘s the reason because I need a dark hydra design. Sorry for my bad English, because my native language is German and I‘m German.

Atten007 (talk) 10:20, 23 May 2020 (UTC)


 * A sysop will have to import the de:MediaWiki:Hydradark.css page into here. A bunch of strings in Special:PrefixIndex/MediaWiki:Hydra may also need to be duplicated (minecraft-de have them). And then there's the skin, as skins are installed separately in the background. --Arthur200000 (talk) 16:09, 25 May 2020 (UTC

Instagram
Hi! After an extensive discussion on discord, I would like to develop this idea further. Here are some questions and answers:

• Why "Instagram"??

- It is a social network with several useful tools for different types of demand. In general, the site helps a lot with our branding and business.

• What content people will be able to find in the profile?

- This is the best part! I would like the immersion of each of our more than 300 editors from different cultures, places and different ideas. Firstly, I was thinking of we select each of editors who wants to share their suggestion. I want that everyone is heard, pretty much like in the videos project scripts. Some ideas: we could do a highlight (a storie shown in the profile) of interviews. The contributor could answer (if they want to) a series of questions about his personal and professional experience from games and FANDOM wikis, what is your best building in Minecraft, what are the aspects which allow you to stay in the community and make you like helping this site... We could ask a short survey and even trivia: where do you live, what is your work or favorite matter? There are many possibilities! So it is essential that there is participation from you.

- The posts could be Minecraft, Minecraft Earth, or Minecraft Dungeons news, minecraft facts you did now know, events, shoutouts, sharing good moments. There is inspiration from many profiles I saw.

- It's wanted a place where people still learning about Minecraft, so technical images, tutorials, or just facts are nice. Also, we must write a guideline about this stuff.

I want everyone's participation to have professional results, and most importantly, available from anybody concur. We can even share buildings, servers, gaming events, and stories about our hard work.

What do you think of this proposition? I really want to see this working, this could help people from the wiki get more attention :>

I'm willing for your help and open for observations and feedback from you. =^^= Julia Rusakova 05:48, 27 May 2020 (UTC) –Preceding unsigned comment was added by Marinah (talk • contribs). Please sign your posts with


 * I think that if we are interested in building a non-editor community, Instagram could be a good way to develop that. Otherwise, I'm not sure I see much use for it. No major opposition from me, but I am skeptical that it'd be worth the effort required.
 * I also think it's worth thinking about this long term. If we start and later abandon the Instagram page, it could very well create a negative impression about the wiki. I know from personal experience that forgotten social media pages can lower interest in a brand/product as it shows a lack of commitment and such. If we did this, we'd have to be in it for the long haul I think.-PancakeIdentity (talk) 07:09, 27 May 2020 (UTC)

English wiki forum and English wiki server
Hi folks,

I had recently these two ideas:


 * An English wiki Minecraft-Server, the German wiki has a Server on Unlimitedworld.de, but the English wiki doesn‘t have a Minecraft wiki-server.
 * An English wiki forum, for thinks that shouldn‘t be should be discussed in the Wiki and on the discord Server. I recommend Xobor for this, it‘s a very simple forum software!

I hope, that you will like these ideas. Please answer me, because answer would be very nice.

Atten007 (talk) 18:08, 12 June 2020 (UTC)
 * Not sure about that Xobor thing, it throws a security warning when I visit it.
 * I've been thinking about having a place to talk that is certainly not controlled by Fandom Inc. (The Fandom/Gamepedia server is partnered with Discord, and staff are known to interact with Discord T&S team members, so there are questions as to how far can Fandom staff affect communities on Discord the platform.) But I'm not sure there's actual need or possibility to do it.
 * There is a Fandom/Gamepedia Minecraft Server with a whitelist. Staff and some global groups can get in, Gamepedia MCW (incl. non-English) admins can get in too. Any editors can also get in, but must be vouched for by a member of some of the former groups. Not sure there's need for a server specifically for the English wiki. --AttemptToCallNil (report bug, view backtrace) 18:49, 12 June 2020 (UTC)


 * Just wanted to clarify, Unlimitedworld is not a server owned by the wiki, but it's affiliated to the wiki and there is a bit of staff overlap. But technically it's not a server by the wiki. Apart from that I don't get the point of a forum if a Discord server already exists. | violine1101(Talk) 07:23, 13 June 2020 (UTC)


 * Could you elaborate about "things that shouldn‘t be should be discussed in the Wiki and on the Discord server"? I don't really see what you are talking about... Sagessylu (discuss | edits) 16:32, 15 June 2020 (UTC)

@AttemptToCallNil Please ignore the security warning in Xobor because the certificate on this site is outdated. You can create the Xobor forum here @Sagessylu Sometimes there are things that you shouldn't post on the wiki or on the Discordserver, because they don't belong in the Discordserver, in the Wiki or on the respective discussion page of the respective article. If you're ready to create the forum, then now someone creates it here from this wiki. @Violine1101 I know that Unlimitedworld not a server that owned by the wiki. Please look for the discord server on the above listed answer.

Atten007 (talk) 16:28, 6 July 2020 (UTC)

Old posts
I personally think that the old posts in the talk (i.e. from 2014/2015) should be archived, they might be misleading for newcomers, and they take up space. I don't just mean this page, there are posts all over the wiki's talk pages that are outdated. There's a whole bunch of posts complaining about history that needs updating, for example 15w22c being changed to 15w23b, or changes to the page format that have been fixed. I think we should at least archive them. I get it that there are archives, but they are way too slow to update and not on pages that are slightly less active than here.

223.74.60.202 21:43, 21 June 2020 (UTC)


 * a mass effort to archive all talk pages containing any old discussions. Archives are typically done when a talk page reaches a significant length, not when discussions are old. If something is misleading and no longer needs attention, it can be closed. "Taking up space" isn't really an issue unless, like I said, the page is a significant length. One or two old discussions don't warrant an archive imo. The TOC and the "Add Topic" button take care of most navigation issues anyway. -PancakeIdentity (talk) 21:51, 21 June 2020 (UTC)


 * . No comment. --Treeislife2 (talk) 11:30, 22 June 2020 (UTC)

Minecraft Update Pictures
Hello I am trying to track down who makes the Minecraft update pictures. I have already confirmed that Svep does not make them. Any help is appreciated MattTheBanana (talk) 19:44, 9 July 2020 (UTC)


 * I'm not sure what you mean, but most of the possibilities I can think of come from Mojang themselves. -PancakeIdentity (talk) 21:36, 9 July 2020 (UTC)

Account weirdness
so i was logged in before the migration, and that account had more than 500 edits. There was no one on fandom with the same username. I was logged out like expected but when i tried to log in using twitch, it failed. 173.56.56.228 13:03, 25 July 2020 (UTC)
 * Then, there is problem in your Twitch account --TreeIsLife (talk) 22:31, 9 September 2020 (UTC)

@ instead of § for specific destinations in a page.
The result of the discussion was no change. Nonsensical proposal. &sect; is used to refer to sections. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  21:59, 4 September 2020 (UTC)

I think that instead of using a sigma (§) we should use an @ symbol. 182.65.102.56 08:31, 27 July 2020 (UTC)


 * Why? I don't feel super strongly, but I think § looks better and I don't see a real reason to change it, so for now. -PancakeIdentity (talk) 08:33, 27 July 2020 (UTC)
 * , it's not a sigma, it's a section sign. Is @ ever used for this purpose? --AttemptToCallNil (report bug, view backtrace) 08:34, 27 July 2020 (UTC)
 * @ is mostly used for pinging others, and I don't see why we should change the section sign.-- skylord_wars (talk) 10:46, 27 July 2020 (UTC)
 * How about #, because it is consistent with the url, which uses #? Blockofnetherite Talk Contributions 23:57, 2 September 2020 (UTC)
 * ---HumiebeeDiscuss anything with me Look at my edits 01:20, 3 September 2020 (UTC)

MCE namespace (or background)
I have a question, can the background change for MCE namespace? For example, the MCD namespace has an orage background so can the MCE namespace have like idk, a watery colored backround???---HumiebeeDiscuss anything with me Look at my edits 20:40, 19 August 2020 (UTC)


 * Don't really see a need for this, the current background already goes well with the skin. -PancakeIdentity (talk) 03:33, 23 August 2020 (UTC)

New Template: Wrong format
Sure, there is a change the sound table template, but what about, for example, a wrong blueprint format? There are two blueprint formats:

1.The one that doesn't have a link to the block when you click on it:

2. and the one that has a link on it such as Desert pyramid/Structure 182.65.102.56 10:37, 5 August 2020 (UTC)


 * I don't see how either format is wrong... also, the blueprint/grid templates allow doing  to remove the link. FVbico (talk) 10:48, 5 August 2020 (UTC)

Is there a short for the User in User:Blockofnetherite, for example? If so, can we add one?
The result of the discussion was the question was answered. No. Blockofnetherite Talk Contributions 21:40, 9 September 2020 (UTC)

I wonder if there is a short version of typing the User in User:Blockofnetherite. If not, is it possible to add a short for it, like or something? Any thoughts? Blockofnetherite Talk Contributions 03:55, 21 August 2020 (UTC)
 * The only shorthands are for this namespace and its nontalk equivalent. Saving three characters really isn't necessary anyway. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  03:57, 21 August 2020 (UTC)

How to comment properly on this wiki?
We haven't used this wiki much when speaking of accounts, but we do want to help people in the 'Talk' pages. So we've tried to commenton someone's post and it turned out as a really horrible-looking reply. Plus we can't get rid of the thing that says "You recently worked on an article. Would you like to save your changes to your friends?". So yeah, we need a bit of assistance. Book and Brook (talk) 08:38, 9 August 2020 (UTC)


 * If you want to reply like I'm doing now you can add a : to the beginning of your sentence to naturally indent it. Add more than one to indent it further. Not sure about the other thing though. -EatingSilencerforBreakfast (talk) 01:00, 11 August 2020 (UTC)

A small question about archiving
The result of the discussion was the question was answered.

How do you install OneClickArchiver? I just do it the old fashined way, copy the contents of a section, cut it, and paste it into the archive (I do the closed discussion template for CP)How?---HumiebeeDiscuss anything with me Look at my edits 21:58, 27 August 2020 (UTC)
 * Add archive config to your common.js page. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  20:16, 28 August 2020 (UTC)
 * How do you use it? Looking at the source editor, I can find nothing, is it something to do with mobile web editor? I'm on mobile web, not normal mobile so i'll see.---HumiebeeDiscuss anything with me Look at my edits 20:48, 28 August 2020 (UTC)
 * nvm, thanks for documentation.---HumiebeeDiscuss anything with me Look at my edits 20:50, 28 August 2020 (UTC)
 * Oops, it's actually archive script that you should add to your common.js page. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  22:11, 28 August 2020 (UTC)
 * Oh... thanks!😇---HumiebeeDiscuss anything with me Look at my edits 22:19, 28 August 2020 (UTC)
 * Why is this not a gadget? --AttemptToCallNil (report bug, view backtrace) 20:41, 28 August 2020 (UTC)

Minecraft Dungeons: Icologer or Chillager?
I know I've posted similar posts on other pages, but anyway....

Is it called the Icologer or Chillager? The Chillager page has already been infested with "Icologer", plus Mojang Studios calls it an Icologer, so should it be renamed on this entire wiki too? Creeping Winter (talk) 14:49, 29 August 2020 (UTC)


 * If it's referred to as the Icologer by Mojang, it should without a doubt be referred to as such on the wiki. The opening line of the article can say something like "The icologer, also known as the chillager, ..." if need be. -PancakeIdentity (talk) 22:35, 29 August 2020 (UTC)
 * This also applies to the Illusioner since people referred to it as the Illusionist, but in the recent teaser video released by Mojang Studios yesterday you can clearly see that its boss bar says Illusioner. James Haydon (talk) 01:56, 30 August 2020 (UTC)

Apparently lossy compression was applied to all images (including all revisions) on this wiki

 * The following is a closed discussion. Please do not modify it. Any editors wishing to make further comments should start a new topic.

There is lossy compression applied to ALL images (including revisions and lossless file types) and I think it has to do with the media migration. Is this temporary or is this permanent? Fadyblok240 (talk) 03:27, 19 August 2020 (UTC)
 * I've also seen some svgs look blurry, like the Minecraft Wiki header in the main page, or hearts on Health since the migration. -- Unavailablehoax (talk) 11:18, 20 August 2020 (UTC)
 * For me, sometimes the images just don't render at all.---HumiebeeDiscuss anything with me Look at my edits 16:31, 20 August 2020 (UTC)
 * It appears that image scaling is kinda broken. Scaling problem.png This image of Mclogo.svg is supposed to be scaled to 295px in width, which can be seen in the url. However, the image is actually 331px in width. --Unavailablehoax (talk) 22:34, 21 August 2020 (UTC)
 * Also, it should just use the original svg instead of a png conversion --Unavailablehoax (talk) 22:37, 21 August 2020 (UTC)
 * Okay, so this is almost DEFINITELY a problem with the migration. [[File:Migration problem.png]] In the Bedrock Edition page, the images that are blurry are from the new url (static.wikia.nocookie.net) and images without this problem are using the old url. (gamepedia.cursecdn.com) You can check what url an image is from by right clicking it and selecting 'Copy image address' (At least on Chrome) --Unavailablehoax (talk) 23:11, 21 August 2020 (UTC)

Template:Schematic uses outdated sprite sheet
The loss in image quality has been mostly resolved, but the template uses an old revision of File:SchematicSprite.png. I first noticed the discrepancy when I removed the corner stairs from the sheet and put tree blocks in their place. However, when I added the samples of the new IDs for tree blocks in the documentation, the intended sprites would not show up and instead be replaced with corner stairs or nothing. I think this problem is related to the media host migration. Fadyblok240 (talk) 04:36, 24 August 2020 (UTC)
 * Oh, I've talked about this problem at the admin noticeboard for BlockSprite and InvSprite, and while I really don't know how these stuff really works, AttemptToCallNil could help. – Unavailable Hoax (talk) 12:20, 6 September 2020 (UTC)
 * Does it work now? --AttemptToCallNil (report bug, view backtrace) 18:09, 6 September 2020 (UTC)
 * It seems to work now, but I don't know how it was fixed. Fadyblok240 (talk) 10:39, 8 September 2020 (UTC)

Humiebee for admin
The result of the discussion was declined by Humiebee, plus opposition.

I think he is a constructive user so can we promote him into an admin TheGreatSpring (talk) 09:03, 8 September 2020 (UTC)
 * , simply because they've only been here since this June (old account)/July (new account). They've simply not been on the wiki long enough. FVbico (talk) 09:25, 8 September 2020 (UTC)
 * ok TheGreatSpring (talk) 09:27, 8 September 2020 (UTC)
 * I agree with FVBico, i have been on this wiki since may, i am the same level as humiebee, and i dont feel ready to be admin yet. James Haydon (talk) 14:00, 8 September 2020 (UTC)
 * Sorry, but i can't agree. I am on Minecraft Wiki (counting my old account) more then 2 years, and i still did not have any ranks. And i've been editing even on Wikipedia. He received autopatrol for 2 reasons
 * Of course, many verified edits
 * Well, on other hand there was so much edits, that it makes inpossible to catch vandallers.
 * Administrator is not like constructive user job. Here, you need to know, how to manage wiki. Also, it is harder, because you need to know, what tools can be used in what situation. Well, if this was not in case, it will be like on Fandom wikis. Users block other users, because they don' t agree, or simply, because they are reverting vandalers edits. So vandaler got 3 weeks, you 1 year.
 * One note: I am actual Admin on one Gamepedia Wiki, so i know, how hard it is. --TreeIsLife (talk) 14:11, 8 September 2020 (UTC)
 * for now. Still too new. Simply being constructive isn't sufficient. I am an admin on the English Wikipedia, and I consider myself quite an experienced editor here, but I don't yet feel qualified to be an admin here. There's more to it than simply working on the wiki content. And what does "level" have to do with anything? ~ Amatulic (talk) 14:41, 8 September 2020 (UTC)
 * I completely myself, you promote a patroller, not an auto patrol, also you promote someone who's had at least like 3 yrs of experience and why? Like that's such a borrrring reason, contructive? There are hundreds of contructive users on this wiki and many are autopatrol but an admin? you joking.---HumiebeeDiscuss anything with me Look at my edits 19:17, 8 September 2020 (UTC)

Adding images to templates
The result of the discussion was Added.

Edit. Should we add image to Stub template? --TreeIsLife (talk) 08:02, 2 September 2020 (UTC)
 * , but it will better, if there will be another image. --TreeIsLife (talk) 08:02, 2 September 2020 (UTC)
 * I images on every message box, but only if they are fitting. I don't see how an allow block is fitting for a stub template. Is there even a fitting image for this one? — Thomanski | t | c |  15:59, 2 September 2020 (UTC)
 * , if the image is customizable, and if the message could be customized based on topic. Fadyblok240 (talk) 03:55, 3 September 2020 (UTC)
 * Meh, it will make it look like the other templates, though i am fine with it being plain. James Haydon (talk) 23:14, 4 September 2020 (UTC)
 * It's fine but is it really nessicary?---HumiebeeDiscuss anything with me Look at my edits 00:21, 5 September 2020 (UTC)
 * Ok, so now, there is Dark Oak sapling, which is like - not compleated article/not done (or small article). --TreeIsLife (talk) 20:34, 8 September 2020 (UTC)

an extremely controversial proposal that will probably never get any support
Noe idk if this is even relevant but I propose........ to make a somewhat new. mob category. So far, there are 2 community-made mob categories, defensive (technically sub-category of passive), and neutral. I propose to make a category, mini-boss a sub-category of hostile, now this started with the fact that Elder Guardians are bosses $$ but not $$ despite them being the exact same. Mini-bosses are also in dungeons (so it could possibly improve my hopes for support) but the mini-bosses would be the Elder Guardian and the Piglin Brute. These mobs have things in common. ---HumiebeeDiscuss anything with me Look at my edits 01:21, 28 August 2020 (UTC)
 * 1) They are non-renewable, idk if this is a definition of mini-boss though
 * 2) They defend a structure (Ocean Monuments and Bastion Remnants")
 * 3) Multiple of then spawn within a structure, but only upon generation (reated to points 1 & 2)
 * 4) Have lot's of health and do lot's of damage, similar but weaker than a boss.
 * 5) Finally, they have a mini/weaker version, guardians and piglins.


 * . 1) All mob categories on the wiki are currently community-made. 2) Community-made mob categories have been proven to not work for a variety of reasons (see multiple above/archived discussions). 3) I don't think we ever settled on "defensive" being a category. 4) Elder guardians are not bosses in Bedrock (at least, not in any way they're not in Java). This was a myth started by the fact that they were added in the "boss update". And even if they were, regrouping them in a category that is explicitly separate from what the game puts them in is a very bad idea. 4) Dungeons is a completely different game from the sandbox Minecraft. Something being in that game has no bearing on whether it should be considered for this one. 5) IMO, piglin brutes are too plentiful in bastions to be considered a "mini-boss". -PancakeIdentity (talk) 22:07, 29 August 2020 (UTC)
 * "All mob categories on the wiki are currently community-made." I'll have to point out that the Minecraft Books specifically categorize mobs as passive, neutral, or hostile. For 2, I'll need a link. For 5, I disagree as I usually find only 4-5 piglin brutes in bastion remnants. Blockofnetherite Talk Contributions 02:03, 31 August 2020 (UTC)


 * I really, really don't think the books should be counted as official sources of information when nothing in the game or the code categorizes things this way. More likely, the community made those terms, then those books adopted them. They are useful as a very surface level descriptor, and for most of Minecraft's history, didn't have much issue categorizing every mob. Here's one discussion, here's another, here's a third. -PancakeIdentity (talk) 08:03, 31 August 2020 (UTC)


 * . I want to abolish all 'mob categories'. Behaviors of mobs can simply not be summarized in one or two words, in my opinion. — Thomanski | t | c | 22:20, 29 August 2020 (UTC)


 * I think mob categories are more useful for briefly describing mob behavior, which is then explained in detail elsewhere, than "categorizing" mobs. Elder Guardians could perhaps be described as mini bosses, but I don't think there is any need to categorize them as such. Mob categories are just too difficult to properly define. jahunsbe (talk) 23:51, 30 August 2020 (UTC)


 * I personally believe that categorizing mobs are very useful, and despite some mobs being incredibly complex in its behavior, simplifying them to "passive", "neutral" or "hostile" is very useful. But I don't see the "mini-boss" as the best approach to this, neither do I think it is a bad idea. Blockofnetherite Talk Contributions 02:03, 31 August 2020 (UTC)


 * Because this category is completely made-up. As for your points, I can get exceptions to them: 1. Shulkers. 2. Guardians, Piglins, Shulkers. 3. Villagers, Piglins, Evokers... 4. Ravager? and 5. No example. Sagessylu (discuss | edits) 17:02, 31 August 2020 (UTC)
 * Sry Humiebee, but i think we can close this discussion. This won't have any support. --TreeIsLife (talk) 22:44, 9 September 2020 (UTC)

Deletion of several Tutorials pages
Hello everyone,

I'd like to know if you think these sub-pages of Tutorials should be deleted : Speaking for myself, I these three deletions. Sagessylu (discuss | edits) 12:39, 15 June 2020 (UTC)
 * Tutorials/Airlock : almost completely pointless, the history is mildly active, but nobody has edited this page regularly for years
 * Tutorials/Desert shelter : completely pointless, too much specific, almost untouched since its creation
 * Tutorials/Pig parking lot : completely pointless, and nobody edited this page for a full year
 * Tutorials/How to find caves : information is also in Tutorials/Exploring caverns

for removing Tutorials/Airlock, Tutorials/Desert shelter if merged with Tutorials/Shelter types and  for removing Tutorials/Pig parking lot --Treeislife2 (talk) 10:32, 17 June 2020 (UTC)
 * Ok, thanks! Just wondering, why exactly do you oppose for Tutorials/Airlock? Sagessylu (discuss | edits) 17:17, 17 June 2020 (UTC)


 * I feel airlocks are a genuinely useful tool in the context of water. If an article hasn't been updated in a while, the solution should usually be to update it, not nuke it. -PancakeIdentity (talk) 03:49, 23 June 2020 (UTC)


 * Well, after taking a look at it, the Airlock page is mainly talking about the sand + torch mechanic currently, even if there are more airlocks with doors, signs... I thought it was only supposed to talk about these useless one-use "sand airlocks", but I was wrong, and you're quite right. So, I updated my original post to not include the Airlock page. Sagessylu (discuss | edits) 08:15, 23 June 2020 (UTC)

Tagged "Pig parking lot" for deletion, I will do so with "Desert shelter" at some point, when I'll merge it with "Shelter types". I won't do anything with "Airlock" except maybe work on it to make it focus less on those sand staircase things and more on techniques like using doors, because it's quite misleading right now. Sagessylu (discuss | edits) 10:17, 6 July 2020 (UTC)
 * I agree that the "Pig parking lot" tutorial is useless. I mean, why to build a complicated parking mechanism when you can just use leash and a fence? 193.210.234.8 11:13, 12 July 2020 (UTC)

I also want Tutorials/How to find caves to be deleted, since a section of Tutorials/Exploring caverns provides the same information. Fadyblok240 (talk) 00:13, 14 July 2020 (UTC)
 * That's right, I added it to the list. Sagessylu (discuss | edits) 15:42, 20 July 2020 (UTC)

Since Tutorials/Redstone machines duplicates the scope of Tutorials/Mechanisms, the former should be deleted, following the movement or deletion of contraptions on a case-by-case basis. –Preceding unsigned comment was added by Fadyblok240 (talk • contribs) at 13:51, 23 July 2020 (UTC). Please sign your posts with
 * Actually, I converted the article into a redirect after moving or deleting all the content. Fadyblok240 (talk) 01:08, 12 August 2020 (UTC)


 * deletion of Tutorials/Pig parking lot and merging/redirecting of Tutorials/Desert shelter and Tutorials/How to find caves. I don't see the harm in keeping "Tutorials/How to find caves" as a redirect, especially since it was created in 2011 (before "Tutorials/Exploring caverns") and may have incoming links from outside the wiki. – Sonicwave talk  22:46, 4 September 2020 (UTC)


 * , there was a clear consensus, now can an admin delete the pig parking lot page?---HumiebeeDiscuss anything with me Look at my edits 21:36, 15 September 2020 (UTC)

Conflicting Licenses
As a part of Minecraft Wiki:Projects/Cleanup open tags I came across File:Grid Charged Thaumium Cap (Thaumcraft).gif which seems to have twp conflicting Licenses applied to it. Does anyone know which is the right one? -- Asarta   (Talk)  15:44, 13 September 2020 (UTC)
 * I believe the more restrictive one (in this case, copyright / fair use) takes precedence. --AttemptToCallNil (report bug, view backtrace) 18:05, 13 September 2020 (UTC)
 * removing the extra license. Fadyblok240 (talk) 12:38, 14 September 2020 (UTC)

RfC: appoint a new bureaucrat
Majr is inactive, leaving Madminecrafter12 as the only active bureaucrat. It has been supported by several users on Discord that it's optimal to have 2 bureaucrats for "balance" purposes.


 * 1) Does anyone think we actually don't need a new bureaucrat?
 * 2) Who could be a new bureaucrat? (Actual discussion/voting on specific candidates could be separate and come later, I think)

Any thoughts? --AttemptToCallNil (report bug, view backtrace) 22:55, 26 June 2020 (UTC)


 * Don't necessarily think it's needed, as not that much needs to be done by a bureaucrat that an admin cannot do, but I don't oppose more bureaucrats. FVbico (talk) 23:04, 26 June 2020 (UTC)


 * Well, I feel like the definition of "need" is a bit subjective; but I will say I think it would be quite useful to have a second (active) bureaucrat. As for who it would be, I'm not strongly opposed to any of the current admins being promoted; I'd prefer to leave the deciding up to the community and I'd close the discussion, promoting if there's a sufficient consensus to do so. As for my reasoning about why having another bureaucrat would be beneficial, I'm lazy so I'm just gonna copy what I said on Discord:


 * "I feel like the main reason would most likely be RevDelete. As an example, there was a recent case of a user revealing private information on their profile and it was noticed at a time where neither I nor Markus (the wiki manager) was active. It wasn't until I was woke up the next day that it was hidden. Such cases aren't very common, but they do happen; and private personal information really should be expunged as quickly as possible."


 * "Another reason may be for "balance" purposes; e.g. if my account were to get compromised or I suddenly become inactive (in which case there would be no bureaucrats), or even simply because I need a second opinion on a bureaucrat-related matter . I guess this argument is weakened by the fact that staff exist, but still, I feel like it's good practice in general to have more than one local user with the ability to hide edits and grant/remove any user rights."


 * Some stated that the RevDelete argument isn't particularly strong because once we move to Fandom, bureaucrats will likely no longer have the ability to RevDelete. However, I don't see the probable removal of RevDelete by bureaucrats eventually as a reason to not promote any currently; we don't know what exactly is going to happen or when it's going to happen, so imo it makes the most sense to act upon the current situation and accommodate if the situation changes in the future.--Madminecrafter12 (Talk to me 23:28, 26 June 2020 (UTC)


 * We're not moving to Fandom. Unified Community Platform won't affect URL or Gamepedia brand. There is also no proof, if it will affect something as whole. In this Phase 1 only some elements will change. In Phase 2 however, here will be that changes to skins, copyright, and new features. --Treeislife2 (talk) 14:24, 28 June 2020 (UTC)


 * We're not merging with the Fandom Minecraft Wiki, if that's what you mean, but it's likely eventually we will adapt many of Fandom's features. This probably includes not allowing bureaucrats to RevDel, as staff have actually stated. But my argument was actually that we don't know for sure how this is going to happen and that it's probably going to be a while.--Madminecrafter12 (Talk to me 14:30, 28 June 2020 (UTC)


 * I didn't say merging with Fandoms Minecraft Wiki. This is not real for now, as there are big diffrences between these wikis (mostly noticed - it is really fan-made wiki, and combination of documentation wiki with extreme fan wiki is like breathing cat with ocelot in Minecraft 😀). You can ask staff, if they will keep this feature, but since Gamepedia is still upgrading, there is no reason for Fandom to revoke feature (only, if they will say, that feature is not needed). No one knows, how long it will be till end of Phase 1. Simpliest wikis on Fandom were already merged (but this is only Stage 2 from 4 of them - and you know, that stage 1 started on March 11, 2020). --Treeislife2 (talk) 16:23, 28 June 2020 (UTC)


 * Support adding a new bureaucrat, I don't see why not. We effectively only have one right now. I think any of the admins would do well, though I think picking someone who can cover more of Mad's inactive time would be preferable. -PancakeIdentity (talk) 00:54, 27 June 2020 (UTC)


 * I would support adding new admins instead of bureaucrats since there are only 9 admins. Promoting new bureaucrats doesn't seem to help the wiki much. I would say we can wait until Majr is inactive for 1 calendar year before taking action.-- skylord_wars (talk) 05:15, 27 June 2020 (UTC)


 * The problem with having only 1 bureaucrat is that if ze becomes inactive, we have no way to get a new one. We can always ask to make someone a bureaucrat, but that is a last resort. The BlobsPaper.png 06:21, 28 June 2020 (UTC)

Possible candidates?

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * The result of the discussion was promote Nixinova.

The discussion above to promote a new bureaucrat seems to have a pretty clear outcome of yes, a second bureaucrat would be useful. As I myself am the only active bureaucrat, I think my own opinion could be useful as well, and I do indeed agree with promoting a new bureaucrat. The few people who were opposed or neutral towards having a new bureaucrat seemed to think that if we were to promote another bureaucrat (leaving aside whether such would be necessary), Nixinova would be the best option. There has been quite a bit of well-reasoned support with very little valid opposition, and this discussion has been inactive for about a week. It is worth noting I have no personal objections to granting Nixinova bureaucrat, so the decision is pretty clear to me. If anyone has any thoughts or objections, comment in the section above or create a new subsection; this specific discussion is closed. --Madminecrafter12 (Talk to me 15:59, 23 September 2020 (UTC)

I thought I'd go ahead and open up this sub topic. If we add a new bureaucrat, which seems to be where the above discussion is heading, who should it be? AFAIK, standard practice is to choose from current admins (correct me if I'm wrong). I mentioned my stance above; any of the current admins seem good but one who covers Mad's inactive times would be better probably. If we narrow it down to just a couple and/or a specific user is "nominated", I may give my specific feedback regarding those/that user(s). -PancakeIdentity (talk) 09:31, 8 July 2020 (UTC)
 * '''Nixinova. There are many reasons but lets start simple
 * He is an admin (obviously)
 * He has beencontributingg to this wiki for many years and has been an admin for more than a year.
 * He's number 2 in the minecraft wiki.
 * He's been playing the game since 1.4.2
 * He owns all the versions of minecraft (including earth and dungeons) except education and discontinued versions
 * Very Knowledgeable in minecraft
 * he's never shown any inactivity from the time he registered his current account
 * He lives in New Zealand and as what User:PancakeIdentity said, covering User:Madminecrafter12's inactive times would be the best and since Nixinova lives in New Zealand, it's perfect.
 * so that is why i think he should be bureaucrat.
 * 1 note is that he's the newest admin if that has any effect.
 * The BumblebeeBee.png 00:47, 15 July 2020 (UTC)
 * I agree that nixinova would make anexcellentt bureaucrat.--Minecraft loot (talk) 10:46, 22 August 2020 (UTC)
 * Nixinova thinks twice before acting and always have amazing and precise suggestions on most subjects. --dr03ramos Piston.gif (talk) Admin wiki[pt] 00:03, 29 August 2020 (UTC)
 * I didn't comment on this before because I didn't know what bureaucrats actually did (just user rights and revdel, right? anything else?), so unless revdel doesn't work on mobile for some reason (in a way I can't hack around) I'd be fine with being a bureaucrat. (And thanks for the praise above :).) <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  00:35, 29 August 2020 (UTC)
 * Correct. The only permissions bureaucrats have that admins don't are the ability to hide revisions and logs and give users any local right (patroller, admin, bureaucrat, etc.). --Madminecrafter12 (Talk to me 00:51, 15 September 2020 (UTC)


 * for above reasons Blockofnetherite Talk Contributions 21:29, 9 September 2020 (UTC)
 * Having two active bureaucrats, I believe, is actually . Very bad edits that need to be RevDeleted may be necessary when @MadMinecrafter12 is offline, knowing that @Nixinova is in about the opposite time zone as @Madminecrafter12. Sure, contacting User:Game widow is an option, but is the very last result. Overall, if we need a new bureaucrat (which I observe is useful considering what I just said and above reasons), then User:Nixinova would be the best candidate. Blockofnetherite Talk Contributions 19:44, 15 September 2020 (UTC)
 * also for the above reasons --Minecraft loot (talk) 21:10, 13 September 2020 (UTC)
 * No stance on whether we need bureaucrats (but slightly leaning towards that we do). If we do decide we need a bureaucrat, then I'd support Nixinova. --AttemptToCallNil (report bug, view backtrace) 00:54, 15 September 2020 (UTC)
 * for Nixinova. But, please, do not forget, that he is also administrator on Hytale wiki. Idk, how he can manage 2 wikis at once with no problem, but i am not oppose that.--TreeIsLife (talk) 12:46, 15 September 2020 (UTC)
 * I don't think being an admin on another wiki should be considered an issue at all. Nixinova is already actually an administrator here and by looking through his contributions you'll see he's very active here. And bureaucrats just have a few additional tools. It's not like bureaucrats are expected to devote all their free time to changing user rights or deleting revisions on the wiki.--Madminecrafter12 (Talk to me 13:12, 15 September 2020 (UTC)
 * Hytale Wiki at the moment isn't much work (since the game only comes out next year) and since bureaucrat is just a couple extra tools it shouldn't be too much to handle. <b style="border:1px solid #10a"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b></b>  00:59, 16 September 2020 (UTC)
 * – No objections for Nixinova (or any of the other active admins for that matter). As mentioned above, the fact that he is in a different timezone than Madminecrafter (as well as MarkusRost or the other Gamepedia wiki managers) may be useful for urgent RevDel requests. Even if that might be removed from bureaucrats in the future, having an extra bureaucrat for promoting users seems useful in case Mad also becomes inactive. – Sonicwave talk  20:07, 16 September 2020 (UTC)
 * Can we promote him now?---HumiebeeDiscuss anything with me Look at my edits 20:58, 16 September 2020 (UTC)
 * While there is a lot of support, it does seem nobody even thought about any other admin, such as sonicwave or knight miner. Additionally, aside from the initial arguments, nothing was added by supporters. All but being "nr 2" (which says only about quantity of edits, not quality BTW) are applicable to other admins as well, so perhaps at least put up other suggestions as well, rather than have a poll with only 1 option provided. :) FVbico (talk) 21:34, 16 September 2020 (UTC)
 * The most major argument would probably be the timezones one as no other admin (not even mad) live in like +7 to -11 timezone while everyone else is -8 to +6 (unless attempttocallnil lives in eastern russia, if so, also a possible candidate) if mad or markus rost are not online, whos going to be to rev delete some extreme personal or things that violate rule #3?---HumiebeeDiscuss anything with me Look at my edits 21:49, 16 September 2020 (UTC)
 * Even now, rev deletes are not something that is immediately done, and you can be kept waiting for it for more than half a day, no matter the timezone. So while it is an argument, it's not necessarily a must. To be completely clear, I do NOT oppose nixinova at all, but as it currently stands in this discussion, it really looks like nobody else even got considered. FVbico (talk) 21:55, 16 September 2020 (UTC)
 * For the record I don't think I would want to be bureaucrat; I have been trying to reduce activity on here (and most internet places) for a while and therefore might not always be available. As mentioned above though, I wouldn't oppose any of the other admins either. It might be worth noting that is already a bureaucrat on Russian MCW and therefore might have some experience with the RevDel policy already. – Sonicwave  talk  22:00, 16 September 2020 (UTC)

If Piglins are called "hostile" can we revert them?

 * The following is a closed discussion&#32; of whether piglins are neutral or hostile. Please do not modify it. Any editors wishing to make further comments should start a new topic.

I think it is fine to close this topic because there is no reply in almost a month, leaving this discussion inactive. Also, the question has been answered and the piglin situation is pretty much solved. They're neutral. Blockofnetherite Talk Contributions 16:48, 26 September 2020 (UTC)

There are many times that piglins are called "hostile" so can we revert them? -49.146.40.160 10:04, 23 August 2020 (UTC)
 * Piglins are hostile by default so that's the definition. Idk why there's like a giant edit war about the neutrality of the piglin.---HumiebeeDiscuss anything with me Look at my edits 15:24, 24 August 2020 (UTC)
 * But if you wear gold armor they become neutral so I call them neutral. 49.146.40.160 02:26, 25 August 2020 (UTC)
 * See my edit on my talk---HumiebeeDiscuss anything with me Look at my edits 22:37, 25 August 2020 (UTC)


 * Let's stop this edit war. It should say "Piglins are neutral mobs native to the Nether. If the player wears gold armor, they become neutral." Sounds better than "Piglins are neutral mobs native to the Nether. If the player wears gold armor, they become neutral." However, we still have something going on: in the Mob page, adult piglins have been moved to the neutral section to the hostile question. I propose a new question: In the Mob page, should we place adult piglins in the neutral section, or the hostile section? Blockofnetherite Talk Contributions 01:59, 26 August 2020 (UTC)
 * The edit wars have stopped, though there is still some discussion about the status as it is mainly hostile, partialy neutral and partialy passive so it would fit into hostile/neutral??? like the spider.---HumiebeeDiscuss anything with me Look at my edits 02:11, 26 August 2020 (UTC)


 * I once again point to the mob category discussion above. These simple, largely undefined in-game terms are not great for grouping more complex mobs like piglins. For what it's worth though, I'd say they're neutral, especially if we're gonna count spiders as neutral. -PancakeIdentity (talk) 17:42, 27 August 2020 (UTC)

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 [ Book and Quill.png 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 [ Book and Quill.png 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 [ Book and Quill.png Diamond Pickaxe.png ] 12:33, 10 October 2019 (UTC)
 * What about Enchanting/Mechanics]]? --MMK21stream (talk) 14:17, 1 June 2020 (UTC)


 * See below, we decided against this. -PancakeIdentity (talk) 18:22, 1 June 2020 (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, even though 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 [ Book and Quill.png 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. <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: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 [ Book and Quill.png 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)


 * This is why Wikipedia has disabled sub pages in the main-space. --Fadyblok240 (talk) 23:41, 16 August 2020 (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)


 * . Sounds we know specifically to be from C418 (with a source) should still use the license, but I think using the general Mojang license is better in most cases. -PancakeIdentity (talk) 04:38, 20 May 2020 (UTC)

Using sprite grid with schematic sprites
Has anyone tried to lay out schematics using sprite grid? I am trying to draw a stretch of railway, and it feels like a bad idea to be typing the full names repeatedly. In other words, I want this to work:

CC User:Majr -- I think know a fuckton about these things. --Arthur200000 (talk) 16:56, 3 June 2020 (UTC)


 * In order to do this, SchematicSprite would need to be changed to the same type of template+module as BlockSprite. So unless anyone is willing to do that; sorry. FVbico (talk) 17:00, 3 June 2020 (UTC)

Collapses for Fixes section
Hi. As some of you noticed, fixes were collapsed on some versions. But, why? It looks really bad (or at least, there is small text "Bit bugs fixed in ..Parent version.."). There was no discussion and it is only on 1.16, 1.8 and 1.9 articles. However, it still load this, because it is text and it does not display in reading mode (if available). Is this really a need? --Treeislife2 (talk) 09:34, 21 June 2020 (UTC)


 * for making collapses. If yes, then at least implement code to Module, not to article (+ do some formatting). --Treeislife2 (talk) 09:34, 21 June 2020 (UTC)


 * if uncollapsed by default, and changed in the module as said above. — Thomanski | t | c | 14:30, 22 June 2020 (UTC)


 * Oppose auto-collapse, some support for collapsed by default. -PancakeIdentity (talk) 03:46, 23 June 2020 (UTC)


 * the auto-collapse, because it makes it easy to scroll and miss the fixes. However, I'm if it is collapsed by default, and done properly. Sagessylu (discuss | edits) 15:39, 25 June 2020 (UTC)

Rework command pages
The subpages of command have been missing a lot of information, and I propose that we rework these command pages.

Some changes I suggest：
 * Use argument and literal to show arguments and their types (these two templates are still WIP). Use arg desc to show formats of arguments.
 * Use result table to list results of commands. Results includes:
 * Unparseable - Syntax is wrong, command is unknown, or arguments are illegal
 * Failed - The command is executed but the success count is 0
 * Successful - The command is executed and the success count is not 0
 * Terminate - Does nothing and doesn't output anything.
 * Exception - Throw an exception other than  during execution.
 * Use output table to list results of commands. Outputs includes:
 * Success Count - Success count stored in command block when the command is executed by it.
 * - Success value stored by
 * - Result value stored by

I have roughly reworked some, see User:Chixvv/Sandbox/long. And hope someone can help to rework other pages. Any thoughts? --Chixvv (talk) 15:41, 11 August 2020 (UTC)


 * Now all templates are done, and I'll edit these command pages tomorrow.--Chixvv (talk) 13:24, 19 August 2020 (UTC)
 * I see you've implemented this, and I the changes. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  03:39, 20 August 2020 (UTC)
 * as it does improve the layout of the page.-- LakeJasonFace.png Lakejason0  (Talk • Contribs) 10:26, 21 August 2020 (UTC)

Can I edit "Bedrock Edition scripting documentation"
I am thinking of editing Bedrock Edition scripting documentation but I am not sure if I am allowed to. This is my first time contributing to wikis. I want to add on to the createEntity that if the Type is specified as item_entity then TemplateIdentifier should be the item identifier and not the identifier of an entity. 73.241.136.27 02:57, 15 September 2020 (UTC)
 * I don't see any protections. Well, most of pages are not protected. But admins are mostly blocking pages with hype. These are: Minecon few hours before beggining, new major update (planned/released) and of course, pages with vandalism. And, IPs can't create any new pages (except talk pages), so you should Create a new account which will grant you abiloty to create pages + you will can use this account on any other Gamepedia and even Fandom wiki--TreeIsLife (talk) 13:01, 15 September 2020 (UTC).
 * Okay thanks, I will create an account. 73.241.136.27 17:22, 15 September 2020 (UTC)

Reworking mob categories
We've had snippets of this discussion across the wiki and on discord, but nothing ever came of it. I thought I'd bring it up here. In my opinion, the mob categories are baseless and confusing. Currently, we split mobs into "Passive", "Neutral", and "Hostile". However, these categories have a number of issues:


 * They're not based on anything. None of these three terms are defined anywhere in the game or in the code.
 * They're somewhat unclear. "Neutral" in this case doesn't really mean neutral in any typical sense of the word. The naturally hostile "neutral" mobs may also be confusing for less experienced players.
 * They're ambiguous. We have cases like the defensive pufferfish; the "one-and-done" bees, llamas, and pandas; the (usually) naturally hostile spiders, piglins, and polar bears; and more.

I propose reworking the categories to the following, more game-defined definitions: Animal/Friendly and Monster. If we went with "animal", I think other categories such as NPC for villagers and such might be needed, so I think I prefer friendly. These are better defined by the sound categories, the "Monster Hunter" advancements, and the actual system used to define mobs in-code. The currently "neutral" mobs would be sorted into the category the game puts them in. (Edit: Given tweets by Mojang employees, I've updated how I think the term "neutral" should be handled in responses lower in the discussion. I still stand by the majority of this proposal.) -PancakeIdentity (talk) 04:34, 20 May 2020 (UTC)


 * the "Friendly" and "Hostile" categories as they are simpler and as they arguably match the code more closely. I don't approve the "Animal" category you suggested as it causes problems, as you said, with villagers, but also with Polar Bears and Hoglins (both animals and hostile). By the way, we should also think of a new definition for the new "Hostile mob" category. It isn't that simple : why are zombie pigmen hostile mobs and not wolfs or dolphins ? I have a (pretty quirky) definition for it, but I'll post it only if you're interested. Sagessylu (talk) 12:21, 21 May 2020 (UTC)


 * Support following the sound category names. FVbico (talk) 12:24, 21 May 2020 (UTC)


 * Support disbanding the "neutral" category. I compared mobs that implement "Enemy" in the code, are included in the Monster Hunter advancements, or specify a hostile sound category; they are mostly the same except that the advancement doesn't include giants or Illusioners (as might be expected), and hostile sound category includes killer rabbits but not slimes or magma cubes. "Monster" would be clearer than "hostile" since mobs like bees and polar bears are not included in any of these, despite having hostile behavior. – Sonicwave talk  18:42, 22 May 2020 (UTC)


 * Yeah, "Friendly" and "Monster" seem the best way to go imo. I also think that, in case of discrepancies, we should prioritize what makes most sense (slimes would be "monsters", etc.) -PancakeIdentity (talk) 20:54, 22 May 2020 (UTC)


 * using categories like "Friendly" and "Monster," I think terms like passive, neutral, and hostile could still be useful as a short description of a mob's behavior in info boxes. The behavior should be more thoroughly explained in the behavior section. For example, as noted on wolf, wild wolves are neutral and tamed wolves are passive. To give a general idea of panda, it could possibly say Neutral (Aggressive Pandas), Mostly Passive (Other Pandas). Without the terms being tied to categories, it is alright for them to be somewhat ambiguous so long as they are properly explained in the behavior section. jahunsbe (talk) 02:14, 24 May 2020 (UTC)


 * Yeah, I'd support keeping the ideas of this terminology around, even if it's not how we group mobs. I would still say we should figure out a better name for "neutral" though. -PancakeIdentity (talk) 02:23, 25 May 2020 (UTC)


 * Maybe we could say "Defensive" instead of "Neutral"? Makes more sense in my opinion, what do you think? Sagessylu (talk) 14:35, 26 May 2020 (UTC)
 * They aren't defensive though, they attack under conditions, not just when attacked. Endermen when looked at, Spiders in darkness, Piglins if you don't wear gold, etc. FVbico (talk) 14:43, 26 May 2020 (UTC)
 * I mean, neutral mobs are mainly quite defensive, and Endermen feel provoked when you look at them, so in this sense we can say they are defensive, Spiders could be "Hostile/Defensive" and Piglins "Mostly Hostile"? I feel like it's quite hard to keep mobs in static categories anyway. Sagessylu (talk) 09:58, 29 May 2020 (UTC)


 * I'd support defensive for things that only attack out of defense. Other than that, I'm not sure we need a set term for it? Hostile describes most of the mobs fairly well, we can describe that they are not always aggrsive in their description areas. -PancakeIdentity (talk) 04:13, 27 May 2020 (UTC)


 * I think we could also use the term "Aggressive" to describe mobs which become hostile and repeatedly attack (or attempt to kill) when provoked. There would need to be an exception to the term Defensive for mobs which are not "Aggressive" but can be provoked even if the player doesn't attack (Pufferfish).
 * Hostile - Seeks out and attempts to kill the player. Example: Creeper
 * Passive - Never attacks the player. Example: Sheep
 * Aggressive - Becomes hostile when provoked. Example: Spider (light > 11)
 * Defensive - Provoked only by getting attacked. Example: Llama
 * OR Not Aggressive yet otherwise provoke-able. Example: Pufferfish
 * Using this terminology, llamas and pufferfish would be Defensive, spiders Aggressively Defensive, and endermen Aggressive. The term "Group" could also be used to describe mobs which are provoked when group members are. For example, Zombie Pigmen would be Aggressively Group Defensive. All of this terminology might make things too confusing though, so I don't know. It would definitely need to be explained in the behavior section. jahunsbe (talk) 15:09, 30 May 2020 (UTC)


 * Like I said above, I'm not sure we really set terms for all these behaviors. I feel it'd get too confusing too quickly. -PancakeIdentity (talk) 18:56, 30 May 2020 (UTC)


 * any change. They're officially known as "neutral" by Mojang, and Hostile and Passive work fine with clarification. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  06:53, 5 June 2020 (UTC)


 * So, would dolphins, iron golems, llamas, and pandas be passive and spiders, cave spiders, and piglins be hostile? -PancakeIdentity (talk) 18:03, 5 June 2020 (UTC)
 * Passive and Hostile should have an implied "always" before them, and Neutral should be the "everything else" term. So, e.g. iron golems would have an overall classification of "Neutral" but with a specific clarification of "Passive when player-made and Neutral when natural". Spiders likewise. Piglins are neutral as "not wearing gold" ≈ "provoking" and llamas are neutral as they are defensive. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  00:40, 30 July 2020 (UTC)


 * , but keeping it to a single term.
 * I acknowledge that Henrik's attention to the anger management code is noteworthy, and indicates that Mojang considers the Neutral mobs in a single category, but I do think the wiki can push against old (bad) terminology and just use a new word, and people will start using it. I believe we on the wiki were early adopters / pushers / popularizers of the term "bedrock edition", and I think we were right to create a term then ... and now.
 * What that term would be ... I don't know if Aggressive and Defensive capture it ... Provokable? Volatile?  Excitable? – Sealbudsman talk | contribs 16:14, 22 June 2020 (UTC)


 * Provokable describes the actual behavior about as cleanly as you can in a simple, single word descriptor. I like that. Also, like I said below, I don't think recognizing this "neutral" classification is irreconcilable with using the in-game groups of Friendly and Monster (even if we don't actually use the word neutral). -PancakeIdentity (talk) 23:05, 15 July 2020 (UTC)


 * Having thought about it a bit, I think it's possible to rework things into friendly/monster and have a "neutral" category in the mob categories section. This allows us to document mob groups as the game sees them while still recognizing the "neutral" status used by Mojangsters and (sort of) the game code. -PancakeIdentity (talk) 22:59, 15 July 2020 (UTC)


 * In my opinion an "Animal", "(Non-Player) Character" and "Monster" could work. Although I'm hesitant about calling anything "Monster" specifically. In my opinion something is a monster if no one feels affectionate about them, as in, disassociative to their individuality. However in that sense I find the word insensitive and insulting. I would personally categorize this stuff to behaviour, such as "attacks player near babies", "attacks player once provoked/looked at", "never attacks player", etc. Because it would be more concise and always be accurate. More complicated however, because that way a mob can belong to multiple categories. So I do think grouping by type of creature like this is better, specially better than by their current type of hostility. Because most important of all, against what is currently done, hostility is not consistent between mobs. We need to improve this. A mob's hostility can change over the course of certain player actions, and sometimes depends on situation and other factors. It's not anything a mob is always permanently considered to "have" or "be".
 * Using terms such as "friendly" and "monster" (specially without further context when there is further distinction needed), although might be more true to what the game defines them as, it isn't necessarily true and accurate for every player. It isn't concise. It doesn't always meet the expectations of what someone might think it means and it is important in my opinion, that we honour that. Saying it like "polar bears are friendlies", can have the effect of upsetting someone when they're killed just because there was a baby around and they didn't know they would defend them. It does happen to newer players, and this sort of "ignorance" to behaviour violates what the wiki is intended to do; documenting the game "as it is". If people can get confused so significantly by the way things are classified, the wiki's not serving that purpose. I'm not necessarily voting for any suggestion, I just wanted to put my opinion out there, because I'm not active in discussions anymore for my own reasons (may come back later) and I specifically had thoughts I found relevant. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 23:40, 15 July 2020 (UTC)


 * This seems like a far too philosophical argument for this topic tbh -PancakeIdentity (talk) 23:06, 29 July 2020 (UTC)


 * I honestly don't think we should categorize mob behaviors with just one or two words. Especially since basically every new mob that gets added, get more and more complicated behaviors than the previous one, I don't think they can simply be summarized as just 'Monster', for instance. — Thomanski | t | c | 09:06, 17 July 2020 (UTC)


 * Some rambling and unrelated thoughts:


 * I'm in favor of the friendly/monster classification, but I also see the point of passive/neutral/hostile classification. The latter is based on the mobs' in-game behaviour, which could be, but isn't, clearly defined. However, the solution should above all else follow the technicalities of the game, and pillagers should be neutral.


 * Hostility also needs to be defined, as well as attacking. Now, I don't give too much value to intuition where logic can be used, but I think we can unanimously agree that ghasts are hostile. So let's assume a hypothetical mob that is identical to ghast, except that its distance of perception is slightly more than its attack distance. Would it, due to that minor difference, not be hostile? It does not change its movement because of the player, and thus would not chase the player, nor could it attack. In fact, its behaviour would be identical to ghast, except that it would look at the player from a bit further away. With no relevant difference in behaviour, this mob and ghast should be classified the same way, which means the definition should be such that it classifies this hypothetical mob as hostile. The solution would be that hostility towards the player means attacking the player, provided it is possible.


 * Now, for pufferfish, it is passive, neutral, or hostile. If it is not hostile when it damages the player, it is passive, whereas if it is hostile when it damages the player, either 1) it is hostile - it attacks when it can, and it can only do so when the player gets close enough to it; or, 2) ghasts are neutral, and coincidentally have no situations in practice where they are passive.


 * There have also been opinions voiced that passive mobs can't/won't deal damage to the player, or that friendly mobs don't attack the player. This, however, is untrue, as these claims do not follow from any definitions, and are without basis. Such misunderstandings should be prevented with disclaimers within articles, rather than by shaping the classifications around them. Blue Banana whotookthisname (talk) 23:56, 29 July 2020 (UTC)

Should unreleased versions be documented on the wiki?
There's been a very long discussion that actually got quite heated, on the Discord server, about the question; should versions that are unreleased be documented on the wiki? Because this decision seems clearly controversial and the Discord is generally not the place to make definite decisions, I figured I'd bring this to the wiki since no one else has done so. I personally haven't made up my opinion on this (yet).--Madminecrafter12 (Talk to me 02:45, 13 June 2020 (UTC)
 * Reposting and reformatting my statement from Discord:
 * Some Minecraft versions have never been intentionally released, but their existence was made available by accessing internal data for a software distribution service.
 * Stating the wiki's purpose, MCW is a wiki on Minecraft and all related topics, striving to be as complete and accurate as possible.
 * When we say some completeness (i. e. some information that is accurate and related to Minecraft) is inappropriate, it's because:
 * this information is unacceptable to host on MCW, such as due to breach of law or contract (copyright infringement, non-public info, etc.)
 * hosting this information will create a precedent for other similar information, which cannot be managed (e. g. galleries of custom builds with no limits on how many there can be)
 * this information is not a good fit for MCW, either for technical or community reasons, and should be hosted on another wiki or another website entirely (mods and non-English pages have their own wikis; videos are too large for the wiki and are hosted on YouTube; etc.)
 * (if I missed a point, please inform me)
 * Non-public versions like the one found aren't `2` (there aren't an unbounded number of them) or `3` (hardly needs an external resource), but may be `1` if the access to the version list data, and its disclosure, is somehow illegal.
 * I'm not sure this is the case, I can see how it could be a breach of the Terms of Use for that software distribution service, but for it to be _illegal_, it would have to be more than that, I guess? --AttemptToCallNil (report bug, view backtrace) 02:47, 13 June 2020 (UTC)
 * , of course. The wiki should strive (and is striving) towards having complete documentation on the developmental history of the game. And that includes unreleased versions. We've had pre-Classic on the wiki for years without issue, and most of those did not advance past compilation. Unreleased versions in amongst release versions should not, however, be listed in infobox navigation or on their parent² pages, and should only be listed in the navbox and on Version history in italics. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  02:52, 13 June 2020 (UTC)


 * with contingencies. I'll re-state what I said on discord:
 * Changelogs on them should be as complete as possible. Of course, these would have to be done with testing, but testing being required is hardly an argument for not documenting something. I'd be opposed to distributing versions we don't have access to, but I don't think we have Bedrock versions archived on the wiki in general anyway. These changelogs should not impact the changelogs of released betas. For example: Beta A is released, Beta B is not, and Beta C is. The page for Beta C would include everything changed in Beta B (possibly with a note that they were changed in Beta B?).
 * I'd also say, if we get word that this could get us in legal trouble, I'd say remove them right away. It's worth noting that this is different than say pre-classic versions. First off, the legal protections surrounding Java and Bedrock seem to be different (I may be wrong about this), but definitely, at the time, everything was much looser. Second, we have freely available evidence of those versions from the chat logs linked in references, while the only proof for the existence of these betas and the changes within them are obtained through a much more "gray area" method.
 * TL;DR: Support, but lets be careful about it and not let it impact how we document actually released betas. -PancakeIdentity (talk) 03:45, 13 June 2020 (UTC)
 * Addendum with some thoughts I missed: We should treat them like dev builds for the next released beta. The changelog for the released beta is a compilation of all changes from the previous unreleased ones, the parent should be set to the next released beta, etc. Also worth noting that there's multiple legal angles to look at this from, both Minecraft/Mojang's TOS/EULA and those of the Google Play Store, which is where most of the modern unreleased betas have been pulled from afaik. -PancakeIdentity (talk) 05:32, 13 June 2020 (UTC)
 * For my case, I posted a leaked changelog of an unknown beta back in 2018. It's not really leaked since the changelog is from Minecraft.net but for some reason the developers pushed back the release date. Here's the leaked changelog. I'm supportive of if the changelog is made public or if it doesn't violate any of the laws.-- skylord_wars (talk) 05:00, 13 June 2020 (UTC)


 * -- yes, but only if it's reasonable. The discussion emerged because there are apparently some old Bedrock betas that were uploaded to the Play store, but actually never made available to the public. As far as I understand it, you need a third-party app in order to actually be able to access these versions. Often, the only thing known about these versions is that they exist; not much else is known, since Mojang obviously usually doesn't release changelogs for unreleased versions. As such in order to get a complete changelog, the changes would need to be (re)discovered manually, which is very time-consuming and in my opinion not worth it. Additionally I don't think having a lot of articles about unreleased versions that are basically empty and just say that the version exists is desirable. Apart from that, there's the issue of how released versions' changelogs should be handled: If a released version is after an unreleased version and the changelog of the unreleased version is known, should the contents of the unreleased version's changelog be removed from the regular version's changelog? I don't think so. I don't think that unreleased versions shouldn't be documented at all, but they shouldn't be treated the same as released versions and get an own page (except if they're notable enough or there's enough content to warrant an own page). Proposed solutions to this are having these versions in a Trivia section somewhere (e.g. in the next released version's article), in an extra section in the version history page, or an extra single article to specifically document unreleased versions. Lastly, I want to point out that there are a huge amount of unreleased versions of Minecraft, for instance every git commit could be considered its own version. Documenting those would just be worthless. But these versions are not known to the public anyway; there's only a small number of unreleased versions altogether that made it to the public at some point. But there's a point where useful information ends and unnecessary clutter starts. | violine1101(Talk) 07:16, 13 June 2020 (UTC)


 * The difference is that these were packaged and ready to go, just not pushed out to users. They have distinct identities and version numbers (they're why betas sometimes skip versions). Comparing it to git commits seems like a bit of a . -PancakeIdentity (talk) 08:30, 13 June 2020 (UTC)
 * "which is very time-consuming and in my opinion not worth it.": Well, you don't have to be the one to do this; "should the contents of the unreleased version's changelog be removed from the regular version's changelog?": No, they should be treated as dev builds of the dev builds, and have their changelogs detailed on the release version two; "every git commit could be considered its own version.": no, not at all, that's not a compiled build, these bedrock versions have been compiled, their version number bumped, and actually uploaded to the store, so they obviously have some amount of completeness to them. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  19:24, 13 June 2020 (UTC)


 * I guess this seems to be something people want, but:
 * Now having taken a look at the pages for unreleased Bedrock beta pages that do already exist, they seem to turn out the exact same way, I'd imagined these pages to turn out: They are currently still blank and already exist for quite a few weeks. I do know, that there are a lot of pages already (e.g. older versions for Java Edition and Launcher versions) that are blank but there's evidence that they were released to the public and therefore they should of course be documented.
 * But even if we do test things out and figure out the additions, changes and bug fixes that have been made in those versions, the readers would then turn to the next (released) beta and would see info that has already been mentioned on the previous (unreleased) beta page. And finding out the differences between those two betas by comparing both pages would probably be annoying and should be avoided. I actually like the idea of having that disclaimer and the categories but those pages should differ even further in my opinion and should be as different as possible, in terms of how things are documented. Elite hog (talk) 10:41, 13 June 2020 (UTC)
 * "the readers would then turn to the next (released) beta and would see info that has already been mentioned on the previous (unreleased) beta page." unreleased versions and release versions would not go together in the infobox navigation. It's a similar situation to e.g. 16w50a vs 1.11.1. "They are currently still blank and already exist for quite a few weeks.: Yes, I'll have to ask the omni guys what's changed in the version, I just haven't got round to that yet. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  19:24, 13 June 2020 (UTC)


 * , but with notice, that version was never released. --Treeislife2 (talk) 06:42, 15 June 2020 (UTC)


 * , per above reasons. — Thomanski | t | c | 14:33, 22 June 2020 (UTC)


 * for reasons already said. – Sealbudsman talk | contribs 15:59, 22 June 2020 (UTC)


 * nothing to add---HumiebeeDiscuss anything with me Look at my edits 23:31, 12 August 2020 (UTC)


 * Blockofnetherite Talk Contributions 23:49, 18 August 2020 (UTC)

Bedrock Technical Wiki corporation
A couple of days ago a couple of skilled Minecraft Bedrock edition code diggers and technical players decided to setup a discord for a bedrock (technical) wiki. The reason behind this is because tons of information on the wiki for bedrock isn’t always right because there hasn’t been too much of research into it. There are also tons of new terms that most people haven’t heard about it.

What we want to do is try to come in touch with you guys about how we could set this wiki up. We already starting setting up articles in a discord server, but we want to expand it to this site or a new one. And we know loads of people visit this site for various reasons, so thats why we wanted to contact you.

What we want to do is to simplify various (Bedrock) articles. The problem is that our corrections constant change because other people edit them with wrong information and then we have to correct it again (starting a never ending circle) Also we want to add new articles about bedrock exclusive features (such as soft inversion and more). We already know that we can edit this on our own but we want to talk with you (The administrators) more frequently about why bedrock has things in different ways and want to confirm that trough the code digging that has been done.

We hope that this will help people in the future who don’t know a lot about the game (on bedrock edition)

We think we gave you enough information, but if you have any questions or other things you want to talk about, please tell us (contact ItsRichHeart in discord if needed)

Kind Regards,

Bedrock Technical Wiki Team ItsRichHeart (talk) 16:08, 12 August 2020 (UTC)


 * So is it going to be a separate wiki or merged into this wiki?, I also have bedrock but i dont have discord ---HumiebeeDiscuss anything with me Look at my edits 16:10, 12 August 2020 (UTC)


 * We will be releasing articles on our discord but will add the information from these articles as simplified as possible on this wiki. ItsRichHeart (talk) 21:34, 12 August 2020 (UTC)
 * Oh 😑---HumiebeeDiscuss anything with me Look at my edits 21:37, 12 August 2020 (UTC)
 * If there's a problem with bedrock content on the wiki, the solution is to fix it when possible, not move it off wiki as that would just exacerbate the problem. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  00:09, 15 August 2020 (UTC)
 * This. Splitting the community, in terms of both editors and readers, is not helpful. Do what you need to allow Bedrock to be documented fully on here. -PancakeIdentity (talk) 09:00, 16 August 2020 (UTC)


 * I think setting up a new wiki for unique technichal things in BE for only developers and technology players is not bad. However, we should also work together to make this wiki better, especially in the field of non-technological game behaviors. If you find false info here, just fix it. Note it is not all of editors here that are ignorant of the bedrock edition. Just edit it as long as you like, and we'll help defend against vandalism.--Chixvv (talk) 16:04, 16 August 2020 (UTC)


 * I propose that the information be on this wiki whenever possible. However, you can consolidate the information on discord to help us port it here. The BlobsPaper.png 19:22, 17 August 2020 (UTC)

Change formatting for hatnotes
Currently, there is excessive padding around hatnotes. A proposed change of mine would condense the spacing, making the hatnotes more similar to that of Wikipedia's. The following should be added to the common.css file: to replace Also the contents of Hatnote/sandbox should replace the contents of Hatnote, which currently has hardcoded css values.

Fadyblok240 (talk) 05:26, 26 September 2020 (UTC)
 * What's the benefit of putting on these stylesheets as opposed to raw inline styles? The latter seems like it would be way easier to keep updated. <b style="border:1px solid #10a"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b></b>  02:12, 27 September 2020 (UTC)
 * Here's the thing: the current template forces italics, and italic markup cannot cancel it. Using the new stylesheets would allow italics within italics (i.e. no italics). Also, when the new styles get implemented, we don't have to worry much about changing them for a very long time. Fadyblok240 (talk) 04:53, 27 September 2020 (UTC)
 * [[File:Hatnote comparision.png]]
 * Okay, done. <b style="border:1px solid #10a"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b></b>  19:14, 30 September 2020 (UTC)