Minecraft Wiki talk:Community portal

From Minecraft Wiki
Jump to: navigation, search
Minecraft Wiki Community portal discussion page

This is the community's main discussion page.

Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the feedback site.
This page is for community discussion; generally, wiki issue reports should go on the Admin's noticeboard and discussions about a single page do not belong here.

Archive basics |archive = /Archive %(counter)d |counter = 31


Contents

The problem with subpages[edit]

I think subpages are overused on this wiki. Wikipedia has disabled subpages in the main namespace and some others. Subpages cannot be accessed by clicking on the "Random page" link and only support one hierarchy while they may be more. I'm not saying to get rid of all subpages in the content namespaces, but to discourage some uses. Here's what I think when subpages should and should not be used:
Acceptable uses:

  • Anything that Wikipedia accepts as subpages—User subpages, template documentation, etc. It is laughable to even think about removing these subpages from the Minecraft wiki.
  • Mod pages (until all mod pages are moved to FTB)—The Minecraft Wiki only concerns the vanilla game. Although some of these pages are full articles, we don't want readers to end up on pages about specific mods.

Disallowed uses:

  • Writing about a feature of the same name for a different edition—These pages are articles and there are better ways to disambiguate the name than making it look like one article forms part of another when it does not.
  • Category subpages—Categories were created to replace mainspace subpages on Wikipedia. Using subpages for categories is pointless and sometimes the names get ridiculously long.
  • Mechanics pages—These pages are also articles, and in the past there was a dispute on whether these pages should be named "Mechanics/X" or "X/Mechanics".
  • Tutorials subpages—These pages are less like encyclopedia articles, but they still contain helpful instructional material so they should be moved to a new namespace.
  • File subpages—I don't know whether there are such pages or even if the subpage feature is enabled, but it should be disabled because some filenames create accidental subpages and hierarchy among files is bad.

Unsure:

  • Previous versions of features—These articles are useful to a historical perspective, but completely irrelevant in the latest version of the game.
  • Command subpages—These pages are legitimate articles, but pages starting with "/" cause technical problems.
  • Schematic pages—They are merely pseudo-images that are transcluded, but sometimes they may be used on more than one page so maybe they should be converted to templates.

There are more uses of subpages on this wiki but I am still unsure about whether they are acceptable. Fadyblok240 (talk) 21:23, 23 August 2020 (UTC)

My opinion. I'm going to list my strongest support on top and strongest oppose on the bottom (of what subpages should be allowed)
  1. User subpages  Definitely should be allowed.
  2. Minecraft Wiki namespace subpages  Definitely should be allowed.
  3. Archive subpages  Definitely should be allowed.
  4. Documentation  Definitely should be allowed (template)
  5. Guides, Commands and Official subpages  Should be allowed.
  6. Previous versions of features  Should be allowed.
  7. Development versions subpages  Should be allowed (ex:Java Edition 1.0.0/Development versions)
  8. Subpages that make sense but are too technical to be in a main article (Ex:/DV, /Structure, Category Data Pages, or others).
  9. Mod subpages  Should be allowed (as they still haven't been completely exported yet)
  10. Writing about a feature of the same name for a different edition  Should maybe be allowed as it makes sense but the argument also makes sense so i'm sorta split?
  11. Mechanics pages should be  Moved to another subpage/possible tutorial namespace
  12. Tutorials subpage should be  Moved to another namespace
  13. Category subpages should be  Should not be allowed like theres such thing as subcategories (Ex Objects requiring isometric renders/Re-render)

1 more thing, what do you mean by previous versions of features? are you talking about Java Edition 1.13/Flattening? ---Humiebee Discuss anything with me Look at my edits 22:59, 23 August 2020 (UTC)

Kinda, I meant pages like "X/Before <version>". which in my opinion I am still not sure about. Fadyblok240 (talk) 17:21, 24 August 2020 (UTC)
I support keeping those as let's take the Far lands, old farlands sounds so wrong and also, merging the Far Lands/Java Edition and Far Lands will create a lot of confusion, thats why it was split---Humiebee Discuss anything with me Look at my edits 17:46, 24 August 2020 (UTC)
What does this (Writing about a feature of the same name for a different edition) mean? like I don't know any example and I'm pretty sure there's no subpage, can you give an example?---Humiebee Discuss anything with me Look at my edits 17:48, 24 August 2020 (UTC)
A page like Achievements/Java Edition. I prefer moving pages like these to "<edition> X" (i.e. Java Edition Achievements and Java Edition Far Lands). I also support moving the current Far Lands page and moving it to Bedrock Edition Far Lands and leaving a disambiguation page behind. –Preceding unsigned comment was added by Fadyblok240 (talkcontribs) at 17:58, 24 August 2020 (UTC). Please sign your posts with ~~~~
I don't think moving "X/Edition" to "Edition X" is a good idea; the former provides a semantic relation that is more visible to search engines. I'm not sure what "category subpages" are or whether they are used on MCW. As for mechanics, "X/Mechanics" has the same consideration of semantic relation as with editions. --AttemptToCallNil (report bug, view backtrace) 18:01, 24 August 2020 (UTC)
There are already articles using the "Edition X" format, e.g. Java Edition mentioned features. Also, there is such a thing as category subpages on this wiki. I have reworked Template:Needs render to avoid category subpages, but Template:Render uses dozens of category subpages (e.g. Category:Objects requiring isometric renders/Historical features/Stems/Invalid states) which is too much for me to handle. Fadyblok240 (talk) 18:36, 24 August 2020 (UTC)
Above is 1 such example---Humiebee Discuss anything with me Look at my edits 18:40, 24 August 2020 (UTC)
Oh, those? Yeah, I agree, they're not the best idea. --AttemptToCallNil (report bug, view backtrace) 18:43, 24 August 2020 (UTC)
Mixed opinion on this. Subpages automatically link back to their parent pages at the top and allows easy access to them; this is especially useful on mobile where neither categories nor navbox templates show up. With that in mind, I think it makes sense to keep at least the following as subpages (and probably other scenarios that I missed):
However, I would support template-like subpages (such as Renewable resource/row) to the template namespace, as well as cleaning up category subpages. I would also support moving "Mechanics/Redstone" to "Redstone mechanics" since the mechanics page itself is a redirect to a different page. Regarding some of the suggestions by Humiebee, I am neutral on moving Tutorials pages to a separate namespace (assuming that it's searchable like the MCD and MCE namespaces), but disagree with making a namespace for "X/Mechanics" pages as they are similar to regular articles, just more technical. –Sonicwave talk 20:08, 24 August 2020 (UTC)
Ok, I agree on pretty much your whole statement above including the gallery subpage idea but but I think the Mechanics should possibly go into Tutorials:Mechanics/whatever.---Humiebee Discuss anything with me Look at my edits 20:15, 24 August 2020 (UTC)
I dont know, if mechanics are (not) tutorials, but I have no problem with that. So I am  Supporting this idea.–Preceding unsigned comment was added by TreeIsLife (talkcontribs) at 20:50, 24 August 2020 (UTC). Please sign your posts with ~~~~
I mean it is teaching you the mechanics of whatever so that  Would make sense.---Humiebee Discuss anything with me Look at my edits 22:47, 24 August 2020 (UTC)
I don't think you make strong enough case for not using subpages, especially so for mechanics and tutorials pages. For example, you brought up the past dispute regarding the names of mechanics pages, but the fact that the dispute was had and solved, and the community arrived at a solution, is an argument in favour of keeping the current page hierarchy, if anything. I'm fine with the other suggestions but mechanics and tutorials subpages work fine without issues. Blue Banana whotookthisname (talk) 07:16, 25 August 2020 (UTC)
Many of the Tutorials subpages are ignored by the Minecraft Wiki's most active editors. Special:Random The "Random page" link never links to subpages. If the tutorials were moved to a new content namespace, they wouldn't be subpages and therefore be accessible from the Random page link and more likely for editors to notice. Fadyblok240 (talk) 02:09, 27 August 2020 (UTC)
Fadyblok240Special:Random does not link to anything besides mainspace so that's.......---Humiebee Discuss anything with me Look at my edits 02:24, 27 August 2020 (UTC)
The "Random page" link does link to other namespaces, namely Minecraft Earth and Minecraft Dungeons. If a Tutorials namespace were created, the wiki manager could classify it as a content namespace. Ironically, Special:Random also links to subpages, although the "Random page" link does not. I tested this after the migration to UCP and I still couldn't get to a subpage by using the "Random page" link on the sidebar. Fadyblok240 (talk) 02:40, 27 August 2020 (UTC)
This is because the Random page link in the sidebar uses Special:RandomRootpage instead. – Unavailablehoax (talk) 21:55, 15 October 2020 (UTC)
It was probably configured like that to bypass non-article pages that are subpages of articles, but there are also legitimate articles that are subpages. Maybe we should move article subpages to root pages or allow the random page link to access subpages and move non-article subpages of articles to other namespaces. Fadyblok240 (talk) 20:20, 7 November 2020 (UTC)
Ditto Sonicwave and Humiebee for the most part, don't have a whole lot to add. I'd also add history-esque subpages to the list of "acceptable" subpages, there's not really a better place for most of these and it keeps them tied to their parent pages really nicely. While yes the current version of a main article body should always reflect the current version (and only the current version), the wiki should still hold all the information on old versions of features. Usually a good history section can get the job done, but oftentimes the changes are too vast and/or complicated to be fully represented there (for example, loot table reworks, old villagers, etc). -PancakeIdentity (talk) 17:41, 27 August 2020 (UTC)
See Minecraft Wiki talk:Community portal/Archive 26#Should we move all Tutorials pages to a own namespace? for further info about moving tutorials to a new namespace. Fadyblok240 (talk) 00:22, 18 September 2020 (UTC)
Should you open up a new discussion about this? I would like a new tutorials namespace, supporing Psl85 and User-12316399 ideas.---Humiebee Discuss anything with me Look at my edits 01:19, 18 September 2020 (UTC)
Here is a quote

If we move the pages to a new namespace, we could make in the LocalSettings.php so these could show up by default in the search bar.

User:Psl85

If we move the pages to a new namespace, we could make in the LocalSettings.php so these could show up by default in the search bar.
User:Psl85

---Humiebee Discuss anything with me Look at my edits 01:25, 18 September 2020 (UTC)
And Another one

The aim of the mainspace is for information on the game (and, by extension, Mojang) to be documented. Tutorials do not fall within the scope of what the mainspace should document, and as such should not be kept in the same namespace. It's also worth noting that other Gamepedia wikis such as the Terraria Wiki already have namespaces dedicated to tutorials.

User-12316399

The aim of the mainspace is for information on the game (and, by extension, Mojang) to be documented. Tutorials do not fall within the scope of what the mainspace should document, and as such should not be kept in the same namespace. It's also worth noting that other Gamepedia wikis such as the Terraria Wiki already have namespaces dedicated to tutorials.
User-12316399

All in all, the opposes are not very convincing but the supports are, should I reopej the discussion?---Humiebee Discuss anything with me Look at my edits 01:27, 18 September 2020 (UTC)

Bot noticeboard?[edit]

I know this sounds really dumb but I kind of want like a page, similar to the Minecraft Wiki:Admin noticeboard that people can post on that requests something that a bot would do such as fixing links due to UCP. Maybe is should be called something else but idk what. Link????Minecraft Wiki:Bot noticeboard---Humiebee Discuss anything with me Look at my edits 20:29, 26 August 2020 (UTC)

I'm kind of skeptical. The Russian wiki has made one long ago. Now it's unused. Completely. The last 3 edits were in 2016, 2017, and one IP request about a month ago. --AttemptToCallNil (report bug, view backtrace) 20:40, 26 August 2020 (UTC)
Is there a link?---Humiebee Discuss anything with me Look at my edits 20:40, 26 August 2020 (UTC)
ru:MCW:Запросы к ботоводам. --AttemptToCallNil (report bug, view backtrace) 21:07, 26 August 2020 (UTC)
Oh... ever since 2016, it's been unused??---Humiebee Discuss anything with me Look at my edits 21:17, 26 August 2020 (UTC)
It seemed to be pretty active at 2014 but for some reason, it completely died down..---Humiebee Discuss anything with me Look at my edits 21:18, 26 August 2020 (UTC)
Thanks!---Humiebee Discuss anything with me Look at my edits 21:16, 26 August 2020 (UTC)
 Weak support Wikipedia has a similar page named Wikipedia:WP:Bot requests but on the Minecraft Wiki there are not that many bots, so maybe the Bot Noticeboard doesn't warrant its own page, but should be a section of subpage of the Admin Noticeboard or linked directly on the sidebar. Fadyblok240 (talk) 20:46, 26 August 2020 (UTC)
I don't think it should be in the sidebar but I do  Agree on it to be a subpage/subsection of the admin noticeboard.---Humiebee Discuss anything with me Look at my edits 20:49, 26 August 2020 (UTC)
I would  Support a small section dedicated for this. Although I feel like the community portal would a better place for this than the admin noticeboard, as bot edits aren't necessarily for admins. — Thomanski | t | c | 21:55, 26 August 2020 (UTC)
Though bots rights are only given to bots of trusted users so I have some mixed opinions---Humiebee Discuss anything with me Look at my edits 21:56, 26 August 2020 (UTC)
It's not super hard to be considered a trusted user if you're somewhat active and consistently constructive. Also, bots don't really have many different rights than normal user accounts, it's more to do with reducing spam and stuff. -PancakeIdentity (talk) 21:53, 27 August 2020 (UTC)
 Weak oppose. Don't really see a need honestly. In my time here, I've only seen a few users ask for a bot to do something for them that they couldn't/didn't want to do themselves. And in these few instances, they were easily fulfilled through discord or this CP. -PancakeIdentity (talk) 17:34, 27 August 2020 (UTC)

Closing and merging projects[edit]

Well. Currently, we have many, many, many active Wiki Projects in Minecraft Wiki:Projects. But many of them are duplicate, non-useful and others, which idk, how someone could create it.

So here's complete list of active projects, excluding language ones

  1. Welcome
  2. Screenshot Minecraft Versions
  3. Beginner's Guide Rewrite
  4. Minecraft in schools
  5. Screenshot Fixing
  6. Rewrite for Style
  7. Version cleanup
  8. Tutorials Modernization
  9. Userboxes standardization
  10. Redirect cleanup
  11. Renaming
  12. Cleanup open tags
  13. Capitalization Fixing
  14. Individual Biome Pages
  15. Upload Missing Wiki Sounds
  16. Refactoring edition specific information
  17. Minecraft Earth Wiki
  18. Texture Documentation Cleanup
  19. Gallery organization
  20. Wiki videos
  21. Minecraft: Story Mode Mobs

21 pages, with some of them could be deleted.

So i start with my ideas

  1. Fandom has automatic Messages from some MediaWiki page. Also i don't see anybody adding {{Welcome}} template, so I consider  Closing it.
  2. Should be merged with Screenshot fixing
  3.  Keep it
  4. Better merging with Minecraft in Education
  5. Should be merged with Screenshot Minecraft Versions
  6.  Keep it but, compleate it.
  7.  Keep it
  8. Ok,  Keep it
  9. Keep it
  10. No activity, it's in dead point from it's creation, consider removing it
  11. It is compleated, we should archive that
  12. Keeping it
  13. Keeping it
  14. Happy to see it will be done (one time), so keep it
  15. It is compleated, so archive
  16. Keeping longer for discuss
  17. Archive
  18. Keep
  19. This is not most useful project, so discussion
  20. Keep that
  21. Keep it, but i notice that's outdated.

--TreeIsLife (talk) 20:54, 26 August 2020 (UTC)

I have some opinions as well.
  1.  Somewhat Agree, Madminecrafter12 is the only user to even remotely work on it, completly unused though the template should still remain as the template, not the project is still used.
  2.  Agree
  3.  Agree
  4.  Agree
  5.  Agree
  6.  Merge, would be better to merge with capitalization fixing.
  7.  Agree
  8.  Agree
  9.  Agree
  10.  Disagree, don't bomb it, improve it.
  11.  Agree
  12.  Agree
  13.  Merge with Rewrite for Style
  14.  Agree
  15.  Agree
  16.  Agree
  17.  Agree
  18.  Agree
  19.  Don't really agree/disagree there's still a discussion with like 90% support and so more discussion is not really needed
  20.  Agree
  21.  Disagree Story mode is discontinued so since less people have it, I don't think it's worth the effort so  Bomb it---Humiebee Discuss anything with me Look at my edits 21:15, 26 August 2020 (UTC)
I think Rewrite for Style and Capitalization Fixing should be merged. Fadyblok240 (talk) 16:57, 27 August 2020 (UTC)
Mostly agree with your conclusions. At this point, I'm not sure we need #16 anymore, we only deal with two editions. We're not perfect in how we document them yet but I'm not sure if need a project, especially as it never really had much discussion on what to do. Also, just wanted to check, the Earth Wiki project has no relevance now that it has its own namespace, correct? -PancakeIdentity (talk) 17:32, 27 August 2020 (UTC)
The Minecraft Earth Wiki project is still relevant, as many of the articles in that wiki's namespace are stubs. Fadyblok240 (talk) 09:43, 31 August 2020 (UTC)
Also, we should reclassify some projects as semi-active, as the Minecraft Wiki is never complete. I have added a handy template called {{project status}} that categorizes projects by activity. The cleanup open tags project has turned into a white elephant project. Fadyblok240 (talk) 02:16, 19 September 2020 (UTC)

Documentation template revamp[edit]

Can somebody add links to "/sandbox" and "/testcases" subpages of templates to the Template:Documentation template? Fadyblok240 (talk) 19:08, 28 August 2020 (UTC)

Why? --TreeIsLife (talk) 22:39, 9 September 2020 (UTC)
I (along with Humiebee) have created several template sandboxes, but the documentation template does not recognize that they are template sandboxes and shows that they have no documentation; they appear in Category:Templates with no documentation instead of Category:Template sandboxes. Fadyblok240 (talk) 22:32, 26 September 2020 (UTC)
I don't see the need for those pages, they'd just become outdated and useless quickly. Just use the Template:Sandbox or your own user subpage instead.  Nixinova T  C   02:10, 27 September 2020 (UTC)
Template sandbox subpages would be useful for implementing major changes to high-risk templates with complex code or many parameters, where the "show preview" button alone would not guarantee whether the template is free of errors. Fadyblok240 (talk) 03:31, 5 October 2020 (UTC)
Okay, and what stops you from doing that on your own page or as a subpage on the sandbox, instead of creating additional maintenance for all templates? Very few templates are both high traffic enough that a major change is wiki breaking and get enough changes to warrant a permanent sandbox page. Likewise, {{BatchTest}} can handle doing test cases by comparing actual uses of the template to a sandboxed version.
I get that other wikis like Wikipedia do this, we don't have nearly the editing traffic they do so we don't have to adopt such complicated systems to make templates easy to maintain.KnightMiner · (t) 04:02, 5 October 2020 (UTC)

Move the Greek and Turkish Wiki back into translation projects[edit]

Why? Well for starters, Grid Files, the vast majority of them are used exclusively by the turkish wiki, also for both wiki, they have inactive admins. Another thing is that the amount of contributions to the wiki is miniscule. All I see is User:Fusion thermonucleaire, who is technically a bot, who puts interwiki links, User:Thomanski, who uploads files and thats pretty much it, for the Greek Wiki, it's main page is not even 100% translated and again, completely inactive.

A Summary

  1. Both have no active admin (Greek admin edits once a year, turkish admin hasn't edited since 2017)
  2. Both have no active real contributers (Greek wiki is slightly more active then Turkish, still, 80% of edits are by Fusion thermonucleaire)
  3. The Greek Wiki does not even have a 100% translated main page
  4. The Turkish wiki uses grid files and would ease the hassle of removing them.
  5. Those are my reasons
  6. ---Humiebee Discuss anything with me Look at my edits 17:39, 4 September 2020 (UTC)
 Comment, the reason why I upload files to those interwikis is to remove their dependency of the English wiki so we can finally remove the grid files here. I honestly don't know what to do with these wikis though. I don't think straight up deleting them is a good idea (for people that don't understand English), but on the other hand, these interwikis are REALLY outdated and inaccurate information is never a good thing for a wiki. — Thomanski | t | c | 21:45, 4 September 2020 (UTC)
Yeah, but like putting it into a translation project isn't harmful.---Humiebee Discuss anything with me Look at my edits 22:01, 4 September 2020 (UTC)
Hate to say it, but,  Strong support moving back to translation projects, as their state is actually harmfull to the readers (false/outdated info everywhere, and only partially translated) and only hinders changes on the english wiki due to the dependency. FVbico (talk) 22:04, 4 September 2020 (UTC)
I think it has to do with the Cyprus dispute Fadyblok240 (talk) 00:36, 5 September 2020 (UTC)
What does this have anything to do with the discussion?---Humiebee Discuss anything with me Look at my edits 00:42, 5 September 2020 (UTC)
 Weak oppose - why can't we just delete the untranslated pages instead, and add dedicated "this info is disgustingly outdated" templates to it instead? I wouldn't be against just getting rid of the wikis entirely either given the lack of interest. - User-12316399 (talk) 00:40, 5 September 2020 (UTC)
 Comment Yes, because whats the point about having a wiki page translated in multiple languages and the translated pages not even be finished and be forgotten about. I would consider it wiki clutter. So unless someone takes the time out of their day to rework all these translated pages, i think it's best to just axe em'. James Haydon (talk) 04:05, 5 September 2020 (UTC)
 Strong support doing something about these translations, the Greek wiki is just a complete import of the English one, issues pages and all (this should never be how translations are done), so everything is 3+ years outdated and clutters maintenance on this wiki. Add to that the fact that, since the wiki is in English, its a target for spammers who won't be reverted like they are here. E.g.: el:Alpha 1.2.4: there's no'one other than English wiki users to revert them. I can barely find many pages that have actually been translated apart from like a disambig, though there is el:Κρύσταλλος_του_Ender, el:Βιβλίο και Πένα, el:Κύβοι Διαμαντιού‏‎, el:Μπλοκ‏‎, but that's it. I'll just import all of the translated pages back here so they're safe if we feel like nuking that wiki.  Nixinova T  C   20:20, 5 September 2020 (UTC)
There: Special:Prefixindex/MCW:Projects/Greek translation/ – that's literally all the translated Greek pages. The wiki can be safely nuked now if that's decided.  Nixinova T  C   20:34, 5 September 2020 (UTC)
What about the turkish wiki?---Humiebee Discuss anything with me Look at my edits 22:53, 5 September 2020 (UTC)
 Strong support for the Greek wiki, mainly because so many pages are untranslated (which kinda defeats the purpose of a traduction).  Weak support for the Turkish wiki, mainly because of the inactivity. Sagessylu (discuss | edits) 17:37, 6 September 2020 (UTC)
Sagessylu, the Greek wiki is already translated.---Humiebee Discuss anything with me Look at my edits 20:55, 6 September 2020 (UTC)
 Done by Nixinova Greek wiki only---Humiebee Discuss anything with me Look at my edits 20:55, 6 September 2020 (UTC)
Well, not really, I've just moved a couple to this wiki, el: still exists.  Nixinova T  C   01:33, 7 September 2020 (UTC)
okay ill wait and see if someone will actually finish them now that there back in the works. James Haydon (talk) 00:50, 7 September 2020 (UTC)
I'm worried about the Ukrainian wiki potentially suffering from the same fate. It's also on the brink of dying out. There is one local user who appears to have edited in the last few days, but aside from that, there are predominantly edits by users from other wikis, notably Mak_and_Iv (a Russian admin) who is also an admin on the Ukrainian wiki. — BabylonAS *Happy Camper* 12:20, 30 September 2020 (UTC)
The thai wiki also only has like 1 contributer who keeps it alive and from anarchy as well but aside from that, it could die as well. – Preceding unsigned comment was added by Humiebee (talkcontribs) at 21:22, 3 November 2020 (UTC). Please sign your posts with ~~~~

Replace /ED, etc, subpages with DPL section transclusion[edit]

TIL that DPL can be used for labelled section transclusion: {{#dpl:title=Furnace|include=#Block entity}}. This can replace having /ED, /BE, etc subpages.  Nixinova T  C   22:47, 5 September 2020 (UTC)

Changing it might break some nbt inherit templates though. FVbico (talk) 20:58, 6 September 2020 (UTC)
What about change it to only certain templates where it won't break?---Humiebee Discuss anything with me Look at my edits 20:59, 6 September 2020 (UTC)
Oh, LST finally works now? I believe there could be a workaround for NBT pages, but if it can be easily done with non-NBT data, then I am all for it. — BabylonAS *Happy Camper* 07:23, 24 September 2020 (UTC)

Converting .ogg files to .mp3 and .wav[edit]

Given that .ogg files aren't supported on mobile, maybe we should convert all .ogg files into .mp3 (Music samples) and .wav (sounds) files with software like Audacity. One user at Terraria wiki did this to Terraria: Otherworld tracks, wich were .ogg files. --Superwill771 (talk) 15:55, 8 September 2020 (UTC)

 Oppose There will be much much work. Only if you want to do converting and uploads, then, i am  Neutral --TreeIsLife (talk) 16:04, 8 September 2020 (UTC)
Umm... for me, the sounds on skeleton#Sounds, which are ogg sounds, work fine on mobile. FVbico (talk) 16:12, 8 September 2020 (UTC)
Probably (as I understood from discussion) meant on mobiles with mobile view. But even there, it is working. --TreeIsLife (talk) 16:24, 8 September 2020 (UTC)
I use Duckduckgo on an ipad with desktop view and they don't work.--Superwill771 (talk) 16:36, 8 September 2020 (UTC)
Well, it can be problem with iPads/iPhones. Duckduckgo is search engine. --TreeIsLife (talk) 16:40, 8 September 2020 (UTC)
Ogg sounds are not supported in Safari browsers. --AttemptToCallNil (report bug, view backtrace) 17:49, 8 September 2020 (UTC)
Duckduckgo is also a browser app on iOS/Android. I don't know if they meant that. — Thomanski | t | c | 19:38, 8 September 2020 (UTC)
 Half-Support. For the above reasons that some devices don't support these ogg files, I support. However, looking at User:TreeIsLife,'s argument it is a lot of work, I say go ahead and do that, I don't see it as a bad thing. Good luck on that. Blockofnetherite Talk Contributions 18:05, 8 September 2020 (UTC)
 Changed to full support for below reasons. Blockofnetherite Talk Contributions 21:22, 9 September 2020 (UTC)
 Support, this wiki is about work, I use safari and it fails completely, the terraia wiki example is good.---Humiebee Discuss anything with me Look at my edits 19:26, 8 September 2020 (UTC)
 Weak support for conversion to MP3, definitely not WAV. See my explanation on Terraria Wiki. --AttemptToCallNil (report bug, view backtrace) 19:38, 8 September 2020 (UTC)
So your saying we could use FLAC?---Humiebee Discuss anything with me Look at my edits 19:41, 8 September 2020 (UTC)
It looks possible, but I don't think this was actually done on the wiki before. --AttemptToCallNil (report bug, view backtrace) 20:05, 8 September 2020 (UTC)
 Support, but I'm not gonna do it. — Thomanski | t | c | 19:39, 8 September 2020 (UTC)
 Strong oppose. Just because ogg isn't supported on some mobile devices now, doesn't mean it won't be later, given that it's a license-free open-source thing. Firefox and Chrome already support ogg. I note that the VLC player supports ogg on all mobile devices. And I believe the Opera browser does also, which is also available on any mobile device. ~ Amatulic (talk) 16:28, 9 September 2020 (UTC)
why strong oppose TheGreatSpring (talk) 07:56, 22 September 2020 (UTC)
As a matter of principle, I strongly oppose creating unnecessary time-wasting busy-work, which is basically what is being proposed. Ogg is playable on all desktop browsers and on all mobile devices using VLC. By the time all the work has been done to convert ogg to mp3, mobile browsers will likely be supporting it anyway. ~ Amatulic (talk) 21:13, 22 September 2020 (UTC)
 Weak support as a temporary measure until the majority of affected devices end up supporting playback. - User-12316399 (talk) 17:11, 9 September 2020 (UTC)
 Neutral. I definitely don't like mp3 because it's not lossless, and I think this wiki supposedly being a source of information should present that information without losses. I see the issues with wav and ogg as well, though. What other possibilities are there? Blue Banana whotookthisname (talk) 07:39, 21 September 2020 (UTC)
Well, the sounds and music are stored in Minecraft as Ogg files in the first place, so if data integrity is a concern, they should be used and uploaded directly, which was already done. (For music files, it’s possible to cut the file to 30 seconds without re-encoding it — FFmpeg does allow that, not so sure about Audacity.) — BabylonAS *Happy Camper* 15:09, 24 September 2020 (UTC)
 Weak support TheGreatSpring (talk) 07:56, 22 September 2020 (UTC)
 Oppose — Transcoding Ogg Vorbis (one lossy format) to MP3 (another lossy format, with worse quality by the way) isn't good practice in general, and using WAV will lead to much larger files. Safari not supporting Ogg is Apple's fault, and VLC is also available (if I recall correctly™) on iOS/macOS as well. As for royalty free, this advantage of Ogg is no longer relevant now, as all patents on MP3 have already expired, however Ogg Vorbis is still superior quality-wise (as in, Ogg file will sound better than an MP3 of identical size). It doesn't seem to be worth the effort. — BabylonAS *Happy Camper* 07:19, 24 September 2020 (UTC)
I now  Oppose the idea TheGreatSpring (talk) 12:56, 24 September 2020 (UTC)
 Weak Oppose. I don't really have any original arguments, just see the opposing arguments above. I especially wouldn't like MP3 if it is indeed more lossy than Ogg. It seems like a lot of work and I know how long it can take us to do these sorts of tasks. -PancakeIdentity (talk) 19:13, 24 September 2020 (UTC)
Changed to  Weak support for above reasons, still think it should be done. I am  Weak oppose for mp3,  Support for wav and  Weak oppose due to the amount of time and effort it woult cause.---Humiebee Discuss anything with me Look at my edits 16:08, 17 October 2020 (UTC)
 Comment - Doesn't Wikipedia have a web player or something? I'm able to play Ogg Vorbis sounds in Wikipedia while using Safari. – Unavailablehoax (talk) 16:30, 17 October 2020 (UTC)
I'm pretty sure that is .ogv, not .ogg and it's basically adding up .gif and .(a music file that is available in all search engines as well as not being lossy)---Humiebee Discuss anything with me Look at my edits 21:42, 28 October 2020 (UTC)
What makes you think it's a video? Here an example sound file from Wikipedia, which is in Ogg Vorbis and can be played in Safari. – Unavailablehoax (talk) 22:12, 28 October 2020 (UTC)
.ogv is just an extension, the base format is still the same (well, then you’d usually have Theora video together with Vorbis audio). As far as I know Wikipedia uses a different extension for media playback, which might in fact handle audio files somewhat differently. — BabylonAS 10:36, 29 October 2020 (UTC)

The Skeleton Horseman problem, and how should we fix it?[edit]

Recently, Skeleton Horseman has had its link changed from Skeleton Horse#Skeleton trap to MCD:Skeleton Horseman. Two major problems emerged from doing so:

  1. Many "Skeleton Horseman" links of the Minecraft jockey-like mob suddenly redirected into a Minecraft Dungeons mob. This created problems for the Minecraft topic section of the Skeleton (disambiguation) page.
  2. At least two templates, Template:EntitySprite and Template:EntityLink's id is "skeleton-horseman", not "skeleton-trap".

Is it called a skeleton trap, a skeleton jockey, or a skeleton horseman? This change of redirect of the [[Skeleton Horseman]] page has caused some confusion for me.
Blockofnetherite Talk Contributions 20:33, 8 September 2020 (UTC)

Ok, try do to your best and fix it, i have no other argument, so I am  Supporting. --TreeIsLife (talk) 20:40, 8 September 2020 (UTC)
 Comment Thanks for the support, but I currently don't want to fix it yet, as I still don't exactly know how to fix it, nor do I know how to change those two templates which use the id "skeleton-horseman". @Humiebee very recently undid @Fadyblok240 's edit, but it's not over. Blockofnetherite Talk Contributions 20:44, 8 September 2020 (UTC)
To avoid confusion, I added the {{redirect}} template.---Humiebee Discuss anything with me Look at my edits 20:46, 8 September 2020 (UTC)
It should be redirected back to skeleton trap with a hatnote ({{for}}) added to the top of the section. Vanilla should always take priority.  Nixinova T  C   20:41, 8 September 2020 (UTC)
 Comment What about the templates? Blockofnetherite Talk Contributions 20:47, 8 September 2020 (UTC)
 Done, but with {{redirect}} instead---Humiebee Discuss anything with me Look at my edits 20:43, 8 September 2020 (UTC)

Now that this issue is fixed, there are still questions remaining.[edit]

It seems that "skeleton trap" and "skeleton horseman" have been used interchangeably. In the Skeleton Horse page, where skeleton traps/horsemen are described, they call them skeleton traps. However, the {{EntitySprite}} and {{EntityLink}} templates use the id: "skeleton-horseman". So what are they, skeleton traps, skeleton horsemen, or skeleton/skeleton horse jockeys? What should we do, keep them as interchangeable terms, or merge into one?
Blockofnetherite Talk Contributions 16:15, 9 September 2020 (UTC)

 Comment: Skeleton trap: "The mechanic where skeletons riding horse skeletons have a chance to appear when a lightning hit the ground". Skeleton horseman: "The name of the compound entity made of 2 mobs". That's how I always have understood this thing, and I think that clarifying the definitions of the terms will help readers and editors to use them better. Thejoaqui777 (talk) 19:54, 21 March 2021 (UTC)
Skeleton traps are the skeleton horses that stand still and visually get struck by lightning when approached; they spawn 4 skeleton horsemen. Dhranios (talk) (Join the wiki videos project!) 20:03, 21 March 2021 (UTC)

Add shorthand Namespaces for certain things[edit]

Now there are shortened namespaces such as MCD:Zombie or MCE:Muddy Pig but others such as Templates don't have one. All namespaces except for main (obviously) should have an abbreviation.
Already Existing

  1. MCW (Minecraft Wiki)
  2. MCT (Minecraft Wiki talk)
  3. MCE (Minecraft Earth)
  4. MCD (Minecraft Dungeons)

Not Sure if exists

  1. Minecraft Dungeons talk or Minecraft Earth talk
  2. My proposals would be MDT and MET respectively

Does not exist, definitely want

  1. TP for Template
  2. TPT for Template talk
  3. MW for MediaWiki - Automaticly redirects to mediawiki.org, so that's impossible to add.
  4. New Proposal for MediaWiki. MDW for MediaWiki.
  5. MWT for MediaWiki talk
  6. CAT for Category
  7. CTT for Category talk
  8. M or MOD for Module
  9. MT or MDT for Module talk

If this gets implemented, want for consistancy

  1. T for talk
  2. U for User
  3. UT for User talk
  4. F for File
  5. FT for File talk
  6. H for Help
  7. HT for Help talk
  8. W for Widget (didn't even know this existed)
  9. WT for Widget talk
  10. S or SP for Special Page
  11. UP for UserProfile

Ones that I really just don't want or need but it would br nice for consistancy

  1. G(T) or GAD(T) for Gadget (talk)
  2. GD(T) for Gadget definition (talk)

---Humiebee Discuss anything with me Look at my edits 20:09, 11 September 2020 (UTC)

Not sure these should all be created, but I can definitely make a template that does this.  Nixinova T  C   20:10, 11 September 2020 (UTC)
I think, their existence wouldn't harm the wiki. FVbico (talk) 20:18, 11 September 2020 (UTC)
How do tou create a template for namespaces?---Humiebee Discuss anything with me Look at my edits 20:21, 11 September 2020 (UTC)
Not for the namespaces themselves, but for linking to them. That wouldn't affect searching, however, but I could also make a script that does this for individuals.  Nixinova T  C   20:29, 11 September 2020 (UTC)
I would love the script as I search for templates a lot and it's annoying when I misspell it as trmplate (r is on the way from t to e so yeah), where would the script go, common.js?---Humiebee Discuss anything with me Look at my edits 20:32, 11 September 2020 (UTC)
Yes, common.js, try adding mw.loader.load('/index.php?title=User:Nixinova/namespace-shortcuts.js&action=raw&ctype=text/javascript'); to yours to test my new script.  Nixinova T  C   20:49, 11 September 2020 (UTC)
Oh, ok, thank you, can you delete the test page I made and it's documentation?---Humiebee Discuss anything with me Look at my edits 20:51, 11 September 2020 (UTC)
Why does it go to like the search then the desired page, nothing of a big deal though, is it a limitation or is it diffucult to change that?---Humiebee Discuss anything with me Look at my edits 21:29, 11 September 2020 (UTC)
Fixed.  Nixinova T  C   21:45, 11 September 2020 (UTC)
I think it broke again.... I searched UT:Nixinova and it didn't work..., thanks for everything!---Humiebee Discuss anything with me Look at my edits 21:55, 11 September 2020 (UTC)
Fixed as well. Take further reports to User talk:Nixinova/namespace-shortcuts.js.  Nixinova T  C   22:07, 11 September 2020 (UTC)
(edit conflict) I think they could be implemented into shortcut redirects, but implementing them as aliases would require modifying the wiki software. Also, I prefer CAT: over C: for categories. Fadyblok240 (talk) 20:34, 11 September 2020 (UTC)
 Changed---Humiebee Discuss anything with me Look at my edits 20:39, 11 September 2020 (UTC)
I don't see the point of most of these, they would add confusion since most other wikis don't have these abbreviations. The only ones that I support are Minecraft Dungeons/Earth talk since these are more of a handful to type out, and are more likely to be linked to (as opposed to the MediaWiki namespaces, for example). –Sonicwave talk 22:14, 11 September 2020 (UTC)
I agree with you, especially about the talk pages of non-article pages except for the Minecraft Wiki: namespace. Even Wikipedia doesn't have alias for most types of talk pages. Fadyblok240 (talk) 22:52, 11 September 2020 (UTC)
 Oppose changing, except MDT and MET. Sry, but shortcuts are SHORT-CUTS. So it is for shorter things, and for things, which won't get confused. This means, it is for project talks or ns with more then 8 characters. And MediaWiki, NO! I don't know, how it will work, but MediaWiki shouldn't be shortcutted in any way! I don't want, that users will easily get to MediaWiki ns. Also, special pages,... No! --TreeIsLife (talk) 17:43, 12 September 2020 (UTC)
Why oppose special pages and templates? You gave no reason for special pages and templates have more than 8 characters and I use them as search terms a lot---Humiebee Discuss anything with me Look at my edits 22:12, 12 September 2020 (UTC)
 Done with {{sl}} and example U:Nixinova/namespace-shortcuts.js of course by Nixinova. The only issue is that it shows in S:WantedPages---Humiebee Discuss anything with me Look at my edits 20:10, 12 September 2020 (UTC)
I'll fix the wanted pages thing, however these still don't go towards making universal namespace shortcuts.  Nixinova T  C   20:12, 12 September 2020 (UTC)
Wait actually you just have to do {{sl}}, does it still come up in S:WantedPages?---Humiebee Discuss anything with me Look at my edits 20:29, 12 September 2020 (UTC)
Well, with {{sl}}, i'm not oppose, i only was scared, if many users, which want to browse wiki content will see MediaWiki:Hydra.css by just MDW or other things, which are not wiki content.--TreeIsLife (talk) 19:51, 13 September 2020 (UTC)
Why would they type media wiki in the first place? You would type the shortcut if you knew the destanation and as for {{sl}}, if they saw the link and pressed it, they would just press the back button (an example of this "back button" sense is TP:Disambiguation.---Humiebee Discuss anything with me Look at my edits 20:47, 13 September 2020 (UTC)
This is already partially implemented with {{sl}}, however, for this to be 100% implemented, U:Nixinova/namespace-shortcuts.js would have to be implemented to MediaWiki:common.js, however, tjis will need a consensus. There still has not been a clear answer but it seems like User:Nixinova is support and User:TreeIsLife is Oppose. Any thoughts or clear opinions?---Humiebee Discuss anything with me Look at my edits 20:52, 13 September 2020 (UTC)
 Oppose for most talk namespaces and site-wide automatic implementation. Even Wikipedia doesn't use shortcuts for most namespaces. We should use shortcuts on a page-by-page basis, meaning we can abbreviate the page name, not just the namespace. Fadyblok240 (talk) 22:45, 13 September 2020 (UTC)
 Comment Putting shortcuts on pages? There are so much more pages then shortcuts, I don't get why your proposing this and your only reason for opposition was

Even Wikipedia doesn't use shortcuts for most namespaces.

U:Fadyblok240

Even Wikipedia doesn't use shortcuts for most namespaces.
U:Fadyblok240

do you have any more opposition reasons? I mean the shortcut for searching substitutes it, not like normal Ex:If i'm searching MCT:CP, MCT doesn't turn into Minecraft Wiki talk:whatever page, it keeps it but this commons.js thing does this, T:Golden Apple->Talk:Golden Apple. Again, it's helpful and I don't see anything wrong, it's nice and convenient, also you have to put T: (colon) so it won't affect normal searching---Humiebee Discuss anything with me Look at my edits 00:19, 14 September 2020 (UTC)
 Support as this is a quality of life change that assists editors and viewers. I really don't see any real problems, and no technical issues as of what I know. Blockofnetherite Talk Contributions 00:14, 15 September 2020 (UTC)
I am still  Oppose about this idea. This is bad idea with auto redirect. Yes, even Wikipedia has no "shortcut ns". What you see like WP:R is basicly an article with redirect. Sry, but not everything is good. --TreeIsLife (talk) 18:04, 15 September 2020 (UTC)
 Support per above reasons. TheGreatSpring (talk) 10:32, 18 September 2020 (UTC)
 Oppose most shortcuts. A single letter namespace name is hard to read and can be confusing for new users, all for the gain of you typing 5 less letters. I don't see much point to that. For long namespaces such as Minecraft Wiki or Minecraft Dungeons (and cooresponding talk pages) I agree, but for short ones like Talk or Template, you are gaining a ton of confusion in favor of typing 6 less letters. (is T:Minecraft a talk page, or a template?). Plus, many of these rarely get links, such as widgets, MediaWiki, and Help. Template is also rarely linked directly, the template syntax automatically handles it. KnightMiner (t/c) 17:27, 10 November 2020 (UTC)

New proposal[edit]

It looks like the most support is headed towards implement for only MET and MDT and the others are not really nessicary, so would you support just

  1. Only MDT and MET
  2. MD, ME, MDT, MET
  3. Everything on my definitely list (+ MD and ME)
  4. Everything except Gadget, Widget, and their talk and definition variants.
  5. Everything

I feel like MD and ME could also be helpful (so that is why I added it to the list)---Humiebee Discuss anything with me Look at my edits 22:37, 19 September 2020 (UTC)

Option 1 and CAT: for Category:, H: for Help:, and T: for Template: instead of Talk: Fadyblok240 (talk) 23:37, 19 September 2020 (UTC)
Option 1 and that's it! This is not Project NS or talks, so there is no need to do other shortcuts. --TreeIsLife (talk) 11:41, 24 September 2020 (UTC)
Certainly Option 1 at least. I dislike the idea of CAT shortening (suggested by Fadyblok) because no category uses short names like Minecraft Wiki pages or even some templates do. Help shortening does seem to be helpful, the same may apply for templates, and if both these get shortcuts, then their talk pages should probably have them as well (HT and TT). But implementing shortcuts for all namespaces just for the sake of it is certainly not worth the effort.
As I said before, I don't support most namespace aliases (including CAT:); I only support them as pseudo-namespace redirects for some pages. Also, I would rather have W: point to Wikipedia pages than to Widget pages. Fadyblok240 (talk) 01:12, 22 November 2020 (UTC)
On a side note, why exactly MDT and MET? The respective article namespaces are abbreviated MCD and MCE. Unless such shortenings are limited to three letters for some reason, I’d suggest using MCDT and MCET respectively for the sake of consistency (though, we already have MCT for Minecraft Wiki talk...). — BabylonAS *Happy Camper* 06:27, 25 September 2020 (UTC)
For consistancy that is (all namespaces has 3 letter) and yes, it would be consistant with MCT (it's not MCWT))---Humiebee Discuss anything with me Look at my edits 14:11, 26 September 2020 (UTC)
Option 1 TheGreatSpring (talk) 06:58, 25 September 2020 (UTC)
Still staying with  Everything per my above reason. Just don't see anything wrong with this addition, saving characters is useful. Blockofnetherite Talk Contributions 19:31, 1 October 2020 (UTC)
Keep in mind that some of the proposed namespace shortcuts conflict with potential interlanguage links, such as ga: for Gadget and Irish (which doesn't make any sense since pages in the Gadget namespace, if any, cannot be accessed directly from the search bar) and tl: for Talk and Tagalog (which somewhat offends me since I am an ethnic Filipino). Another reason to  Oppose. Fadyblok240 (talk) 23:43, 23 October 2020 (UTC)
Okay, I don't think we need Gadget, Widget, or MediaWiki, because we shouldn't make it easier to see MediaWiki pages, as they contain information (like blocked words/website links on the inappropriate filter). Gadget and Widget are not so necessary. Talk is proposed to be short for T and not Tl. Still  Supporting MDT, MET, TP, TPT, CAT, CTT, MOD, MDT, T, U, UT, F, FT, H, HT, S and SP, and UP. Blockofnetherite Talk Contributions 18:10, 6 November 2020 (UTC)
See WP:Perennial_proposals#Create shortcut namespace aliases for various namespaces for why this was rejected in Wikipedia and probably the Minecraft Wiki. Fadyblok240 (talk) 04:05, 10 November 2020 (UTC)
I  Oppose the addition of a "T:" namespace, as "T" could stand for either "talk" or "template", and because of this, such a namespace would be more confusing than helpful. I  Oppose the "M:" namespace for the same reason, as "M" could stand for either "module" or "MediaWiki". I also  Oppose the "GA:" namespace as it would conflict with interwiki links. I  Support "MDT:" and "MET:", as the main Dungeons and Earth namespaces already have shortcuts, so the addition of shortcuts to their talk namespaces would create consistency. I'm  Neutral about the rest, as whilst I can't see much harm in adding them, I'm unsure whether they would be particularly helpful, either. GrogTheGreatEvilGoblinWarlord (talk) 06:00, 11 November 2020 (UTC)

Add sort keys for version exclusive articles (including articles about versions themselves)[edit]

I think it would benefit to add sort keys to remove prefixes from version exclusive articles. (e.g. the sort key for Java Edition level format would be Level format) It would provide a better ordering of lists of pages in version exclusive categories. Fadyblok240 (talk) 21:10, 12 September 2020 (UTC)

Go ahead, this should be an uncontroversial change.  Nixinova T  C   22:10, 12 September 2020 (UTC)
It may take a long time to add all the sort keys for the version articles. Maybe consider modifying or creating templates (see Template:Version nav/sandbox) to automatically create the sort key? Meanwhile, I will add sort keys for articles that are not about versions. Fadyblok240 (talk) 22:21, 12 September 2020 (UTC)

Change the main discussion from MCT:CP to MCW:Centralized discussion[edit]

This is a very big change proposal but I have some reasons to back it up.

  1. This page should be used for discussing the Community Portal itself
  2. The ftb wiki does this as well
  3. It could be linked on the sidebar (as centralized discussion)
  4. How did this name start anyways?
  5. There is not any page to describe this main community discussion, now that it is in MCW namespace instead of MCT namespace, it could have a proper talk page.
  6. This would be an enourmus change and could break a lot of links.
    1. However, I will try to fix the links
  7. However, it fits more nicely

---Humiebee Discuss anything with me Look at my edits 22:14, 28 September 2020 (UTC)

The community portal page itself needs almost no discussion as most of it is requesting pages or linking other discussions, I don't see a need for a dedicated talk page. This page is the portal to community, including community discussion, so the name seems clear enough to me. Plus, centralized discussion can lead to confusion, such as that the page is the only place we discuss wiki topics. Additionally, as you said, this is a huge change which will break basically any reference to the portal; none of the benefits you listed outweigh breaking all links from former discussions. KnightMiner · (t) 16:08, 29 September 2020 (UTC)
Looking at the What links here tool, 214 pages link here, and since at least like 50 of them are like redirects and duplicates (yes if it shows a redirect, it shows it indented below the redirect AND as normal) so it shouldn't be such a hard task. Since this page would not be used as much, it's redirects could just change without worry of the actual page, and like you said, if there is no discussion, it could temporaraly become a redirect while the links try to be fixed.---Humiebee Discuss anything with me Look at my edits 22:24, 30 September 2020 (UTC)
In my opinion, the community portal can very well be discussed about on the community portal, "wiki name"/Community portal is default and thus very widely used in other Gamepedia wikis, ftb is completely unrelated to this wiki, apart for the remaining mod pages, and, as you said yourself, this would be a enormous disruptive change.  Oppose. Sagessylu (discuss | edits) 17:19, 1 October 2020 (UTC)
 Massive Oppose - Seriously? Ok, Wikipedia works this way, but this is ultra massive change, which won't end up being useful. You could name this section - Proposal, which will never get any support. Idk, why, but your ideas are sometimes really outside of reality. This will be so much work, that idk, how will be doing this. A bot? Admins? You? No, this is outside reality change this page, as ut is so active, that it will be bad. Also, even we will end up doing this, it won't be MCW:Centralized discussion, but some MCW:Village pump (just like Wikipedia has it) --TreeIsLife (talk) 12:03, 3 October 2020 (UTC)
 Oppose. I don't really see the point in fixing something that isn't really broken. ~ Amatulic (talk) 17:28, 3 October 2020 (UTC)
 Weak support Well, I guess I'm the only one who supports this at all. Fadyblok240 (talk) 15:26, 20 October 2020 (UTC)
 Massively oppose, there's absolutely nothing to gain from this change, and it would break so much. Every wiki does things slightly differently, consistency with other wikis really isn't a reason to do something. Not only pages on the wiki link to the community portal, links outside of the wiki (such as on discord) will all break too, and you cannot fix those. Do consider all of these in your proposals, because, as stated by others, this idea is way outside of the scope of reality. Nothing to gain, everytging to break. Dhranios (talk) 16:06, 20 October 2020 (UTC)

UCP considerations[edit]

suppressredirect permission, UCP, and autopatrolled users[edit]

On UCP, regular users won't have the permission to move pages without leaving a redirect. This permission will become admin-only. Since there are valid use cases for non-admins using this permission, but concerns with all users having it, I propose to grant autopatrolled users and patrollers this right. Non-English Minecraft Wikis may have other custom groups that they feel should not lose this right and aren't going to cause much damage with it; if so, I encourage the users of these wikis to list these groups here. See also the Wikipedia group that inspired this proposal. --AttemptToCallNil (report bug, view backtrace) 12:40, 2 October 2020 (UTC)

Is moving without redirect vandalism (or in general bad edits) really common though? because if not, I see no reason to take that permission from anyone who may not have autopatroller rights. Dhranios (talk) 13:10, 2 October 2020 (UTC)
I couldn't get a conclusive answer on whether a configuration with suppressredirect for all registered users will be approved (there's no guarantee it will be, and from what I've heard, staff don't know either). I can't give a conclusive answer on whether such vandalism is common either, but I'd say we should expect disruptive users with accounts to be more common than before given that now having an account is much easier (no more Twitch requirement). --AttemptToCallNil (report bug, view backtrace) 13:26, 2 October 2020 (UTC)
If the privilege gets taken away from regular users, I'd definitely support allowing autopatrol and patrollers to retain it, for the reasons you described. I might actually support it otherwise as well, as currently any user who logs in essentially has the ability to delete a page (because that's literately what moving without a redirect does). If someone has the autopatrol or patroller right, they're presumably trusted enough to make constructive edits/moves, so imo they can be trusted to move without leaving a redirect.--Madminecrafter12 (Talk to me | View what I've done) 13:17, 2 October 2020 (UTC)
 Done I added the suppressredirect permission to the following groups:
--  HorseFace.png Gamepedia icon.png MarkusRost (talk) 22:50, 2 October 2020 (UTC)

Comparison of Lua-based templates and non-Lua counterparts[edit]

According to Template:SimpleNavbox/doc, Lua-based templates seem to be slower than their non-Lua counterparts, contrary to the situation on Wikipedia. This might change when the Minecraft Wiki is transferred to the UCP. I want someone to prove or disprove the statement that Lua runs slower than parser functions, before and after migration to the UCP. Fadyblok240 (talk) 02:26, 3 October 2020 (UTC)

That template is not a useful general judgement for Lua vs. wikitext. In fact, in many cases Lua-based templates are going to be faster. In addition, with UCP we are expected to eventually get LuaSandbox, an extension that makes Lua even faster. --AttemptToCallNil (report bug, view backtrace) 04:33, 3 October 2020 (UTC)

List of broken items[edit]

  • Protection icons
  • Some text that was centered is now left-aligned

Fadyblok240 (talk) 20:00, 5 October 2020 (UTC)

Revert war[edit]

Today, there was Minecon. That means many edits from IPs and vandals. But today, there is problem with diffrent thing - Planned Fixes and Planned changes.

There are 2 camps now for these 2 topics. First is that, which wants to have Planned fixes on page and Planned additions on Update page.

Second (in which i am) wants to have Planned additions on page and don't have Planned fixes on page.

So to solve this problem, we can vote, because Camp 1 is now (if i am correct) violating style guide. So we could change it and don't be scared, that we will have edit wars after Update annouced.

Here are options for Planned Additions

  1. Have Planned Additions on Caves & Cliffs page
  2. Have Planned Additions on Java Edition 1.17

Options for Planned Fixes

  1. Have it on update page
  2. Have it seperate page
  3. Don't have it

--TreeIsLife (talk) 19:16, 3 October 2020 (UTC)

With Planned additions, i  Support Option 2, and with Planned Fixes also  Supporting Option 2. --TreeIsLife (talk) 19:16, 3 October 2020 (UTC)
Planned additions go on the Caves & Cliffs page for now, and is transcluded on JE & BE 1.17, but fixes are edition-specific and should go on their respective pages.  Nixinova T  C   19:45, 3 October 2020 (UTC)
@Nixinova: Maximally, we could make subpage for entire update content, like Legacy Console Edition has. –Preceding unsigned comment was added by TreeIsLife (talkcontribs) at 19:51, 3 October 2020 (UTC). Please sign your posts with ~~~~
Well, LCE versions are pretty much exactly the same, running on the same codebase etc. Java/Bedrock are very much not that.  Nixinova T  C   03:41, 5 October 2020 (UTC)

Smash content[edit]

Hi hi. I'm not a regular editor of the Minecraft Wiki, but rather a visitor from SmashWiki, which—as you can imagine—has been busy with the reveal of Steve and company in SSBU. I was curious as to how you all are going to handle the Minecraft content in Smash. We're already linking to you on a few pages, and I've proposed making a formal partnership between wikis to higher-ups on SmashWiki, but it's still in discussion right now. I suppose right now I just want to ask and gauge interest, since there doesn't seem to be much about Smash on this wiki right now. Is Smash content something you would like to further elaborate on for the wiki, and if so, would partnership (being able to reference and cross-link us where necessary) be of any interest? DryKirby64 (talk) 00:50, 5 October 2020 (UTC)

There's some discussing over at Talk:Super Smash Bros., and personally I think we should indeed document it here. Not sure where exactly, though.  Nixinova T  C   00:53, 5 October 2020 (UTC)

Minecon Live!![edit]

Mega-massive-ultra news for MCD!!!!

Okay that was too dramatic


1. A very important announcement was made for Minecraft: Dungeons at Minecon Live. First of all, we need renders for all of the new mobs in Howling Peaks. Second of all, we need names for the new DLC skins, we need to find out more about the new Armor, Weapons, and the Artifact.

2. They announced a Nether DLC in a Basalt Deltas Biome, Crimson Forest Biome, and more. Piglins, Blazes, and Wither Skeletons were all seen. Is there any more info?

3. They also announced an Ocean DLC. It contains tons of new mobs, but what about the special rolling mechanics? What about the other underwater features? How can the player breathe underwater? Will the Glow Squid be there?

4. End DLC. In the video, for an extremely short nano-time, I saw Archie, back in his Arch-Illager form, and still with the Orb once again, summoning mobs. Did the Ender Dragon secretly have power over the orb this whole time or something? Why is Archie evil again?

5. Obsidian Monstrosity. End or Nether DLC? If it's even going to be a mob....

So that's about it. Please answer my questions one at a time if you have answers, because my eyesight is poor. Howling Peaks (talk) 12:19, 5 October 2020 (UTC)

This notice would be better suited for the Dungeons wiki. Also, we probably don't need these renders until the DLC is actually released. -PancakeIdentity (talk) 23:58, 5 October 2020 (UTC)
Yea but i still cant wait. Also i would love it if they actually put the Obsidian Monstrosity as a boss, that would be dope. James Haydon (talk) 01:07, 6 October 2020 (UTC)

Standardizing NBT documentation tag order[edit]

Currently, NBT documentation is added in a rather arbitrary order in the tree, I'd suggest standardizing the order as much as possible.

My suggestions, either:

  1. Sort alphabetically, ignoring NBT type
  2. Sort by NBT type and then alphabetically

Opinions? Dhranios (talk) 10:13, 6 October 2020 (UTC)

 Support for suggestion #1. Seems cleaner to sort alphabetically as sometimes tags may be related in name and what they are used for in-game while having different NBT types. Suggestion #2 seems impractical. -- SizableShrimp🦐 (talk · contribs) 16:43, 7 October 2020 (UTC)
 Support for suggestion #1, SizableShrimp pretty much explained everything. Sagessylu (discuss | edits) 19:09, 15 October 2020 (UTC)
#1 makes the most sense.  Nixinova T  C   22:08, 15 October 2020 (UTC)

Minecraft dungeons on Xbox series x[edit]

Yesterday I went to JB Hi-Fi to get minecraft dungeons on Xbox one and on the cover of the disc holder is said compatibility for Xbox One|Xbox Series X. Can someone put the series X logo on the wiki so it can go on the dungeons page and main page. --Minecraft loot (talk) 22:04, 6 October 2020 (UTC)

Sounds Page[edit]

Should a sounds page be added, i realize all sounds are being added to pages they are caused from, but should a page with all the sounds from all versions of the game be made, as to have them all in one place, as well as on each page?-Robonate135 (T C) 17:25, 8 October 2020 (UTC)

In my opinion, no. The sound section is only marginally useful, it's just more data to expand the page. It's sufficient for each space (vanilla, Earth, Dungeons) to have their own sound files for things that may be common to all versions. Amatulic (talk) 06:09, 17 October 2020 (UTC)
I don't think this would be super useful and I'd worry about performance and load times with that many files on a single page. I'm not completely opposed to it if anyone has a good reason for it. -PancakeIdentity (talk) 18:16, 22 October 2020 (UTC)
Agreed, sound files take up a lot of space on pages and there is many of them on the wiki for mobs and blocks. I think having these on one page might be useful but it could be hundreds of thousands of bytes in size and could cause severe performance issues or could not load entirely. It would be useful somewhat but it would be too large and too laggy so we shouldn't. James Haydon (talk) 18:22, 22 October 2020 (UTC)
 Neutral, mainly what NineTreyBlud said but instead of creating 1 single page, we could split it into a few pages. 1 for subtitles, and 1 for other sounds.---Humiebee Discuss anything with me Look at my edits 20:11, 22 October 2020 (UTC)
It could be made the same way Block states is done, put the sounds to a subpage (e.g Block of Quartz/Sounds) and all the sound subpages would be transcluded to a page like Sounds. – Unavailablehoax (talk) 20:22, 22 October 2020 (UTC)
Ill agree on that one though, just make sure they are in separate tables. James Haydon (talk) 20:31, 22 October 2020 (UTC)

add certain rights to certain user groups[edit]

Can you add the autopatrol right to Directors and Patrollers?---Humiebee Discuss anything with me Look at my edits 17:29, 12 October 2020 (UTC)

Shouldn't they already have it by default? James Haydon (talk) 19:15, 11 November 2020 (UTC)
They don't for some odd reason, just go to Special:UserGroupRightsHumiebeetalk contribs 03:06, 25 November 2020 (UTC)

What happened to advanced search?[edit]

Advanced search has become useless. It used to show me search results up to 500 per page. Now it's this short paginated thing that doesn't even include all results, and the pagination links don't even work.

For example, try an advanced search for all articles containing the word "epic". Scroll down and go to page 2. You can't. It goes to the rarity article.

Try a search main space for the word "now". 90 results? Just about every article on the game has history sections that include the word "now". That's hundreds of articles, not 90.

Is there a user setting somewhere that gives me back the original search? The only "improvement" here is the ability to search other wikis, which isn't relevant to me. Amatulic (talk) 02:50, 13 October 2020 (UTC)

I think it has to do with the fact that UCP search doesn't use CirrusSearch, which legacy Gamepedia and Wikimedia had been using. The most advanced thing you can do is filter by namespace, which means we miss out on truly advanced search parameters like insource: and regular expressions. Also, the new search only considers articles by default. Fadyblok240 (talk) 02:55, 13 October 2020 (UTC)
And as I mentioned, it's broken. All search results are not shown, and pagination doesn't work.
Bring back the original Wikimedia search! Amatulic (talk) 22:36, 14 October 2020 (UTC)
I don't think they're switching away from the current search (apparently they believe the original search isn't scalable or performant). Some issues with the search are known and are likely to eventually end up fixed. --AttemptToCallNil (talk) 23:04, 14 October 2020 (UTC)
I don't understand how the Wikimedia search, used on the busiest website on the planet, is considered non-scalable and non-performant. This new mess is not an improvement. Amatulic (talk) 05:44, 15 October 2020 (UTC)
I'm not sure either, nor did I read any extensive explanation for why this change happened. It's possible that Fandom running some hundreds of thousands of wikis and having different hardware constraints are important factors, but I, of course, can't have any data on that either. --AttemptToCallNil (talk) 09:31, 15 October 2020 (UTC)
I agree, you can't even create pages using search function, it's horrible.---Humiebee Discuss anything with me Look at my edits 20:36, 15 October 2020 (UTC)
Yes how do you create pages now? It probably harder. James Haydon (talk) 21:15, 15 October 2020 (UTC)
You have to CREATE A REDLINK????? on a page such as MCW:Sandbox. This is torture.---Humiebee Discuss anything with me Look at my edits 21:20, 15 October 2020 (UTC)
Its easy to create a redlink if you use visual editor, i just go on a small page, add a link that doesnt exist yet, open it in a new tab, and discard my edit and create the page. It may also work with source editor but you have to use the page preview button. James Haydon (talk) 21:22, 15 October 2020 (UTC)
minecraft.gamepedia.com/<page name> – Unavailablehoax (talk) 21:24, 15 October 2020 (UTC)
Yes is suppose but that is the way i am used to creating them. James Haydon (talk) 21:26, 15 October 2020 (UTC)
I never use visual editor as it is ick, Unavailablehoax's idea is fine and easy though.---Humiebee Discuss anything with me Look at my edits 02:26, 16 October 2020 (UTC)
Another thing is that it doesn't suggest the redirect when typing in the search bar, but instead the target page of the redirect.
For example, typing 'Warden' doesn't suggest the redirect Warden, but instead Caves & Cliffs. This means a user trying to find information about the Warden would have to scroll to the Caves & Cliffs § Warden section, while the Warden redirect would have gone to that section automatically. – Unavailablehoax (talk) 21:47, 15 October 2020 (UTC)
 Comment Yes that is really not a good thing, it makes redirects useless unless it goes to an actual page instead of a section. James Haydon (talk) 21:50, 15 October 2020 (UTC)
A fix at least for the no new page link is expected to come. Other fixes are definitely considered. If you have specific feedback, please send it to Zendesk (like that redirect thing) so that staff take a look. But chances are, a lot of the issues you raise here are already known. (It's useful to tell us anyway even if they just answer, "This is known". Part of the reason I wrote that list on the Help Wiki is to present the community with a centralized, if unofficial, source of issue information in the absence of a public issue system.) --AttemptToCallNil (talk) 23:33, 15 October 2020 (UTC)
The redirect problem has been fixed, still waiting for the page creation issue, typing Caves and Cliffs worked.---Humiebee Discuss anything with me Look at my edits 22:54, 16 October 2020 (UTC)
The pagination bug I mentioned at the top of this thread is fixed too. Advanced search for "epic" and the page links at the bottom no longer take you to the rarity article. However, erroneous search results appear, like pickaxe and sea pickle, neither of which includes the word "epic" anywhere in the article. Amatulic (talk) 06:06, 17 October 2020 (UTC)
The redirect bug and the create new page bug has been fixed, however there are still many other bugs such as what Amatulic said, incorrect search results as well as a lack of results. Wikimedia search is not going to come back in a LONG time (most likely never)---Humiebee Discuss anything with me Look at my edits 01:15, 21 October 2020 (UTC)
Did they also stop advertising unrelated wikis in the corner, because that is annoying too. James Haydon (talk) 01:17, 21 October 2020 (UTC)
They did, it's still comepletly broken as when i search welcomee, it does not even show results for welcome, it just shows some random story mode episode page like ???????---Humiebee Discuss anything with me Look at my edits 01:22, 21 October 2020 (UTC)
I think it looks for those words in other pages and then recommends them above the actual pages. James Haydon (talk) 01:24, 21 October 2020 (UTC)
 Update, there is another bug with search. When you search a page that does not exist, it shows as a blue link but when you click on it, it says Creating Page <page name>.Humiebee (talk) 17:19, 16 February 2021 (UTC)

Spooky Fall[edit]

Make pages with content from the MCD:Spooky Fall MCD:Seasonal Trials. Minecraft Dungeons Howling Peaks (talk) 15:58, 16 October 2020 (UTC)

Okay i already have an image related to that on my computer. James Haydon (talk) 15:59, 16 October 2020 (UTC)
Like Pages for MCD:Hungry Horror and MCD:Haunted Bow. Minecraft Dungeons Howling Peaks (talk) 18:49, 16 October 2020 (UTC)
Yes, if those are the names i will create them. James Haydon (talk) 18:51, 16 October 2020 (UTC)
They are now created, give me any more items/mobs that will appear in these seasonal trials. James Haydon (talk) 18:55, 16 October 2020 (UTC)
Go to twitter.com/dungeonsgame and check daily for any new Spooky Fall-related Dungeons items or mobs, I need to catch up on online schoolwork so I won't be available to do so. I'm getting backlogged. Minecraft Dungeons Howling Peaks (talk) 14:26, 17 October 2020 (UTC)

Never received confirmation email[edit]

I keep getting a message at the top of most pages that my email address has not been confirmed. I've clicked the link to send me another email many times, but still have never received an email of any kind.

Can someone verify that the email sending process actually works?

(Yes, I checked my junk filters and other tabs of mail.)

Jim SirDaddicus (talk) 21:32, 17 October 2020 (UTC)

Same for me, but I signed up using twitch, so I somehow eventually got it in my twitch email, not my gamepedia account email. Blockofnetherite Talk Contributions 02:59, 18 October 2020 (UTC)
When i did it i had to wait many hours for it to come in, i even thought something was wrong with my email and i changed it. The UCP migration has kind of ruined gamepedia in some ways. James Haydon (talk) 18:51, 18 October 2020 (UTC)

Remove section on Mob page[edit]

There's a low-quality section "mobs to be added" on the Mob page, which also violated a comment on the page that explains to not add any mobs until they appear in a development version. I was simply going to delete this section, but was disallowed.

SweptThrone (talk) 01:01, 23 October 2020 (UTC)

I fixed some of the grammar and capitalization, but i am still disputing if it should be there. James Haydon (talk) 02:47, 23 October 2020 (UTC)
I commented out the section as a violation of MCW:FUTURE.  Nixinova T  C   04:37, 23 October 2020 (UTC)
Okay, i wasnt keen on keeping it, as it has been removed before for the same reason. James Haydon (talk) 12:43, 23 October 2020 (UTC)

bedrock or java?[edit]

i feel that the java and bedrock info is a bit outdated and me, a bedrock editon player have items, mobs, and blocks that you mark "java only" i think you shoud work on that--67.189.86.56 18:34, 5 November 2020 (UTC)

Which pages do you mean? – Unavailablehoax (talk) 18:57, 5 November 2020 (UTC)

Moving Minecraft Story Mode Wiki to this wiki[edit]

The following discussion of a proposed merger with Minecraft Story Mode Wiki is closed. Please do not modify it. Subsequent comments should be made in a new section.
Pausing merger, because MCSM Wiki editors are oppose for now. Till admins won't discuss with editors and readers, it has no sense to keep it open --TreeIsLife (talk) 13:44, 27 November 2020 (UTC)

Hi guys. I have an idea, which we partially discussed on Minecraft Wiki Crossover Discord. So, idea is creating Namespace for Minecraft Story Mode and moving there content from https://minecraftstorymode.fandom.com. Yes, it is an active wiki, with many content, which may help this wiki.

This is in a plan of entire crossosover of wikis.

We discussed, that there should be 3 big wikis - Minecraft Wiki (with all non-community content releated to MC), FTB Wiki (for mods) and Minecraft Community Wiki (Creepypastas, Servers, buildings, etc.)

So, what do you think about migrating Story Mode Wiki? --TreeIsLife (talk) 14:23, 11 November 2020 (UTC)

Having it be kept under a namespace is basically the only thing I'm bothered about. Otherwise, go ahead. - User-12316399 (talk) 14:25, 11 November 2020 (UTC)
Well, unfortunatly, it is not so easy as you think. So, there is need for both sides to agree. And as the Wiki has users, who are still contributing, i cannot just force users. I know that, because i already merged 1 community and it took 1 month, to just start it. And it compleated 1.5 months later, with wiki being locked.
And wiki is somewhat active. --TreeIsLife (talk) 15:52, 11 November 2020 (UTC)
So, when comparing to this number of content + users, it may take 2 or 3 months. But, if not using Discord, maybe just few weeks.--TreeIsLife (talk) 14:36, 11 November 2020 (UTC)
 Weak oppose, mainly for the reason that story mode is discontinued and it would take a lot of work, and I also  Strong oppose adding a separate namespace. Also, the pages themselves will probably gain no traction for readers and editors anyways.Humiebee (talk) 15:45, 11 November 2020 (UTC)
It is just merging for better SEO results, because all Gamepedia wikis will migrate to fandom.com domain early 2021. And this is reason, why i am making a subpage with project crossover. --TreeIsLife (talk) 15:50, 11 November 2020 (UTC)
Changed to  Weak support and  Neutral per below.Humiebeetalk contribs 21:28, 13 November 2020 (UTC)
 Comment There is already a project about adding minecraft story mode content i believe, but i dont think there is enough to constitute for its own namespace and sub wiki. I think it should have it content put on the main wiki marked with minecraft story mode in the title. James Haydon (talk) 19:03, 11 November 2020 (UTC)
(I think we are getting from the main path - theme). So, i am talking about Wiki, not sub-wiki, which is on Fandom! There are over 300 pages, which makes it big enough to have its own namespace. Next time, use pls term Main page, as main wiki is Minecraft Wiki, as a name, and you probably meant main page. Yes, now, we have like 3 articles, but with this, we can boost wiki with many content. --TreeIsLife (talk) 19:11, 11 November 2020 (UTC)
Okay so if we are going to make a namespace it should be MSM, the acronym for Minecraft Story Mode. James Haydon (talk) 19:13, 11 November 2020 (UTC)
No, we don't use shortcuts as namespaces, only aliases. It would be "Minecraft Story Mode" or "Story Mode" with alias MCSM or SM respectively, to match dungeons and earth (MCD MCE, not MD ME). Dhranios (talk) 19:35, 11 November 2020 (UTC)
I personally  Support, the reason being that it's a Minecraft game and should be on the Minecraft wiki. I don't know how many other people would want to contribute. Maybe if we contacted the people in the Fandom Wiki they would be up to helping. There is currently a request move on my user page for a Story Mode exclusive features for an official page. If nothing else, we could at least have that. https://minecraft.gamepedia.com/User:Yekulten/Story_mode_exclusive_features Yekulten (talk) 12:35, 12 November 2020 (UTC)
 Support moving Story Mode content to this wiki. This would improve the main Minecraft wiki by making it more comprehensive, and could even bring in new readers and editors. The move would also improve consistency, as all other official Minecraft games are already documented in this wiki. GrogTheGreatEvilGoblinWarlord (talk) 14:07, 12 November 2020 (UTC)
 Strong supportThomanski | t | c | 08:11, 13 November 2020 (UTC)
 Strong support. More editors, more pages, more relevance on Google and everything on its own namespace, which means nothing will change in vanilla documenting. --Dr03ramos (talk) 12:17, 13 November 2020 (UTC)
 Strong support The Great Spring (talk) 12:18, 13 November 2020 (UTC)
 Strong support DEJVOSS (talk) 12:45, 13 November 2020 (UTC)
 Supporting for above reasons Blockofnetherite Talk Contributions 16:59, 13 November 2020 (UTC)
 Strong support okay lets make it happen. James Haydon (talk) 18:18, 13 November 2020 (UTC)
 Strong support Just because story mode is discontinued doesn't mean we shoud treat it differently from Minecraft Earth and Dungeons. it should be given pages for the episodes and mobs, its own mainspace, and more contributors on the story mode wiki project --Minecraft loot (talk) 03:13, 15 November 2020 (UTC)

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

Process[edit]

So, i see great support, and first admin respond, and he has no concerns 🙂, except User groups changes. So, our questions are:

User groups

On MCW Crossover, it has been already discussed, and there was result of re-vote. That will mean, we will start vote about them.

Bot

We can use any bot

When?

Well, best will be as soon, as possible

Content

All it should in Minecraft Story Mode namespace. Its alias should be MCSM?

What do you think? And if there is something to add, add it!

--TreeIsLife (talk) 14:35, 16 November 2020 (UTC)

So basically, what are we doing? Is there a project page? If so, we should have one. Then what do we do? Basically copy paste the content from the fandom? I agree with the namespaces Minecraft Story Mode: and Minecraft Story Mode Talk: , but I am currently undecided on its alias. I personally believe MCSM and MCST are good, although they are 4 characters, but that shouldn't be a major problem at all. Can someone answer these questions, now that this proposal got massive amount of support? Blockofnetherite Talk Contributions 18:02, 17 November 2020 (UTC)
We will not copy paste, that'd lose edit history and alike, instead the pages will need to be exported. Also, IIRC, there's already a project for documenting story mode. Dhranios (talk) 20:23, 17 November 2020 (UTC)
About the user right thing. You said that we'll vote, so let's do it here then. I'd say to create a custom user right that gives content-moderator (read more here) but limited to the MCSM namespace. However, i'm not sure if we should do that. --Dr03ramos (talk) 10:54, 18 November 2020 (UTC)
We said we won't do user groups limited to one namespace, because it will be techically difficult. --TreeIsLife (talk) 12:37, 18 November 2020 (UTC)

Herobrine page[edit]

Hi guys. After suggestion from discussion on Discord about crossover, we ran to problem with a page Herobrine. As Herobrine is community made, but really noticed by Mojang Staff, it makes us thinking, if we should keep this page or not?

What do you think? Do you support deletion, or not? --TreeIsLife (talk) 19:38, 13 November 2020 (UTC)

 Support we already moved most of the mod related pages on this wiki to FTB, so making a wiki for fancontent and community content is a good ides. But it should be for more than just moving already existing pages. James Haydon (talk) 19:42, 13 November 2020 (UTC)
 Neutral, I do not have an opinion on this yet, however, could you supply a link to the discord message on the mcw server? Blockofnetherite Talk Contributions 18:04, 17 November 2020 (UTC)
Strikethroughed because I am no longer neutral and I have also seen the original discord converstationBlockofnetherite Talk Contributions 16:09, 19 November 2020 (UTC)
Switched to  Oppose, at least for now or any time soon, as a Herobrine page is actually useful as Mojang references it, and even references it in the code (no, I am not talking about implementing it), like "4J studios may have removed Herobrine" or things like that. Also opposing for below discussion. Blockofnetherite Talk Contributions 23:39, 18 November 2020 (UTC)
 Oppose for now. If we're making that three main wikis thing I've proposed on MC crossover Discord, we should first have the fan content wiki estabilished and only then move the Herobrine page. --Dr03ramos (talk) 10:57, 18 November 2020 (UTC)
Finally, you remember, that you proposed 3 wikis! --TreeIsLife (talk) 13:34, 18 November 2020 (UTC)
 Oppose deletion. Herobrine is a notable part of Minecraft's history and regularily mentioned in changelogs by Mojang. It shouldn't be removed from the wiki just because it's community-made. Violine1101 (talk) 16:31, 18 November 2020 (UTC)
 Oppose deleting the Herobrine page. The Great Spring (talk) 23:41, 18 November 2020 (UTC)
Seems like a lot of people are against this now. James Haydon (talk) 02:26, 19 November 2020 (UTC)
Yes, but it was not my idea. --TreeIsLife (talk) 06:56, 19 November 2020 (UTC)
Okay based on everyone's reaction i think we might have to re-discuss this over. James Haydon (talk) 05:13, 21 November 2020 (UTC)

Create List of entity textures?[edit]

List of block textures already exist, need to create List of entity textures.-- Xiaoyinface.png Duowan channelT&C) 23:29, 13 November 2020 (UTC)

An observation: "Random Page" is quite unlikely to get anything useful[edit]

Out of 10 tries, I observed exactly one that was about gameplay (Netherite Scrap), one about about a rule (Minecraft Dungeons:rarity), and one about a data file (level.dat) The remainder consisted of two short summaries of not-very-notable employees and FIVE short summaries of specific platform edition numbers. This suggests that there's a lot of room to clean up or combine near-useless pages so the average random page is likely to teach something interesting or spark an interesting session of following links; the cleanup of, especially, the specific platform versions ought to be accessible to a simple script to combine them all, depending on what tech underlies the wiki. --Realweregamer (talk) 03:57, 14 November 2020 (UTC)

I suggested it to be Special:Random, not SP:RandomRootPage, though it has mostly the same issues, probably ending in a /DV or some other technical page, possibly remove it?Humiebeetalk contribs 23:30, 16 November 2020 (UTC)
Yes, Special:Random does give version articles a lot, but that's not a bad thing, because there are a lot of version numbers. They shouldn't be combined because each version article can contain a lot of content. Special:Random isn't meant to be "useful", and there are index pages for them like Version history.  Nixinova T  C   23:45, 16 November 2020 (UTC)
The link uses Special:RandomRootPage which excludes subpages. Some of these subpages are considered to be articles e.g. Java Edition version history/Development versions but others are like templates (e.g.Dirt/BS) We should move all article subpages to root pages or move all non-article subpages into template namespace and reconfigure the link so that it could link to subpages. This won't fix the problem entirely, but it could help. Also, why is it called "Random page" instead of "Random article"? Fadyblok240 (talk) 00:56, 21 November 2020 (UTC)

Make some templates more reader-friendly[edit]

Some templates such as {{more images}} and {{infobox}} without an an image parameter cause unnecessary clutter for readers. Since only registered users can upload files, readers cannot address the problems presented by these templates. To provide a cleaner look for some articles, I propose moving templates like {{more images}} to talk pages or hiding them from readers by using a CSS class. For infoboxes, removing the placeholder image at least for readers would reduce whitespace. Also, the {{delete}} template has a "delete" link that only administrators can use, so I am considering hiding it from non-admins, which also requires a CSS class. Fadyblok240 (talk) 00:26, 22 November 2020 (UTC)

Hiding content with CSS is generally not a good idea and preferably avoided. For one, Google finds it anyway, and this might incur SEO penalties. While most readers never become editors, and it's unlikely such templates get a lot of readers make their first uploads, I feel it's not the best idea in terms of "wiki way" to hide content from unregistered users. In addition, I'm not sure there are easy CSS classes to do things based on group preferences, so that might need to be spread across multiple CSS files (MediaWiki:Group-sysop.css). (Note also delete links are useful for SOAP and maybe even WMs/staff, who also might need to act on deletion templates, but aren't necessarily local admins. This means the link would need to be hidden based on user rights, not group membership, which I'm not sure can be done easily.)
In other terms,  Oppose the presented solution, doesn't seem like a substantial problem, but incurs other problems and seems to require a rather complicated solution.
As an additional idea, maybe move editor-facing message boxes like {{more images}} to the bottom of pages? --AttemptToCallNil (talk) 01:25, 22 November 2020 (UTC)
 Oppose moving notice templates to the bottom of pages becuase then editors would not even see the notice template at all. If possible, notcie templates can be hidden from ip's as readers would probably not register an account without editing. What is the "wiki way" anyways? As for the orginal proposal, I am  Weak oppose per AttemptToCallNilHumiebeetalk contribs 02:36, 25 November 2020 (UTC)
By "wiki way" here I meant the idea that editing should be open to unregistered users, and they should be treated as potential editors instead of just readers. --AttemptToCallNil (talk) 02:57, 25 November 2020 (UTC)
True, though a possible solution is to do it based on edits. 1 edit means ips AND users are able to see notice templates. This shows that they are an editor.Humiebeetalk contribs 03:03, 25 November 2020 (UTC)

Convert some disambiguation pages into broad concept articles (again)[edit]

This got archved but I don't really feel like closing it. To continue, ai  Support doing this AND I have revamp the netherite article. Fadyblok240, you  Should start turning the pages into broad concept articles.Humiebeetalk contribs 01:59, 25 November 2020 (UTC)

Cleanup of the docs of Bedrock Edition add-ons articles: Request 1[edit]

I want to contribute by fixing up all the scripting and layouting of articles related to add-ons and the Bedrock Edition add-on/resource pack/behavior pack documentation. My first request is a page split of the Bedrock Edition scripting documentation as there is a lot of information there. I said the following on the talk page of that article:

I am suggesting that we split these into separate pages under the Bedrock Edition scripting documentation umbrella. This is because programming documentation has a lot of headings, subheadings and such, this page is really diving deep. So I suggest the following:

Feel free to share any thoughts on this.

Or maybe some other way to fix that particular article, as there is no style guide that is related to programming, let alone JavaScript documentation (according to my knowledge). YivanGamer (talk) 06:41, 3 December 2020 (UTC)

Readd Pi Edition history to pages[edit]

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

Originally this was removed due to Pi Edition being discontinued. However, Console and 3DS editions have also been discontinued, yet history information for these is kept on pages, so should Pi Edition info make a return to pages it applies to? - User-12316399 (talk) 01:32, 4 December 2020 (UTC)

 Strong support yeah this makes no sense Oreli (talk) 01:40, 4 December 2020 (UTC)
I  Oppose because Pi Edition was just one, unlike Console and 3DS which had many more. All the info for Pi Edition can be seen on its main article, so this would be pointless. Thejoaqui777 (talk) 02:14, 4 December 2020 (UTC)
Agree with joaqui Nixinova T  C   05:19, 4 December 2020 (UTC)
Pi edition was literally just an adapted version of pocket edition alpha 6.1.0, so its not really even its own edition. James Haydon (talk) 05:24, 4 December 2020 (UTC)
 Oppose per Thejoaqui777. The Great Spring (talk | contribs) 05:28, 4 December 2020 (UTC)
 Weak Oppose for above reasons. I have Pi edition and know that there is barely anything there. Blockofnetherite Talk Contributions 17:22, 4 December 2020 (UTC)
 Stongest oppose that i have ever opposed
  1. It never got updated
  2. It would be extremely inconvenient
  3. All the info is on pi edition page
Just noHumiebeetalk contribs 17:28, 6 December 2020 (UTC)

Ray Tracing[edit]

  • Shouldn't we have a article on ray tracing.
  • It is a feature of more light and smooth light and all that sort of stuff.
  • For more information go to Minecraft.net and look at articles that have RTX or ray tracing in them.
  • to get started here is one. https://www.minecraft.net/en-us/updates/ray-tracing
  • from --73.89.66.98 18:12, 10 December 2020 (UTC)

Redirect capitalization[edit]

Currently, we are allowed to make lowercase redirects that point to their uppercase articles. However, it is unclear whether we should create uppercase redirects to articles with lowercase titles. Is it okay to create such uppercase redirects, since when someone tries to go to an uppercase form of the same article, they go to the search page instead of directly to the lowercase article. Blockofnetherite Talk Contributions 19:01, 8 December 2020 (UTC)

Per the style guide, alternate capitalization redirects are allowed. Dhranios (talk) (Join the wiki videos project!) 19:04, 8 December 2020 (UTC)
Okay thanks, but was there a time before UCP where "uppercase is redundant to lowercase," where uppercase was not needed because the system already redirected? I feel like that has changed since UCP. Blockofnetherite Talk Contributions 19:10, 8 December 2020 (UTC)

Inventory Template in Snapshot and releases Pages[edit]

I wanted to add to the snapshot pages some Images of all the things added in that snapshot, using the Inventory template, I already done that to a lot of pages, and it looks pretty good aesthetically, in the case I don't get the permission here to do that I will undo that, Am I allowed to do that? RondiMarco (talk) 18:13, 13 December 2020 (UTC)

Per this discussion,  Neutral. The Great Spring (talk | contribs) (Tagalog translation) 13:18, 14 December 2020 (UTC)
  • Seeing the discussion there the concensus wasn't reached, so it is worth to discuss this again. However that discussion used the same format of what we are doing currently at "Planned additions" on the Caves & Cliffs article, and what RondiMarco did is add just the inventory template. I  Support this because it's a little summary of additions with another format, so I don't find a problem there, because it's just visual, and for development versions the things there were just adittions, not changed ones. Thejoaqui777 (talk) 18:03, 15 December 2020 (UTC).
    Edit: Also with visual is that they don't make the page look cluttered and are an easy link to the blocks and items articles. Thejoaqui777 (talk) 18:07, 15 December 2020 (UTC)
Changed to  Support. TheGreatSpring (talk) 03:21, 27 December 2020 (UTC)

More Facts In Did You Know...[edit]

On the main page, the Did You Know... section always has the same 5 facts. I think it would be neat if there was a large pool of random facts and every time the page loads, it picks a random 5 from that list. Any thoughts would be appreciated! || Remember this thing? Nether Reactor Core BE1.png Because I do. --Ninji2701 03:17, 27 December 2020 (UTC)

The did you know relies on a certain template, Template:DidYouKnow. It does not always have the same facts, it refreshes every day. There are not 5 facts, here are all the facts. If you want to add more facts, you can add them in the editcopy. Keep in mind you can edit the editcopy and add what you think is good, but it will not show up on the front page until an admin decides they belong there. Blockofnetherite Talk Contributions 04:45, 27 December 2020 (UTC)
Oh, cool! I guess this topic is totally irrelevant then. || Remember this thing? Nether Reactor Core BE1.png Because I do. --Ninji2701 13:50, 27 December 2020 (UTC)

Repurpose[edit]

I personally think that the template should show more than 5 facts. It could show 7 facts instead of 5. The reason is that the Minecraft Wiki/editcopy page shows too few facts on the template, so if we increase a little bit the amount of facts this can be solved. Thejoaqui777 (talk) 23:12, 18 March 2021 (UTC)

Moving the remaining orientable block renders to use the current naming system[edit]

Currently just about all blocks which can connect (e.g. iron bars, redstone wire) or be oriented (e.g. furnaces, pistons) directionally share a consistent naming system. However, a notable exception is blocks with log orientation, which still use an Axis orientation. I've marked all of these for moving but have been instructed to ask about this here.

Advantages of moving:

  • More consistent with other block files with directional placement
  • Considerably easier to memorise as a result (with few exceptions, all block renders have north-west as the upwards direction, meaning up-left is west and up-right is north; with the Axis naming you'd need to also consider which axis corresponds to which direction, which wastes time and also changed throughout the game's history)
  • Has allowed some remaining files which didn't follow the remaining parts of the naming scheme to be identified and fixed

Disadvantages of moving:

  • Not consistent with the block's actual block state naming (probably not relevant as if we were to keep to being completely consistent with block states, rails for example would have to be moved to names such as "Rail Shape North South JEx BEy")

Other things to note:

  • Some blocks had an "Axis None" orientation Chiseled Quartz Block Axis None BE1.png Chiseled Quartz Block Axis None BE2.png Quartz Pillar Axis None BE1.png Quartz Pillar Axis None BE2.png Purpur Pillar Axis None BE1.png Purpur Pillar Axis None BE2.png Hay Bale Axis None JE1 BE1.png Hay Bale Axis None BE2.png Bone Block Axis None BE1.png Bone Block Axis None BE2.png and their new file names after this unification may be unclear. However, this exact same thing affects some files which already use the intended new naming scheme Hexahedral Piston.png Hexahedral Sticky Piston.png Weird Piston.png, so this is likely worth a separate, smaller discussion.
  • Whether this move is or isn't worth the time/effort is effectively irrelevant, as the move templates will need to be deleted from several talk pages anyway, which would take roughly the same amount of time and both outcomes will likely be performed by a bot/other form of automation anyway

Are there any good enough reasons this move shouldn't go ahead? - User-12316399 (talk) 13:27, 30 December 2020 (UTC)

I personally think we should follow the block states. Writing them out fully is not needed (EG drop the "Axis" from the current files), but we should not change the naming completely. What bothers me right now, for example, is the cauldrons "Cauldron (moderately filled with water)" (instead of "Water Cauldron Level 2" (level can be dropped per previous sentence)), which is absolutely nothing like the actual state of the block. Your rail example (Rail Shape North South) could be simplified to Rail NS, that would still follow the block states, just using a shorter variation.
This "and also changed throughout the game's history" has never actually happened, it was correcting where the sun came from, the axis themselves weren't changed, and never will.
Keep in mind that being aligned to the north-south axis is not the same as facing north or south. Dhranios (talk) (Join the wiki videos project!) 19:38, 30 December 2020 (UTC)
Just got an issue with the naming system that you're trying to apply. For rails, is Ns ascending north, or ascending south? Changing the rail file links from Ns nS Ew and eW to A<letter> for "Ascending <direction>" it is a lot more clear which is which. Dhranios (talk) (Join the wiki videos project!) 21:41, 30 December 2020 (UTC)
Lowercase is the ascending direction - the same logic applies here for redstone dust. - User-12316399 (talk) 14:18, 31 December 2020 (UTC)
It's also logical to think "uppercase is where it does up". Dhranios (talk) (Join the wiki videos project!) 20:21, 31 December 2020 (UTC)
Wouldn't that still be the same thing? – Unavailablehoax (talk) 20:26, 31 December 2020 (UTC)
No, see the redstone dust, which he compared it to, uppercase is not up directions File:Active Redstone Wire (EW).png File:Active Redstone Wire (ew).png. Dhranios (talk) (Join the wiki videos project!) 20:28, 31 December 2020 (UTC)

Consistency in "Pre-Release" Capitalization[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
Article titles should follow the official name. Pre-release and Pre-Release spelling appear in different dates. However, feel free to create redirects from r -> R and vise versa.Humiebeetalk contribs 21:25, 10 January 2021 (UTC)

While editing the server.properties page, I noticed that there is considerable inconsistency in how "Pre-Release" is capitalized across the wiki. Some pages choose to uppercase the "R" in "Release", some do not. Some choose to redirect the opposite case, some do not.

For example, 1.14.4 Pre-Release 1 is an uppercase "R" and trying to navigate to "1.14.4 Pre-release 1" fails. On the other hand, 1.16.4 Pre-release 1 is a lowercase "r", and trying to navigate to "1.16.4 Pre-Release 1" similarly fails. Some pages (e.g. 1.15 Pre-release 5) have a redirect but many do not. The net effect of this is that editors have no idea which capitalization is "correct", or even which one will work correctly. It leads to overall inconsistency and unnecessary redirects across the Wiki.

My suggestion is for the Wiki to come to a consensus on which capitalization should be used. Personally, I feel that "Pre-Release" with an uppercase "R" should be preferred, as that is what Mojang uses in its official communications. Once consensus is reached, incorrect pages should be moved to the correct title, and any errant capitalization in article bodies fixed.

AMNOTBANANAAMA (talk) 23:48, 5 January 2021 (UTC)

The name of pre-releases follow the name in-game, so  Weak oppose The Great Spring (talk | contribs) (Tagalog translation) 23:50, 5 January 2021 (UTC)
If the decision is to prefer "pre-release" as the page names I am fine with that, as long as it is consistent. The current inconsistency is my primary concern, ultimately which one is chosen is less important to me. AMNOTBANANAAMA (talk) 00:01, 6 January 2021 (UTC)
For example, if you want to put this at the start it would be

1.16.4 Pre-release 1 (known as 1.16.4-pre1 in the launcher) is the first pre-release for Java Edition 1.16.4, released on October 15, 2020, which adds the social interactions screen and fixes two bugs.

1.16.4 Pre-release 1 (known as 1.16.4-pre1 in the launcher) is the first pre-release for Java Edition 1.16.4, released on October 15, 2020, which adds the social interactions screen and fixes two bugs.

instead of

1.16.4 Pre-Release 1 (known as 1.16.4-pre1 in the launcher) is the first pre-release for Java Edition 1.16.4, released on October 15, 2020, which adds the social interactions screen and fixes two bugs.

1.16.4 Pre-Release 1 (known as 1.16.4-pre1 in the launcher) is the first pre-release for Java Edition 1.16.4, released on October 15, 2020, which adds the social interactions screen and fixes two bugs.

The Great Spring (talk | contribs) (Tagalog translation) 00:10, 6 January 2021 (UTC)
We follow the in-game names, so they are not to be moved. However, feel free to make redirects for the opposite capitalization. Dhranios (talk) (Join the wiki videos project!) 09:32, 6 January 2021 (UTC)

Splitting PS4 history[edit]

Recenty, RondiMarco splits the PS4 part from the LCE section without discussion. Can we split the PS4 part or not? Any thoughts? The Great Spring (talk | contribs) (Tagalog translation) 12:11, 6 January 2021 (UTC)

 Neutral, while it is done the same with PE and bedrock, PS4 is a legacy console edition, as it was also replaced by bedrock. I don't see harm in doing it this way, nor harm in reverting it. Dhranios (talk) (Join the wiki videos project!) 12:13, 6 January 2021 (UTC)
 Oppose PS4 is part of LCE, no reason to split its history.  Nixinova T  C   19:29, 7 January 2021 (UTC)
 Comment I get your point, but the PS4 edition outlasted all the other Legacy Console editions, and was the only legacy console version to have the Texture Update. James Haydon (talk) 19:32, 7 January 2021 (UTC)
Barely, only for like 10 updates.  Nixinova T  C   21:27, 10 January 2021 (UTC)
True, they only spanned 1.14, or Bedrock Edition 1.8.0 - 1.13.0.Humiebeetalk contribs 21:30, 10 January 2021 (UTC)
 Weak support becuase of consistancy with pe and be but it is part of lce and is diffferent than pe and be as they are separated until the Better Together Update but ps4 IS part of lce. Idk, I would keep it though.Humiebeetalk contribs 21:45, 30 December 2020 (UTC) 22:21, 7 January 2021 (UTC)

Something discussing renewability of the Lava Bucket and other items that are not renewable in snapshots but are going to be in the full release[edit]

Yes, I know that the ip constantly got reverted for changing it, they did have a good point but the wiki uses current status, not upcoming status. The ip got reverted with understandable edit summaries and I personally would revert the ip. They were doing it in good-faith though. Something odd about that is that the template is the {{upcoming}} template, implying that the thing that is upcoming IS upcoming in <version>. In the case of 1.17, the full release. Now the wiki trys to be as informative as possible and trys to give the reader a clear understanding. In my opinion, I am  Semi-weak support. It would be confusing for the reader if they watched like say for example, xisumavoid and went to the minecraft wiki. They would notice that the renewability of lava buckets would be incorrect, misleading the reader. Note that I mean No‌[until JE 1.17]/Yes‌[upcoming: JE 1.17] Any thoughts?Humiebeetalk contribs 22:35, 7 January 2021 (UTC)

The same can be said the other way around. If we end up saying yes in 1.17, while it's not in the snapshots yet, people who open the snapshots will be presented with misinformation.
It's better to stick with the current latest release and snapshot info, not the whole planned update. (Plans can change, after all...) Dhranios (talk) (Join the wiki videos project!) 23:33, 7 January 2021 (UTC)
True... but it would be more helpful in general becuase more Java Edition players use Java Edition 1.16.4 than 21w18a.Humiebeetalk contribs 23:37, 7 January 2021 (UTC)
For those people, those templates don't really concern them. When the update releases, they'll check the update page instead and go from there. Dhranios (talk) (Join the wiki videos project!) 23:40, 7 January 2021 (UTC)

Wanted Page: Moving minecart[edit]

The minecarts that move are supposed to be mobs / entities, right? -THENOMNOM (talk) 00:26, 11 January 2021 (UTC)

Yes. They are entities. TheGreatSpring (talk | contribs) (Tagalog translation) 00:28, 11 January 2021 (UTC)
Minecarts themselves are already entities. Moving minecrafts are no different, just that they are moving, similar to a player walking. So no need for a new pageHumiebee (talk) 00:39, 11 January 2021 (UTC)
Exactly, in the same way as evoker fangs. They only damage they player and have no real behavior nor do they interact with them. James Haydon (talk) 00:51, 11 January 2021 (UTC)

5000 content pages milestone[edit]

I just wanted to say that I noticed, as of now, Special:Statistics lists exactly 5,000 content pages on this wiki. Amatulic (talk) 03:00, 16 January 2021 (UTC)

I noticed that a few days back, so you aren't the first to see this. James Haydon (talk) 04:02, 16 January 2021 (UTC)
BDJP007301 created the 5000th article yesterday. Also, does this also includes deleted pages? TheGreatSpring (talk) 04:22, 16 January 2021 (UTC)
It does not, hence why it has become this milestone several times already. Dhranios (talk) (Join the wiki videos project!) 05:53, 16 January 2021 (UTC)
Well there are subpages of articles which are not articles (many of them are templates only meant to be transcluded on one page) which are counted as articles, which means there are probably less than 5,000 "proper" articles. (Note that redirects, project pages, template pages, category pages, file pages, user pages, etc. are not counted as articles. )Fadyblok240 (talk) 17:36, 21 January 2021 (UTC)

Should Caves & Cliffs features in Bedrock Edition be considered from 1.17.0 or from 1.16.210 in history sections[edit]

There's a bit of a inconsistency with Caves & Cliffs features in added in the betas of 1.16.X in the form of Experimental Gameplay, for example, this is the history section for pointed dripstone:

Upcoming Bedrock Edition
1.17.0beta 1.16.210.56Pointed Dripstone Base (D) JE1 BE1.png Pointed Dripstone Middle (D) JE1 BE1.png Pointed Dripstone Frustum (D) JE1 BE1.png Pointed Dripstone Tip (D) JE1 BE1.png Pointed Dripstone Tip Merge (D) JE1 BE1.png
Pointed Dripstone Base (U) JE1 BE1.png Pointed Dripstone Middle (U) JE1 BE1.png Pointed Dripstone Frustum (U) JE1 BE1.png Pointed Dripstone Tip (U) JE1 BE1.png Pointed Dripstone Tip Merge (U) JE1 BE1.png Pointed Dripstone Frustum (up texture) JE1.png Added pointed dripstone.

However, this is the history section for goats:

Bedrock Edition
1.16.200beta 1.16.200.52Goat JE1 BE1.png Goat JE1 BE1.png Added goats and kids, which are available only via Experimental Gameplay.
Goats make the sound of a player being hit.
Goats currently uses the vex's charging sound as a placeholder when preparing to ram charge.[1]
releaseGoats have been made inaccessible in the full release.
Upcoming Bedrock Edition
1.16.210beta 1.16.210.51Goats now only drop 2 goat horns each.
Goats now drop 1-2 mutton.
Goat (one horn) BE1.png Goat (no horn) BE1.png Goats now show missing goat horns in the model.
Baby goats now have half knockback when using a ram attack.
Goats no longer attack armor stands.[2]
Goats now attack shulkers.
Goats now only produce one baby goat at a time when breeding.
beta 1.16.210.53Goats now avoid walking onto powder snow while path-finding.
  1. MCPE-104156
  2. MCPE-104159 – "Goat attacks armor stands" – resolved as "Fixed"

Notice how the former shows the features as a part of 1.17.0, while the latter shows it as part of 1.16.200 and 1.16.210. I prefer the former option as the Caves & Cliffs features added in the betas of 1.16.X don't end up in the full release, but instead will be a part of 1.17.0.

Unavailablehoax (talk) 23:36, 26 January 2021 (UTC)

I  Support to use the first, because the features won't be part of 1.16.x releases, and it's more specific. Thejoaqui777 (talk) 23:54, 26 January 2021 (UTC)
They are part of the 1.16.210 betas, and it should be declared that way. Saying the beta is for 1.17 is false information. Dhranios (talk) (Join the wiki videos project!) 00:16, 27 January 2021 (UTC)
Should say 1.16.210, with "added under experimental gameplay", then 1.17 with "fully implemented".  Nixinova T  C   00:26, 1 February 2021 (UTC)

Proposal for a Crossovers page, replacing the current Smash page[edit]

I talk about this more on Talk:Super Smash Bros. Ultimate, but since that page doesn't get much traffic for obvious reasons, I thought I'd bring it up here.

My argument boils down to it making more sense than adding a new page for every game that references Minecraft, and being more consistent to what Wiki readers might expect and enjoy. Thoughts? -- DigiDuncan (talk) 00:14, 1 February 2021 (UTC)

Articles about Mojang employees: A proposal[edit]

Reviving both this discussion from 2015 and this discussion from 2019-2020, I feel like it should finally be time to take action regarding articles about Mojang employees, whether they are notable or not. I'm using the Wikipedia policy on biographies of living persons as a blueprint for this, so bear with me here.

  • We should try to include as much information on employees that is publicly available through reliable sources, whether it be through LinkedIn profiles, interviews with publications such as news sites, or simply through the Twitter accounts of the employees themselves. As long as the information is available publicly, it should be documented on the wiki, sourced back to the article or tweet in question.
  • However, there has to be a limit as to what information should indeed be allowed on here. Of course, its general understanding that emails, addresses, and phone numbers are never to be added to articles out of respect for privacy. In regards to concessions that have been made in the past, such as the situation with Ez, or retracting information that had been OK up until recently, such concessions should be reviewed as to whether they should remain as is, or be considered null and void pending as to when this policy does become active.

Understanding that this is a style guide policy, I figured it would be best to instead post it here, considering that this policy would cover several hundreds of employees of one company.

The proposed change to the policy is as follows, which would be separated from the "Notability" section and split into its own section (new additions in bold):

Articles about people are only allowed if the person in question is a developer of Minecraft and/or either a part of or closely related to Mojang Studios. The article should cover information about the person that is publicly available through reliable sources, and should remain neutral and fair to the person. Self-published sources, such as tweets or books, are not allowed unless the person is the one who authored or published it. Edits to the article about the person may be reverted / deleted if they contain phone numbers, email, or postal addresses.

Articles about people are only allowed if the person in question is a developer of Minecraft and/or either a part of or closely related to Mojang Studios. The article should cover information about the person that is publicly available through reliable sources, and should remain neutral and fair to the person. Self-published sources, such as tweets or books, are not allowed unless the person is the one who authored or published it. Edits to the article about the person may be reverted / deleted if they contain phone numbers, email, or postal addresses.

This is just a stepping stone. I am open to any additional input regarding any further changes to this. BDJP (t|c) 19:19, 2 February 2021 (UTC)

I still think this should be taken further, and say that articles should only exist for notable employees where the majority of the content is about their work. We shouldn't encourage going into details about personal lives and such, which having all these stub articles does.  Nixinova T  C   19:29, 2 February 2021 (UTC)
Definitely keep the personal life stuff to a minimum at best. BDJP (t|c) 20:42, 2 February 2021 (UTC)
In my opinion, we should keep any pages that have a lot of content (pages without stubs) but pages with stubs should be put into like a draft. Anyone is free to make a page but it needs more content. As for not having like personal details, I also support that but a notable exception would be Helen Zbihlyj as she directly put a little bit of her personal life on her user page as it is a primary and the most reliable source possible. I would like the employee pages to also have more about their work as well and all those stub articles can be clumped into an Employees article.
All in all, I  Support keeping all pages which have enough content and  Removing or converting any pages with a stub and have no content (for instance, Peter Hont which is just one of the many pages that has no info, only saying that they work in Minecraft Dungeons.) For birth dates, I really don't see any harm if they posted it on twitter or some other social media thing. Also I wish to  Remove all pages with no sources as well.Humiebee (talk) 21:35, 2 February 2021 (UTC)
I’ve created an example of how an expanded article would look here. BDJP (t|c) 01:02, 9 February 2021 (UTC)
I  Support the revised article.Humiebee (talk) 03:05, 15 February 2021 (UTC)
I'm going to wait on any further comments for a week, but if there are no further objections then I will implement this on the bio page. BDJP (t|c) 14:36, 19 February 2021 (UTC)
Support the new proposal, but it would make absolutely no sense for the new guideline to be part of the style guide but not part of the notability guideline. What about splitting the notability guidelines from the style guide? Fadyblok240 (talk) 23:12, 19 February 2021 (UTC)

Request for a new page - but I need your help[edit]

I want to create a new page that lists from the longest name for an item to the shortest name, but I don't know how should I create it. I hope you can help me. - Melvintnh327 (talk) 05:04, 7 February 2021 (UTC)

It is unnotable to be given an article. TheGreatSpring (talk) 05:28, 7 February 2021 (UTC)
It is completely trivial information, so it doesn't belong anywhere on this wiki, except perhaps a subpage of your userpage. Fadyblok240 (talk) 05:40, 7 February 2021 (UTC); updated 06:12, 7 February 2021 (UTC)
Okay then...I guess I would not create it - Melvintnh327 (talk) 02:23, 11 February 2021 (UTC)

Are pufferfish passive, neutral or hostile[edit]

Personally, I think that pufferfish are passive because they can't chase you but some users change "Passive" to "Neutral" or "Hostile". Are pufferfish passive, neutral or hostile? TheGreatSpring (talk) 08:08, 7 February 2021 (UTC)

Per Talk:Pufferfish#Pufferfish behavior, we stated that they are passive, so I think that they should stay as Passive. Thejoaqui777 (talk) 22:55, 7 February 2021 (UTC)

What happened?[edit]

The wiki stopped working for some time. Why? Gameking1happy (talk) 16:40, 11 February 2021 (UTC)

Another glitch with UCP, this is the worst one so far. James Haydon (talk) 16:41, 11 February 2021 (UTC)
Fandom rolled out an update that broke the platform. They quickly rolled it back though.
While they were rolling it back though, Minecraft Wiki played the roles of: 1) London Bird Club Wiki; 2) Wookieepedia; 3) the Pixel Gun Wiki and the Game of Thrones Wiki simultaneously. Oh, and half the platform was the Raft Wiki for a few moments. --AttemptToCallNil (talk) 16:58, 11 February 2021 (UTC)
I don't think there even is a Game of Thrones wiki on Gamepedia because its not a game. So it also is affecting FANDOM wikis as well. James Haydon (talk) 17:01, 11 February 2021 (UTC)
Yes, it affected the entire platform, including all Fandom wikis. --AttemptToCallNil (talk) 17:04, 11 February 2021 (UTC)

Minecraft Story Mode NS[edit]

Hi

We already discussed about Minecraft Earth and Minecraft Dungeons namespaces, but i think we still miss "Minecraft: Story Mode" namespace. This namespace was already discussed in "Moving Minecraft Story Mode Wiki to this wiki", but as Minecraft Story Mode Wiki discussion was really not great, and it failed, we were exploring possibility of exporting articles from "Fandom's Minecraft Wiki". But unfortunately, these will also need rewrite. So, articles are created manually, as stubs, which will need to expand.

So, we have to create these articles by ourselves. Unfortunately, we won't be able to beat Minecraft Story Mode Wiki, until we will have own namespace, and own production of articles.

On Google, we ended really far from top, on 5th place. On Bing, we were more successful, reaching 3rd, but on both searches, MC Story Mode Wiki was on top.

So, should we create Minecraft Story Mode NS?--TreeIsLife (talk) 19:05, 13 February 2021 (UTC)

 Support We have pretty bad situation, on Google, even Fandom's MCW has higher ranking, so we are in bad situation --TreeIsLife (talk) 19:05, 13 February 2021 (UTC)
 Temporal oppose, let me explain. It has been some months since the discussion, but I think that we should contact first their admins. I don't want them to think that we try to compete with them, instead to colaborate. Your words look very competitive, which isn't how this wiki wants to get information. We talk with people, and try to get a deal with them to make both parts happy. So, I think that we should wait 2 months more at least to begin talking with them again, because they refused to merge due to bad communication. Thejoaqui777 (talk) 19:21, 13 February 2021 (UTC)
 Comment TreeIsLife, I agree with Thejoaqui777, why are you making this a competition? MC wiki isnt a promotion wiki. Minecraft Story Mode is a WIP and the Minecraft Story Mode in FANDOM is fine, what makes you think that MC wiki is a promotional wiki? I also  Oppose per my comment on the previous discussion. I'm fine with the namespace but not trying to outmanuver fandom, gamepedia is owned by fandom anywaysHumiebee (talk) 19:25, 13 February 2021 (UTC)
This, this, this, this, this, this and this. It's not a competition. This exact behavior is what made the initial merge proposal fail badly. Dhranios (talk) (Join the wiki videos project!) 19:33, 13 February 2021 (UTC)
 Comment to all. This is not about competition. We tried... but... it did not go well. Hummie may not know about that, but there is great server, called Minecraft Wiki Crossover, where we discussed future of MC Wikis (all of them). We had a big dream. 3 big wikis for everything Minecraft - Minecraft Wiki, Minecraft Community Wiki and Minecraft Mods Wiki. And, we wanted to start with merging of all wikis from "Minecraft Wiki Network" into this wiki. Anddddd... I created discussion post, and we had protest on that wiki. I was critized about how i wrote it, and that i wrote it into discussions. Then, i decided i will left server, and do discussion by myself. So great, i had another conflict on another wiki (double problem). Unfortunately, discussion just failed and that's it. And now everybody hates me 😔. That was joke, obviously, I said it was my fault, and we discussed we won't say nothing to community, until we will lock the wiki (meaning only discussing with admins). And now, let's say why i want to do this. Well, they are inactive and only 1 person said something, but his timestamp between answers were 1 week.--TreeIsLife (talk) 19:41, 13 February 2021 (UTC)

Minicraft?[edit]

There are 5 Minecraft games: Minecraft, Minecraft Story Mode, Minecraft Earth and Minecraft Dungeons and, Minicraft. They all have page(s) other than Minicraft witch only has 1 reference on the whole wiki. I think Minicraft should have a page, if not may pages for the things in the game (mobs, items, etc). --Gtbot2007 (talk) 22:22, 13 February 2021 (UTC)

 Weak oppose this wiki is about Minecraft. TheGreatSpring (talk) 23:04, 13 February 2021 (UTC)
 Comment Well, 0x10c has its own wiki page, and yet it isn't a minecraft related game, it was developed by mojang, but wasn't really minecraft-like. James Haydon (talk) 23:23, 13 February 2021 (UTC)
 Comment But it was made by Notch, and has a lot of things from Minecraft (such as creepers), even the name is based on Minecraft --Gtbot2007 (talk) 23:53, 13 February 2021 (UTC)
Minicraft already has a page, but it is a redirect. Fadyblok240 (talk) 01:26, 14 February 2021 (UTC)
I guess because it wasn't developed by mojang unlike 0x10c and it wasn't nearly publicized as much. Makes sense why it doesn't have its own page. James Haydon (talk) 01:30, 14 February 2021 (UTC)
Redirects are pages too. Fadyblok240 (talk) 02:58, 14 February 2021 (UTC)
@Fadyblok240: By page I meant articles, no need to correct me about that. James Haydon (talk) 18:41, 14 February 2021 (UTC)
But its a minecraft game unlike 0x10c
 Comment The reason I felt the need to create the 0x10c page is because, unlike other games made by Notch or Mojang, you can't actually play it because it never came out, and so it doesn't have a wiki of its own (not anymore anyway). Now, on the other hand, Minicraft is a game you can play and it does have its own wiki, but, keep in mind, it is technically an official Minecraft spinoff game, and all the other official Minecraft spinoffs get to be on this wiki, so why not that one too? Plus the Minicraft wiki is really messy and incomplete, so I definitely wouldn't be opposed to something better being added to this wiki. AlienAgent124 (talk) 03:08, 14 February 2021 (UTC)
This is what I mean --172.58.228.82 09:27, 14 February 2021 (UTC)

Pocket/Bedrock Edition version pages[edit]

As the title, the Chinese Wiki is also disussing the same problem. See here.

Here, the problem is slightly different. It's mainly about {{version nav}}.

The documentation doesn't mention the usage of parameter {{{internal}}}. The number filled in this parameter shouldn't called "Internal version no.", and it should be "Full version no.". The correct "Internal version no." is a long string of numbers in file AndroidManifest.xml or in something else. "Full version no." is also in the file. For example, the Internal version no. of Pocket Edition 1.1.3 is 871010352 and the Full version no. is 1.1.3.52. Some of the pages on the Wiki need to split according to this, because we found that some apk files of very old version that shows the same Full version no. but they have different Internal version numbers.

About the articles, Style guide says that "naming specification is currently under discussion", but it was shelved obviously. Some version pages is different from the naming specification it stated. Also, MCW:SG/V needs to update.

In addition, The Chinese wiki is discussing renaming Bedrock/Pocket Edition version articles, and we are having an argument about if development versions should have "beta" or "alpha" on their names. Some people think that "the version number is for distinction", and they suggest to delete all the parts in the title that are not useful for distinction, include "alpha/beta" and "v" (the abbreviation of word "version"). Articles like "Bedrock Edition 1.16.210.59" or "Pocket Edition 0.10.0.b9" is enough to explain it's a development version, does not need to be like "Bedrock Edition beta 1.16.210.59" or "Pocket Edition v0.10.0 alpha build 9". The articles don't need to be exactly the same as shown in game, just like we don't name the page Java Edition 21w06a "Java Edition Minecraft 21w06a/snapshot".

If we changed the articles, the parameter {{{title}}} and {{{protocol_manual}}} of {{version nav}} also need to be changed. Do you think it's necessary?--SkyE | Talk · Contributions · Logs 08:00, 14 February 2021 (UTC)

Necessary, no, but it is a change I'd support. The only thing is that bedrock's beta builds aren't as distinguishable from the full build, compared to java's snapshots; betas only have 1 additional ".X", unlike snapshots which use a vastly different naming altogether. Dhranios (talk) (Join the wiki videos project!) 08:36, 14 February 2021 (UTC)
Oppose new naming scheme (the example given isn't actually relevant, the "/snapshot" isn't part of the version), and "beta" is useful for disambiguating. "The articles don't need to be exactly the same as shown in game"; they are though. Support parameter rename.  Nixinova T  C   18:55, 14 February 2021 (UTC)
Although the existence of "alpha/beta" , "v" , parentheses and spaces have certain significance, it's not so significant as to benefit from changing the title. Now the whole title is long and scattered. According to what you said, "it is useful for disambiguating". But most of the time, the correct page cannot be found. In daily communication, few people would say "beta 1.16.210.59", most people would say "1.16.210.59" directly. Personally, I’m used to find pages directly with URLs instead of search functions. If the users who don’t know much about Wiki type an extra space or a wrong letter, and then find that the page does not exist, they won't know what to do (for example, I want to find "Bedrock Edition beta 1.16.210.59" but input "Bedrock Edition v1.16.210.59" or "Bedrock Edition 1.16.210.59"). If you ask "Why not use the search function?", if the title is changed to "Bedrock Edition 1.16.210.59", wouldn't the search function still be useful? Without various prefixes and suffixes, wouldn't the search efficiency be higher?--SkyE |  Talk · Contributions · Logs 13:24, 16 February 2021 (UTC)
 One more problem. Word "alpha" was not shown since 0.14, can we recognize that versions from 0.14 to 0.16 belong the Alpha development stage? --Lxazl5770zh.admin) 14:47, 17 February 2021 (UTC)

Some current issues[edit]

Even if there is no need to change the naming specification, some Pocket Edition/Bedrock Edition pages still have problems.

  • Bedrock Edition 1.2.13.60 and Bedrock Edition 1.2.16 are two different versions. They just updated the same things and are in the same changelog on the Minecraft feedback website. The correct process is: First, Mojang changed the version number in the source code to 1.2.13.60 and released a version. This version didn't compile for iOS. Then Mojang changed the version number to 1.2.16.3, and bumped another version. They just used the same protocol version so they were still multiplayer compatible with each other. In order to prove that they are two versions, let me give an example: if I made an add-on, max_engine_version and min_engine_version in the manifest.json are both 1.2.13.60, then the version on iOS (1.2.16) cannot load this add-on.
  • The arcticles of Pocket Edition Alpha Realms build 1, build 2 and build 4 are different from other Pocket Edition Alpha versions. What's the naming specification exactly?
  • Mojang's naming specifications are very messy. Sometimes the version numbers show in different places are different.
    • For example, Bedrock Edition 1.2.6.1 should be "Bedrock Edition 1.2.6.60". In Google Play changelog and Mojira's this page], Mojang said it's 1.2.6.1, but in game it displays 1.2.6. In source code and MCPE-17100 on Mojira it's 1.2.6.60. The full version no. of Bedrock Edition 1.2.6 is 1.2.6.55. We know that if you want to update an app, the version number must be higher than the original installed version. Otherwise, the update will fail. So the correct article is "Bedrock Edition 1.2.6.60". There was an argument about this on the talk page.
    • @Nixinova: Your statement is incorrect. This also shows that the version number displayed in the game is unreliable, and the articles must be named according to the source code.
  • We found some versions that you thought did not exist (e.g. 1.14.1.4). If you want, we can provide the original apk files. We made a table to show this:
Wiki page Version no. displayed in game Internal version no. Recommended version no. (ver1) Recommended version no. (ver2)
0.1.0 0.1 1 0.1 0.1
0.1.0 0.1 2 0.1_Rev2 0.1_Rev2
0.1.0 0.1 4 0.1_Demo 0.1_Demo
0.1.1 0.1.1 1013 0.1.1_j 0.1.1_j
0.1.1 0.1.1 1015 0.1.1 0.1.1
0.1.2 0.1.2 1023 0.1.2_j 0.1.2_j
0.1.2 0.1.2 1025 0.1.2 0.1.2
0.1.3 0.1.3 1033 0.1.3_j 0.1.3_j
0.1.3 0.1.3 1035 0.1.3 0.1.3
None 0.1.3 1036 0.1.3_Rev2 0.1.3_Rev2
0.2.0 0.2.0 2003 0.2.0_j 0.2.0_j
0.2.0 0.2.0 2005 0.2.0 0.2.0
0.2.0 0.2.0 2006 0.2.0_Rev2 0.2.0_Rev2
None 0.2.1 2013 0.2.1_j 0.2.1_j
0.2.1 0.2.1 2015 0.2.1 0.2.1
0.2.1 (2) 0.2.1 2016 0.2.1_Rev2 0.2.1_Rev2
None 0.2.1 2017 0.2.1_Rev3 0.2.1_Rev3
None 0.2.2 2023 0.2.2_j 0.2.2_j
0.2.2 0.2.2 2025 0.2.2 0.2.2
None 0.3.0 3003 0.3.0_j 0.3.0_j
0.3.0 0.3.0 3005 0.3.0 0.3.0
None 0.3.0 3006 0.3.0_Rev2 0.3.0_Rev2
None 0.3.0 3007 0.3.0_Rev3 0.3.0_Rev3
None 0.3.2 3023 0.3.2_j 0.3.2_j
0.3.2 0.3.2 3025 0.3.2 0.3.2
None 0.3.3 3030 0.3.3_j 0.3.3_j
0.3.3 0.3.3 3035 0.3.3 0.3.3
0.4.0 0.4.0 4000 0.4.0_j 0.4.0_j
0.4.0 0.4.0 4005 0.4.0 0.4.0
0.4.0 rev 2 0.4.0_Rev2 0.4.0_Rev2
0.4.0 rev 3 0.4.0_Rev3 0.4.0_Rev3
0.5.0 0.5.0 5000 0.5.0 0.5.0
0.5.0 0.5.0 5005 0.5.0 0.5.0
0.6.0 0.6.0 6006 0.6.0 0.6.0
0.6.1 0.6.1 30006010 0.6.1 0.6.1
0.7.0 0.7.0 30007000 0.7.0 0.7.0
0.7.1 0.7.1 30007010 0.7.1 0.7.1
0.7.2 0.7.2 30007020 0.7.2 0.7.2
0.7.3 0.7.3 40007040 0.7.3 0.7.3
0.7.4 0.7.4 50007040 0.7.4 0.7.4
0.7.5 0.7.5 50007050 0.7.5 0.7.5
0.7.6 0.7.6 50007060 0.7.6 0.7.6
None 0.8.0_test1 300800001 0.8.0.b1 0.8.0.b1
0.8.0 build 2 0.8.0 build 2 300800002 0.8.0.b2 0.8.0.b2
0.8.0 build 3 0.8.0 build 3 300800003 0.8.0.b3 0.8.0.b3
0.8.0 build 4 0.8.0 build 4 300800004 0.8.0.b4 0.8.0.b4
0.8.0 build 5 0.8.0 build 5 300800005 0.8.0.b5 0.8.0.b5
0.8.0 build 6 0.8.0 build 6 300800006 0.8.0.b6 0.8.0.b6
0.8.0 build 7 0.8.0 build 7 300800007 0.8.0.b7 0.8.0.b7
0.8.0 build 8 0.8.0 build 8 300800008 0.8.0.b8 0.8.0.b8
0.8.0 0.8.0 500800010 0.8.0 0.8.0
0.8.1 0.8.1 500801011 0.8.1 0.8.1
0.9.0 build 1 0.9.0 500900000 0.9.0.b1 0.9.0.b1
0.9.0 build 2 0.9.0 500900001 0.9.0.b2 0.9.0.b2
0.9.0 build 3 0.9.0 500900002 0.9.0.b3 0.9.0.b3
0.9.0 build 4 0.9.0 500900003 0.9.0.b4 0.9.0.b4
0.9.0 build 5 0.9.0 500900004 0.9.0.b5 0.9.0.b5
0.9.0 build 6 0.9.0 500900005 0.9.0.b6 0.9.0.b6
0.9.0 build 7 0.9.0 500900006 0.9.0.b7 0.9.0.b7
0.9.0 build 8 0.9.0 500900007 0.9.0.b8 0.9.0.b8
0.9.0 build 9 0.9.0 500900008 0.9.0.b9 0.9.0.b9
0.9.0 build 10 0.9.0 500900009 0.9.0.b10 0.9.0.b10
0.9.0 build 11 0.9.0 500900010 0.9.0.b11 0.9.0.b11
0.9.0 build 12 0.9.0 500900011 0.9.0.b12 0.9.0.b12
0.9.0 0.9.0 500900012 0.9.0 0.9.0
0.9.1 0.9.1 500901000 0.9.1 0.9.1
0.9.2 0.9.2 500902000 0.9.2 0.9.2
0.9.3 0.9.3 500903000 0.9.3 0.9.3
0.9.4 0.9.4 500904000 0.9.4 0.9.4
0.9.5 0.9.5 500905000 0.9.5 0.9.5
None 0.9.5 500905001 0.9.5_Rev2 0.9.5_Rev2
0.10.0 build 1 0.10.0 740100000 0.10.0.b1 0.10.0.b1
0.10.0 build 2 0.10.0 740100001 0.10.0.b2 0.10.0.b2
0.10.0 build 3 0.10.0 740100002 0.10.0.b3 0.10.0.b3
0.10.0 build 4 0.10.0 740100003 0.10.0.b4 0.10.0.b4
0.10.0 build 5 0.10.0 740100004 0.10.0.b5 0.10.0.b5
0.10.0 build 6 0.10.0 740100005 0.10.0.b6 0.10.0.b6
0.10.0 build 7 0.10.0 740100006 0.10.0.b7 0.10.0.b7
0.10.0 build 8 0.10.0 740100007 0.10.0.b8 0.10.0.b8
0.10.0 build 9 0.10.0 740100008 0.10.0.b9 0.10.0.b9
0.10.0 0.10.0 740100009 0.10.0 0.10.0
0.10.1 0.10.1 740100100 0.10.1 0.10.1
0.10.2 0.10.2 740100200 0.10.2 0.10.2
0.10.3 0.10.3 740100300 0.10.3 0.10.3
0.10.4 0.10.4 740100400 0.10.4 0.10.4
0.10.5 0.10.5 740100501 0.10.5 0.10.5
0.11.0 build 1 0.11.0 740110001 0.11.0.b1 0.11.0.b1
0.11.0 build 2 0.11.0 740110002 0.11.0.b2 0.11.0.b2
0.11.0 build 3 0.11.0 740110003 0.11.0.b3 0.11.0.b3
0.11.0 build 4 0.11.0.b4 740110004 0.11.0.b4 0.11.0.b4
0.11.0 build 5 0.11.0.b5 740110005 0.11.0.b5 0.11.0.b5
0.11.0 build 6 0.11.0.b6 740110006 0.11.0.b6 0.11.0.b6
0.11.0 build 7 0.11.0.b7 740110007 0.11.0.b7 0.11.0.b7
0.11.0 build 8 0.11.0.b8 740110008 0.11.0.b8 0.11.0.b8
0.11.0 build 9 0.11.0.b9 740110009 0.11.0.b9 0.11.0.b9
0.11.0 build 10 0.11.0.b10 740110010 0.11.0.b10 0.11.0.b10
0.11.0 build 11 0.11.0.b11 740110011 0.11.0.b11 0.11.0.b11
0.11.0 build 12 0.11.0.b12 740110012 0.11.0.b12 0.11.0.b12
0.11.0 build 13 0.11.0.b13 740110013 0.11.0.b13 0.11.0.b13
0.11.0 build 14 0.11.0.b14 740110014 0.11.0.b14 0.11.0.b14
0.11.0 0.11.0 740110015 0.11.0 0.11.0
0.11.1 0.11.1 740110101 0.11.1 0.11.1
None 0.11.1 740110102 0.11.1_Rev2 0.11.1_Rev2
0.11.2 0.11.2 0.11.2 0.11.2
0.12.0 0.12.0 0.12.0 0.12.0
0.12.0.1 0.12.0.1 0.12.0.1 0.12.0.1
0.12.1 build 1 0.12.1.b1 760120101 0.12.1.b1 0.12.1.b1
0.12.1 build 2 0.12.1.b2 760120102 0.12.1.b2 0.12.1.b2
0.12.1 build 3 0.12.1.b3 760120103 0.12.1.b3 0.12.1.b3
0.12.1 build 4 0.12.1.b4 760120104 0.12.1.b4 0.12.1.b4
0.12.1 build 5 0.12.1.b5 760120105 0.12.1.b5 0.12.1.b5
0.12.1 build 6 0.12.1.b6 760120106 0.12.1.b6 0.12.1.b6
0.12.1 build 7 0.12.1.b7 760120107 0.12.1.b7 0.12.1.b7
0.12.1 build 8 0.12.1.b8 760120108 0.12.1.b8 0.12.1.b8
0.12.1 build 9 0.12.1.b9 760120109 0.12.1.b9 0.12.1.b9
0.12.1 build 10 0.12.1.b10 760120110 0.12.1.b10 0.12.1.b10
0.12.1 build 11 0.12.1.b11 760120111 0.12.1.b11 0.12.1.b11
0.12.1 build 12 0.12.1.b12 760120112 0.12.1.b12 0.12.1.b12
0.12.1 build 13 0.12.1.b13 760120113 0.12.1.b13 0.12.1.b13
0.12.1 0.12.1 760120114 0.12.1 0.12.1
0.12.2 0.12.2 760120200 0.12.2 0.12.2
0.12.3 0.12.3 760120300 0.12.3 0.12.3
0.13.0 build 1 0.13.0.b1 760130001 0.13.0.b1 0.13.0.b1
0.13.0 build 2 0.13.0.b2 760130002 0.13.0.b2 0.13.0.b2
0.13.0 build 3 0.13.0.b3 760130003 0.13.0.b3 0.13.0.b3
0.13.0 build 4 0.13.0.b4 760130004 0.13.0.b4 0.13.0.b4
0.13.0 build 5 0.13.0.b5 760130005 0.13.0.b5 0.13.0.b5
0.13.0 0.13.0 760130000 0.13.0 0.13.0
0.13.1 0.13.1 760130100 0.13.1 0.13.1
0.13.2 0.13.2 760130200 0.13.2 0.13.2
None 0.13.2 760130201 0.13.2_Rev2 0.13.2_Rev2
None 0.13.2 760130202 0.13.2_Rev3 0.13.2_Rev3
0.14.0 build 1 0.14.0.b1 760140001 0.14.0.b1 0.14.0.b1
0.14.0 build 2 0.14.0.b2 760140002 0.14.0.b2 0.14.0.b2
0.14.0 build 3 0.14.0.b3 760140003 0.14.0.b3 0.14.0.b3
0.14.0 build 4 0.14.0.b4 760140004 0.14.0.b4 0.14.0.b4
0.14.0 build 5 0.14.0.b5 760140005 0.14.0.b5 0.14.0.b5
0.14.0 build 6 0.14.0.b6 760140006 0.14.0.b6 0.14.0.b6
0.14.0 build 7 0.14.0.b7 760140007 0.14.0.b7 0.14.0.b7
0.14.0 0.14.0 760140009 0.14.0 0.14.0
0.14.1 0.14.1 760140100 0.14.1 0.14.1
0.14.2 0.14.2 760140200 0.14.2 0.14.2
0.14.3 0.14.3 760140300 0.14.3 0.14.3
None 0.14.3 760140301 0.14.3_Rev2 0.14.3_Rev2
Realms build 1 0.15.0.a2 781150002 0.15.0.a2 0.15.0.a2
Realms build 2 0.15.0.a3 781150003 0.15.0.a3 0.15.0.a3
Realms build 4 0.15.0.a4 781150004 0.15.0.a4 0.15.0.a4
0.15.0 build 1 0.14.99.0 870149900 0.14.99.0 0.14.99.0
0.15.0 build 2 0.14.99.2 870149902 0.14.99.2 0.14.99.2
0.15.0 build 3 0.14.99.3 870149903 0.14.99.3 0.14.99.3
0.15.0 0.15.0.1 870150001 0.15.0 0.15.0.1
0.15.1 build 1 0.15.0.50 870150050 0.15.0.50 0.15.0.50
0.15.1 0.15.1.2 870150102 0.15.1 0.15.1.2
0.15.2 0.15.2.1 870150201 0.15.2 0.15.2.1
0.15.3 0.15.3.2 870150302 0.15.3 0.15.3.2
0.15.4 0.15.4.0 870150400 0.15.4 0.15.4.0
0.15.6 0.15.6.0 870150600 0.15.6 0.15.6.0
0.15.7 0.15.7.2 870150702 0.15.7 0.15.7.2
0.15.8 0.15.8.0 870150800 0.15.8 0.15.8.0
None 0.15.8.1 870150801 0.15.8.1 0.15.8.1
0.15.9 0.15.9.0 870150900 0.15.9 0.15.9.0
0.15.10 0.15.10.0 870151000 0.15.10 0.15.10.0
0.16.0 build 1 0.15.90.0 870159000 0.15.90.0 0.15.90.0
0.16.0 build 2 0.15.90.1 870159001 0.15.90.1 0.15.90.1
0.16.0 build 3 0.15.90.2 870159002 0.15.90.2 0.15.90.2
0.16.0 build 4 0.15.90.7 870159007 0.15.90.7 0.15.90.7
0.16.0 build 5 0.15.90.8 870159008 0.15.90.8 0.15.90.8
0.16.0 0.16.0.5 870160005 0.16.0 0.16.0.5
0.16.1 0.16.1.0 870160100 0.16.1 0.16.1.0
0.16.2 0.16.2.2 970160202 0.16.2 0.16.2.2
alpha 0.17.0.1 0.17.0.1 870170001 0.17.0.1 0.17.0.1
alpha 0.17.0.2 0.17.0.2 870170002 0.17.0.2 0.17.0.2
alpha 1.0.0.0 1.0.0.0 871000000 1.0.0.0 1.0.0.0
alpha 1.0.0.1 1.0.0.1 871000001 1.0.0.1 1.0.0.1
alpha 1.0.0.2 1.0.0.2 871000002 1.0.0.2 1.0.0.2
alpha 1.0.0.7 1.0.0.7 871000007 1.0.0.7 1.0.0.7
1.0.0 1.0.0.16 871000016 1.0.0 1.0.0.16
1.0.1 1.0.1 1.0.1
1.0.2 1.0.2.1 871000201 1.0.2 1.0.2.1
alpha 1.0.3.0 1.0.3.0 871000300 1.0.3.0 1.0.3.0
1.0.3 1.0.3.12 871000312 1.0.3 1.0.3.12
alpha 1.0.4.0 1.0.4.0 871000400 1.0.4.0 1.0.4.0
alpha 1.0.4.1 1.0.4.1 871000401 1.0.4.1 1.0.4.1
1.0.4 1.0.4.11 871000411 1.0.4 1.0.4.11
alpha 1.0.5.0 1.0.5.0 871000500 1.0.5.0 1.0.5.0
alpha 1.0.5.3 1.0.5.3 871000503 1.0.5.3 1.0.5.3
alpha 1.0.5.11 1.0.5.11 871000511 1.0.5.11 1.0.5.11
alpha 1.0.5.11 1.0.5.13 871000513 1.0.5.13 1.0.5.13
1.0.5 1.0.5.54 871000554 1.0.5 1.0.5.54
alpha 1.0.6.0 1.0.6.0 871000600 1.0.6.0 1.0.6.0
1.0.6 1.0.6.52 871000652 1.0.6 1.0.6.52
1.0.7 1.0.7.0 871000700 1.0.7 1.0.7.0
1.0.8 1.0.8.1 871000801 1.0.8 1.0.8.1
1.0.9 1.0.9.1 871000901 1.0.9 1.0.9.1
alpha 1.1.0.0 1.1.0.0 871010000 1.1.0.0 1.1.0.0
alpha 1.1.0.1 1.1.0.1 871010001 1.1.0.1 1.1.0.1
alpha 1.1.0.3 1.1.0.3 871010003 1.1.0.3 1.1.0.3
alpha 1.1.0.4 1.1.0.4 871010004 1.1.0.4 1.1.0.4
alpha 1.1.0.5 1.1.0.5 871010005 1.1.0.5 1.1.0.5
alpha 1.1.0.8 1.1.0.8 871010008 1.1.0.8 1.1.0.8
alpha 1.1.0.9 1.1.0.9 871010009 1.1.0.9 1.1.0.9
1.1.0 1.1.0.55 871010055 1.1.0 1.1.0.55
alpha 1.1.1.0 1.1.1.0 871010100 1.1.1.0 1.1.1.0
alpha 1.1.1.1 1.1.1.1 871010101 1.1.1.1 1.1.1.1
1.1.1 1.1.1.51 871010151 1.1.1 1.1.1.51
1.1.2 1.1.2.50 871010250 1.1.2 1.1.2.50
alpha 1.1.3.0 1.1.3.0 871010300 1.1.3.0 1.1.3.0
alpha 1.1.3.1 1.1.3.1 871010301 1.1.3.1 1.1.3.1
1.1.3 1.1.3.52 871010352 1.1.3 1.1.3.52
1.1.4 1.1.4.51 871010451 1.1.4 1.1.4.51
1.1.5 1.1.5.1 871010501 1.1.5 1.1.5.1
1.1.7 1.1.7 1.1.7
beta 1.2.0.2 1.2.0.2 871020002 1.2.0.2 1.2.0.2
beta 1.2.0.7 1.2.0.7 871020007 1.2.0.7 1.2.0.7
beta 1.2.0.9 1.2.0.9 871020009 1.2.0.9 1.2.0.9
beta 1.2.0.11 1.2.0.11 871020011 1.2.0.11 1.2.0.11
beta 1.2.0.15 1.2.0.15 871020015 1.2.0.15 1.2.0.15
beta 1.2.0.18 1.2.0.18 871020018 1.2.0.18 1.2.0.18
beta 1.2.0.22 1.2.0.22 871020022 1.2.0.22 1.2.0.22
beta 1.2.0.25 1.2.0.25 871020025 1.2.0.25 1.2.0.25
beta 1.2.0.31 1.2.0.31 871020031 1.2.0.31 1.2.0.31
1.2.0 1.2.0.81 871020081 1.2.0 1.2.0.81
1.2.1 1.2.1.1 871020101 1.2.1 1.2.1.1
1.2.2 1.2.2.3 871020203 1.2.2 1.2.2.3
beta 1.2.3.3 1.2.3.3 871020303 1.2.3.3 1.2.3.3
1.2.3 1.2.3.6 871020306 1.2.3 1.2.3.6
beta 1.2.5.0 1.2.5.0 871020500 1.2.5.0 1.2.5.0
beta 1.2.5.12 1.2.5.12 871020512 1.2.5.12 1.2.5.12
beta 1.2.5.15 1.2.5.15 871020515 1.2.5.15 1.2.5.15
1.2.5 1.2.5.52 871020552 1.2.5 1.2.5.52
beta 1.2.6.2 1.2.6.2 871020602 1.2.6.2 1.2.6.2
1.2.6 1.2.6.55 871020655 1.2.6 1.2.6.55
1.2.6.1 1.2.6.60 871020660 1.2.6.60 1.2.6.60
1.2.7 1.2.7.2 841020702 1.2.7 1.2.7.2
1.2.8 1.2.8.0 871020800 1.2.8 1.2.8.0
1.2.9 1.2.9.1 871020901 1.2.9 1.2.9.1
beta 1.2.10.1 1.2.10.1 871021001 1.2.10.1 1.2.10.1
1.2.10 1.2.10.2 871021002 1.2.10 1.2.10.2
1.2.11 1.2.11.4 871021104 1.2.11 1.2.11.4
beta 1.2.13.5 1.2.13.5 871021305 1.2.13.5 1.2.13.5
beta 1.2.13.6 1.2.13.6 871021306 1.2.13.6 1.2.13.6
beta 1.2.13.8 1.2.13.8 871021308 1.2.13.8 1.2.13.8
beta 1.2.13.10 1.2.13.10 871021310 1.2.13.10 1.2.13.10
beta 1.2.13.11 1.2.13.11 871021311 1.2.13.11 1.2.13.11
beta 1.2.13.12 1.2.13.12 871021312 1.2.13.12 1.2.13.12
1.2.13 1.2.13.54 871021354 1.2.13 1.2.13.54
1.2.13.60 1.2.13.60 871021360 1.2.13.60 1.2.13.60
beta 1.2.14.2 1.2.14.2 871021402 1.2.14.2 1.2.14.2
beta 1.2.14.3 1.2.14.3 871021403 1.2.14.3 1.2.14.3
1.2.14 1.2.14 1.2.14
1.2.15 1.2.15.01 1.2.15 1.2.15.01
1.2.13.60 1.2.16.3 1.2.16 1.2.16.3
beta 1.2.20.1 1.2.20.1 871022001 1.2.20.1 1.2.20.1
beta 1.2.20.2 1.2.20.2 871022002 1.2.20.2 1.2.20.2
1.4.0 1.4.0.5 871040005 1.4.0 1.4.0.5
1.4.1 1.4.1.0 871040100 1.4.1 1.4.1.0
1.4.2 1.4.2.0 871040200 1.4.2 1.4.2.0
1.4.3 1.4.3.0 1.4.3 1.4.3.0
1.4.4 1.4.4.0 871040400 1.4.4 1.4.4.0
beta 1.5.0.0 1.5.0.0 871050000 1.5.0.0 1.5.0.0
beta 1.5.0.1 1.5.0.1 871050001 1.5.0.1 1.5.0.1
beta 1.5.0.4 1.5.0.4 871050004 1.5.0.4 1.5.0.4
beta 1.5.0.7 1.5.0.7 871050007 1.5.0.7 1.5.0.7
beta 1.5.0.10 1.5.0.10 871050010 1.5.0.10 1.5.0.10
1.5.0 1.5.0.14 871050014 1.5.0 1.5.0.14
1.5.1 1.5.1.2 871050102 1.5.1 1.5.1.2
1.5.2 1.5.2.1 871050201 1.5.2 1.5.2.1
1.5.3 1.5.3.0 871050300 1.5.3 1.5.3.0
beta 1.6.0.1 1.6.0.1 871060001 1.6.0.1 1.6.0.1
beta 1.6.0.5 1.6.0.5 871060005 1.6.0.5 1.6.0.5
beta 1.6.0.6 1.6.0.6 871060006 1.6.0.6 1.6.0.6
beta 1.6.0.8 1.6.0.8 871060008 1.6.0.8 1.6.0.8
1.6.0 1.6.0.14 871060014 1.6.0 1.6.0.14
beta 1.6.0.30 1.6.0.30 871060030 1.6.0.30 1.6.0.30
1.6.1 1.6.1.0 871060100 1.6.1 1.6.1.0
1.6.2 1.6.2 1.6.2
beta 1.7.0.2 1.7.0.2 871070002 1.7.0.2 1.7.0.2
beta 1.7.0.3 1.7.0.3 871070003 1.7.0.3 1.7.0.3
beta 1.7.0.5 1.7.0.5 871070005 1.7.0.5 1.7.0.5
beta 1.7.0.7 1.7.0.7 871070007 1.7.0.7 1.7.0.7
beta 1.7.0.9 1.7.0.9 871070009 1.7.0.9 1.7.0.9
1.7.0 1.7.0.13 871070013 1.7.0 1.7.0.13
1.7.1 1.7.1 1.7.1
1.7.3 1.7.3 1.7.3
None 1.7.9.0 871070900 1.7.9 1.7.9.0
beta 1.8.0.8 1.8.0.8 871080008 1.8.0.8 1.8.0.8
beta 1.8.0.10 1.8.0.10 871080010 1.8.0.10 1.8.0.10
beta 1.8.0.11 1.8.0.11 871080011 1.8.0.11 1.8.0.11
beta 1.8.0.13 1.8.0.13 871080013 1.8.0.13 1.8.0.13
beta 1.8.0.14 1.8.0.14 871080014 1.8.0.14 1.8.0.14
1.8.0 1.8.0.24 871080024 1.8.0 1.8.0.24
1.8.1 1.8.1.2 871080102 1.8.1 1.8.1.2
None 1.8.9.25 871080925 1.8.9 1.8.9.25
beta 1.9.0.0 1.9.0.0 871090000 1.9.0.0 1.9.0.0
beta 1.9.0.2 1.9.0.2 871090002 1.9.0.2 1.9.0.2
beta 1.9.0.3 1.9.0.3 871090003 1.9.0.3 1.9.0.3
beta 1.9.0.5 1.9.0.5 871090005 1.9.0.5 1.9.0.5
1.9.0 1.9.0.15 871090015 1.9.0 1.9.0.15
1.9.1 1.9.1 1.9.1
1.9.3 1.9.3 1.9.3
beta 1.10.0.3 1.10.0.3 871100003 1.10.0.3 1.10.0.3
beta 1.10.0.4 1.10.0.4 871100004 1.10.0.4 1.10.0.4
1.10.0 1.10.0.7 871100007 1.10.0 1.10.0.7
1.10.1 1.10.1 1.10.1
beta 1.11.0.1 1.11.0.1 871110001 1.11.0.1 1.11.0.1
beta 1.11.0.3 1.11.0.3 871110003 1.11.0.3 1.11.0.3
beta 1.11.0.4 1.11.0.4 871110004 1.11.0.4 1.11.0.4
beta 1.11.0.5 1.11.0.5 871110005 1.11.0.5 1.11.0.5
beta 1.11.0.7 1.11.0.7 871110007 1.11.0.7 1.11.0.7
beta 1.11.0.8 1.11.0.8 871110008 1.11.0.8 1.11.0.8
beta 1.11.0.9 1.11.0.9 871110009 1.11.0.9 1.11.0.9
beta 1.11.0.10 1.11.0.10 871110010 1.11.0.10 1.11.0.10
1.11.0 1.11.0.23 871110023 1.11.0 1.11.0.23
1.11.1 1.11.1.2 871110102 1.11.1 1.11.1.2
1.11.2 1.11.2.1 1.11.2 1.11.2.1
1.11.3 1.11.3.1 871110301 1.11.3 1.11.3.1
1.11.4 1.11.4.2 871110402 1.11.4 1.11.4.2
beta 1.12.0.2 1.12.0.2 871120002 1.12.0.2 1.12.0.2
beta 1.12.0.3 1.12.0.3 871120003 1.12.0.3 1.12.0.3
beta 1.12.0.4 1.12.0.4 871120004 1.12.0.4 1.12.0.4
beta 1.12.0.6 1.12.0.6 871120006 1.12.0.6 1.12.0.6
beta 1.12.0.9 1.12.0.9 871120009 1.12.0.9 1.12.0.9
beta 1.12.0.10 1.12.0.10 871120010 1.12.0.10 1.12.0.10
beta 1.12.0.11 1.12.0.11 871120011 1.12.0.11 1.12.0.11
beta 1.12.0.12 1.12.0.12 871120012 1.12.0.12 1.12.0.12
beta 1.12.0.13 1.12.0.13 871120013 1.12.0.13 1.12.0.13
beta 1.12.0.14 1.12.0.14 871120014 1.12.0.14 1.12.0.14
1.12.0 1.12.0.28 871120028 1.12.0 1.12.0.28
1.12.1 1.12.1.1 871120101 1.12.1 1.12.1.1
1.12.3 1.12.3 1.12.3
1.12.5 1.12.5 1.12.5
1.12.60 1.12.60 1.12.60
beta 1.13.0.1 1.13.0.1 871130001 1.13.0.1 1.13.0.1
beta 1.13.0.2 1.13.0.2 871130002 1.13.0.2 1.13.0.2
beta 1.13.0.4 1.13.0.4 871130004 1.13.0.4 1.13.0.4
beta 1.13.0.5 1.13.0.5 871130005 1.13.0.5 1.13.0.5
beta 1.13.0.6 1.13.0.6 871130006 1.13.0.6 1.13.0.6
beta 1.13.0.13 1.13.0.13 871130013 1.13.0.13 1.13.0.13
beta 1.13.0.15 1.13.0.15 871130015 1.13.0.15 1.13.0.15
beta 1.13.0.16 1.13.0.16 1.13.0.16 1.13.0.16
beta 1.13.0.17 1.13.0.17 1.13.0.17 1.13.0.17
beta 1.13.0.18 1.13.0.18 941130018 1.13.0.18 1.13.0.18
1.13.0 1.13.0.34 941130034 1.13.0 1.13.0.34
1.13.1 1.13.1.5 941130105 1.13.1 1.13.1.5
beta 1.14.0.1 1.14.0.1 941140001 1.14.0.1 1.14.0.1
beta 1.14.0.2 1.14.0.2 941140002 1.14.0.2 1.14.0.2
beta 1.14.0.3 1.14.0.3 941140003 1.14.0.3 1.14.0.3
beta 1.14.0.4 1.14.0.4 941140004 1.14.0.4 1.14.0.4
beta 1.14.0.6 1.14.0.6 941140006 1.14.0.6 1.14.0.6
1.14.0 1.14.0.9 941140009 1.14.0 1.14.0.9
beta 1.14.0.50 1.14.0.50 941140050 1.14.0.50 1.14.0.50
beta 1.14.0.51 1.14.0.51 941140051 1.14.0.51 1.14.0.51
beta 1.14.0.52 1.14.0.52 941140052 1.14.0.52 1.14.0.52
beta 1.14.1.2 1.14.1.2 941140102 1.14.1.2 1.14.1.2
beta 1.14.1.3 1.14.1.3 941140103 1.14.1.3 1.14.1.3
None 1.14.1.4 941140104 1.14.1 1.14.1.4
1.14.1 1.14.1.5 941140105 1.14.1.5 1.14.1.5
beta 1.14.2.50 1.14.2.50 941140250 1.14.2.50 1.14.2.50
beta 1.14.2.51 1.14.2.51 941140251 1.14.2.51 1.14.2.51
1.14.20 1.14.20.1 941142001 1.14.20 1.14.20.1
beta 1.14.25.1 1.14.25.1 941142501 1.14.25.1 1.14.25.1
1.14.30 1.14.30.2 941143002 1.14.30 1.14.30.2
1.14.30 1.14.30.06 283143006 1.14.30.06 1.14.30.06
beta 1.14.30.51 1.14.30.51 941143051 1.14.30.51 1.14.30.51
1.14.31 1.14.31.0 283143100 1.14.31 1.14.31.0
1.14.32 1.14.32.0 283143200 1.14.32 1.14.32.0
1.14.41 1.14.41 1.14.41
1.14.50 1.14.50.0 283145000 1.14.50 1.14.50.0
1.14.60 1.14.60.5 1.14.60 1.14.60.5
beta 1.15.0.8 1.15.0.8 1.15.0.8 1.15.0.8
beta 1.15.0.9 1.15.0.9 1.15.0.9 1.15.0.9
beta 1.15.0.11 1.15.0.11 1.15.0.11 1.15.0.11
beta 1.15.0.51 1.15.0.51 1.15.0.51 1.15.0.51
beta 1.15.0.53 1.15.0.53 1.15.0.53 1.15.0.53
beta 1.15.0.54 1.15.0.54 1.15.0.54 1.15.0.54
beta 1.15.0.55 1.15.0.55 1.15.0.55 1.15.0.55
beta 1.15.0.56 1.15.0.56 1.15.0.56 1.15.0.56
1.16.0 1.16.0.2 1.16.0 1.16.0.2
beta 1.16.0.51 1.16.0.51 1.16.0.51 1.16.0.51
beta 1.16.0.53 1.16.0.53 1.16.0.53 1.16.0.53
beta 1.16.0.55 1.16.0.55 1.16.0.55 1.16.0.55
beta 1.16.0.57 1.16.0.57 1.16.0.57 1.16.0.57
beta 1.16.0.58 1.16.0.58 1.16.0.58 1.16.0.58
beta 1.16.0.59 1.16.0.59 1.16.0.59 1.16.0.59
beta 1.16.0.60 1.16.0.60 1.16.0.60 1.16.0.60
beta 1.16.0.61 1.16.0.61 1.16.0.61 1.16.0.61
beta 1.16.0.63 1.16.0.63 1.16.0.63 1.16.0.63
beta 1.16.0.64 1.16.0.64 1.16.0.64 1.16.0.64
beta 1.16.0.66 1.16.0.66 1.16.0.66 1.16.0.66
beta 1.16.0.67 1.16.0.67 1.16.0.67 1.16.0.67
beta 1.16.0.68 1.16.0.68 1.16.0.68 1.16.0.68
1.16.1 1.16.1.02 1.16.1 1.16.1.02
1.16.1.03 1.16.1.03 1.16.1.03 1.16.1.03
1.16.1.04 1.16.1.04 1.16.1.04 1.16.1.04
1.16.10 1.16.10.02 1.16.10 1.16.10.02
beta 1.16.20.50 1.16.20.50 943162050 1.16.20.50 1.16.20.50
beta 1.16.20.52 1.16.20.52 943162052 1.16.20.52 1.16.20.52
beta 1.16.20.53 1.16.20.53 943162053 1.16.20.53 1.16.20.53
beta 1.16.20.54 1.16.20.54 943162054 1.16.20.54 1.16.20.54
1.16.21 1.16.21.01 1.16.21 1.16.21.01
beta 1.16.30.52 1.16.30.52 1.16.30.52 1.16.30.52
beta 1.16.30.53 1.16.30.53 1.16.30.53 1.16.30.53
beta 1.16.30.56 1.16.30.56 1.16.30.56 1.16.30.56
beta 1.16.30.57 1.16.30.57 1.16.30.57 1.16.30.57
1.16.40 1.16.40.02 1.16.40 1.16.40.02
1.16.42 1.16.42 1.16.42
1.16.50 1.16.50 1.16.50
1.16.60 1.16.60 1.16.60
1.16.61 1.16.61 1.16.61
1.16.100 1.16.100.04 1.16.100 1.16.100.04
beta 1.16.100.50 1.16.100.50 953610050 1.16.100.50 1.16.100.50
beta 1.16.100.51 1.16.100.51 953610051 1.16.100.51 1.16.100.51
beta 1.16.100.52 1.16.100.52 953610052 1.16.100.52 1.16.100.52
beta 1.16.100.53 1.16.100.53 953610053 1.16.100.53 1.16.100.53
beta 1.16.100.54 1.16.100.54 953610054 1.16.100.54 1.16.100.54
beta 1.16.100.55 1.16.100.55 953610055 1.16.100.55 1.16.100.55
beta 1.16.100.56 1.16.100.56 1.16.100.56 1.16.100.56
beta 1.16.100.57 1.16.100.57 953610057 1.16.100.57 1.16.100.57
beta 1.16.100.58 1.16.100.58 953610058 1.16.100.58 1.16.100.58
beta 1.16.100.59 1.16.100.59 953610059 1.16.100.59 1.16.100.59
beta 1.16.100.60 1.16.100.60 953610060 1.16.100.60 1.16.100.60
1.16.101 1.16.101.01 1.16.101 1.16.101.01
1.16.200 1.16.200.02 1.16.200 1.16.200.02
beta 1.16.200.51 1.16.200.51 971620051 1.16.200.51 1.16.200.51
beta 1.16.200.52 1.16.200.52 971620052 1.16.200.52 1.16.200.52
beta 1.16.200.53 1.16.200.53 971620053 1.16.200.53 1.16.200.53
beta 1.16.200.55 1.16.200.55 971620055 1.16.200.55 1.16.200.55
beta 1.16.200.56 1.16.200.56 971620056 1.16.200.56 1.16.200.56
beta 1.16.200.57 1.16.200.57 971620057 1.16.200.57 1.16.200.57
1.16.201 1.16.201.01 1.16.201 1.16.201.01
1.16.201 1.16.201.02 1.16.201.02 1.16.201.02
1.16.201 1.16.201.03 1.16.201.03 1.16.201.03
beta 1.16.210.50 1.16.210.50 971621050 1.16.210.50 1.16.210.50
beta 1.16.210.51 1.16.210.51 971621051 1.16.210.51 1.16.210.51
beta 1.16.210.53 1.16.210.53 971621053 1.16.210.53 1.16.210.53
beta 1.16.210.54 1.16.210.54 971621054 1.16.210.54 1.16.210.54
beta 1.16.210.55 1.16.210.55 971621055 1.16.210.55 1.16.210.55
beta 1.16.210.56 1.16.210.56 1.16.210.56 1.16.210.56
beta 1.16.210.57 1.16.210.57 1.16.210.57 1.16.210.57
beta 1.16.210.58 1.16.210.58 1.16.210.58 1.16.210.58
beta 1.16.210.59 1.16.210.59 1.16.210.59 1.16.210.59

--SkyE | Talk · Contributions · Logs 06:51, 17 February 2021 (UTC)

Minecraft Dungeons[edit]

Dungeons.svg
This section has been created to separate Dungeons wiki related topics and proposals from the sea of other topics in this portal, mainly for my own convenience. If this is of issue then please notify me of such so that I am aware to not do so in future. 🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)

Extension to Style Guide[edit]

Related discussion in Wiki Discord (2021-02-14)

As the dungeons wiki continues to expand there has become a desire and a need for a Style Guide that caters specificity to aspects that likely are not evident in general MCW pages or MC and MCE wikis. WIth MCD:Flames of the Nether and a large free update rapidly approaching bring a large quantity of new content, I believe it would be beneficial if we had something to guide Dungeons editors, including myself, to ensure consistency, convenience, and quality of pages and files.

This specific style guide can touch upon image naming schemes for dungeons equipment images (See: User:Raybeano99/MCD_EquipStyle), common page layouts for general articles, equipment articles, mission articles ect., inform about commonly used templates and appropriate scale values for using them, and probably much ,much more that I, myself, have not even thought about.
Preferably, this is to be viewed as an extension with tweaks upon the existing MCW:STYLE rather than a transcluded/duplicated page with some modifications. I have a few ideas on how this could be implemented:

Style 1 - Append onto existing MCW:STYLE page.

  • A new section could be created and enveloped within a distinctive #f4efe6 coloured box and text to ensure viewers recognise that the contained information is specific for the Dungeons WIki. Alternately, dungeons specific information are appended onto existing sections and subsections.
  • Clear that the information is an extension rather than a replacement or equivalent.
  • Centralised - Come one, come all, all ye need lies within a single page of wonderful info.
  • Most exposure to all editors of the wiki - More feedback, critique, and viewpoints from editors to ensure that the style guide is constructed up to a high standard. Also more users are likely to view it.
  • Flow, bit of a double edge - Centralised page would allow the whole MCW:STYLE to be read without trying to find other places for info. However, this may flow too well. Users may not recognise the section as dungeons specific, even with crystal clear visual elements and text, and apply the information onto non-dungeons pages, or miss/disregard the information altogether.
  • Expansion concerns - The existing style guide may become formidably long over time as the dungeons specific section expands and adds detail.

Style 2 - A subpage of MCW:STYLE.

  • A page to contain the dungeons specific information. linked by a visually-distinct hatnote on the MCW:STYLE.
  • Still clear that the information is an extension rather than a replacement or equivalent.
  • Expansion concerns are no longer a concern.
  • Flow concerns mitigated - Information not all in one place thus the distinction that the information is for dungeons specifically is more clear.
  • Moderate exposure to all editors of the wiki - Likely less exposure than style 1.
  • There must certainly be a clear negative somewhere but I am unable to think of one.
  • MCW:Style Guide/Dungeons, MCW:Style Guide/MCD perhaps?

Style 3 - A page within the Minecraft Dungeons namespace.

  • A page to contain the dungeons specific information close to home in the dungeons. linked by a visually-distinct hatnote on the MCW:STYLE.
  • Style - All the visual glory of the dungeons is applied onto the page.
  • Expansion concerns are no longer a concern.
  • Flow concerns mitigated - Information not all in one place thus the distinction that the information is for dungeons specifically is undoubtedly clear, especially with the dungeons namespace.
  • Least exposure to all editors of the wiki - Probably less exposure than style 1 or style 2.
  • Probably another negative exists but I am unable to think of one.
  • MCD:Style Guide perhaps?

I have personal preference for the dungeons style guide extension to become its own page in some form that style 2 and style 3 provides.

  • 🤔 Would this lead to further specificity for other MCW pages such as the portal, tasks and projects? Would that be a concern? Could further pages make things more cumbersome and difficult?

🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)

Style 1
I don't fully agree with this approach. Pertaining to keeping different kind of information simultaneously can be difficult to navigate and may lead to some confusion. A similar problem to this is the difference of information between Java and Bedrock. So as to resolve, the community decided to use {{in}}/{{only}} whenever the provided information contain disparities. This solution should not be used in terms of information that are fundamental to the wiki, like style guides. Another solution such as adding a background color or new section wouldn't help as much. Furthermore, similar styling to background color has already been defined and it requires new knowledge for people to realize the distinction.
Style 2
I totally agree in separating the page from the main style guide. By separating the page, there will be more freedom for expansion whilst not polluting the current page with MCD guides. Regarding misdirections, they are enough to be resolved by using a hat note or message box. For page name, I would say that Minecraft_Wiki:Style_guide/Minecraft_Dungeons is good enough.
Style 3
It would be more appropriate to put meta information in the Minecraft Wiki namespace. As for MCD:Style, I guess it can be used as a redirect to the MCW namespace for shortcut. Also I wouldn't personally be bothered with the design aspect of the page.
In addition, I feel like the sidebar could have the style guide to link specifically when you are in the MCD namespace. Thus resolving the concern of exposure of the page, especially to MCD editors. Other maintenance/community pages like community portal, projects, etc. shouldn't be a concern, at least for now. – ItsPlantseed|⟩ 11:20, 16 February 2021 (UTC)
Having a dynamic sidebar that alters to suit the namespace the user is in would be a brilliant implementation and not just for the style guide exposure. I do recall a discussion in the discord where an issue that prevents namespace dependent sidebars from functioning was mentioned. I suppose until that is resolved, we can’t poke the sidebar in a dynamic fashion. Could have Dungeons Style Guide be under Style Guide until that fix arrives.
Style 1 could certainly end up becoming messy and unclear for all members involved, I agree with your views.
Style 2 & 3 design aspect is agreeably low priority and appropriate location should have possess weight. Some design aspects can be determined by the page through the source so things can be solved on that front.
Minecraft_Wiki:Style_guide/Minecraft_Dungeons with MCD:Style and MCW:Style Dungeons as redirects perhaps? Maybe only the one redirect shortcut is required. 🍍 Raybeano99 (Talk) 14:55, 16 February 2021 (UTC)

Centralised Datapage[edit]

Related discussion in Wiki Discord (2021-02-04)

In the Dungeons namespace, there are multiple pages that duplicate the same information that must be kept updated, consistently styled, and worded correctly. For instance:

Some of these pages present the information in different styles to match the context of these pages.

To make numerous edits across multiple pages is tiring, time-consuming, introduces error, and new editors may be unaware of the different information location. A centralised place to edit this frequently used information will be immensely helpful. One edit to induce into many edits.
I am unaware on how to construct such a thing and implement it in a way that is accessible to locate, trivial to edit, future-proof, and easy to implement into pages.

Please share your thoughts on this and how such a thing could be constructed. A dedicated Sandbox page with subpages could be created for testing purposes.
🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)

UPDATE: Consideration for the use of Cargo. Discussed at Wiki Discord 2021-03-2021

Wiki channel in the Official Dungeons Discord[edit]

This is a thought that has been swimming around in my mind for some time. The Dungeons wiki does not have a huge quantity of editors that are immensely experienced with the game and its internals. There is also, unfortunately, a partial community consensus that any dungeons wikis are untrustworthy and information from them is to be treated with caution. This is something we need to resolve and gain the trust in the community.
The Official Dungeons Discord hosts a large quantity (but not overwhelmingly large!) of experienced players that educate, advise, and guide others but are unfamiliar with wiki editing. I believe there to be a fiction when learning how to edit the wiki with there being a few places to learn such with huge exposure. This wiki, MediaWiki Wiki, Help Wiki and the MCW:Discord (side note: I am very glad the wiki hosts a Discord Server.) are all brilliant places to start learning how to wiki edit however, they are not frequently seen or you need to ask around and explore to find them.

As a moderator of the dungeons discord, I have been able to internally propose the idea of a wiki dedicated channel - a place for dungeons folk to comfortably discuss wiki pages and information without worrying about unintentionally misinforming other players or being disruptive to existing channels. Information and links directing to wiki rules, help wikis, frequently used templates, and some wiki editing tools (ie: the generate spreadsheet on User:Raybeano99 userpage) will be made available as a pinned message. Speculation and general chat will not be permitted in the channel and will be held to a high standard. Specialised roles have not been discussed and will be handled internally.
The internal proposition was to gain feedback and thoughts from the rest of the admins and the moderators before establishing further communications. Unfortunately, the response turnout has been unexpectedly low however, none have made an explicit deny to the channel implementation. Hence me making communications here to gain your thoughts whether ye be a passer-by, an editor, admin or above to ignite the idea again.
I am in belief that implementation would not immediately yield desired output... could be slow, could be nothing, maybe something worth the attempt. Can always be removed quicker than the time taken to make the channel. Reverting and backtracking is not a concern

  • Exposure - More people experienced with the game will be informed of the wiki's existence and can contribute! This could also increase the frequency of disruptive, defacing edits.
  • New place to learn - Another place for editors to gain assistance from other editors.
  • Communication fragmentation - This, personally, is a huge concern. Could be mitigated by instructing users to provide the discord message link of the first substantial message in a conversation in the talk page of the page in discussion.
  • 🤔 What about Wiki Discord's #dungeons-wiki channel? - Something to be considered is if the implementation of a wiki channel on the official discord would have any impact on the existing Wiki Discord.

🍍 Raybeano99 (Talk) 09:45, 16 February 2021 (UTC)

Neutral to weak oppose. Agree with the three points (except I'd say the first point is more positive than negative, rather than positive/negative to an approximately equal degree). I'd also like to add a fourth point (which is a rather major one for me). As I understand, the Dungeons server is run by Mojang, who may have a conflict of interest against the community in a number of aspects. As such, I'm not very positive about game developers controlling communities. Mojang in specific isn't a company I trust given some historical actions and additional information. --AttemptToCallNil (talk) 18:23, 8 April 2021 (UTC)

Tabbed Mob pages[edit]

Alt title: Merge “base” and “variant” mobs into a singular page.

Mobs in Minecraft Dungeons have different tiers (a term used by 1.8.0.0 patch notes referring to apocalypse plus changes) that exhibit the same behaviour but with, generally, increased statistics. For example. Zombie is tier I, the dagger variant of Armored Zombie is tier II, and the sword variant of Armored Zombie is tier III.

Rather than visually appending the information upon the “base” mob (as it would encumber the page), or, what is currently the case, separate pages for Tier I and Tier II&III, a single page could implement a tabbed experience that would allow viewers to select which tier of mob they wish the page, section, or specific component to display.

Perhaps something similar to the infobox used at Terraria's Blue Slime but fashioned so it that would influence the information on the page. This could be under the page title, attached to each section, or applicable components such as tables.

Unsure on whether tabbed consolidation should include Jungle and Frozen variants of Zombie, Skeleton, and Creeper…these are tier I mobs but with additional and/or modified attacks. Could that be considered significantly altered behaviour?
Also are charged creepers considered a higher tier of creeper? Also husks and drowned? Ancients?

  • Reduction of duplicated or fragmented applicable information.
  • Makes explicit that the mobs are related
  • 🟡 Less pages for near identical mobs and thus less entries on Mob. Could possibly be beneficial?
  • Potential to decrease accessibility.
  • Likely to increase complexity of page source and hinder visual editors.

🍍 Raybeano99 (Talk) 17:34, 2 April 2021 (UTC)

Oppose, I don't think this is a useful way of using tabs. Tabs tend to cause accessibility and technical problems as you said (I'd also add that links to anchors in non-default tabs may not work). Fandom staff keep telling editors that research has shown tabs are not an effective way of conveying information as tabs other than the first will be ignored by a large portion of readers. I'm not sure about your third point, I'd say this isn't a factor at all. About the second point, is "fun related" a typo for "unrelated"? I'm not sure what "fun related" means. --AttemptToCallNil (talk) 18:29, 8 April 2021 (UTC)
Typo… not sure how fun got in there. Has been corrected.
Yeah I could envision folk not recognising the tabs as clickable and missing the information enclosed within them thinking about it more. Wondering if there are other ways that the merge could be achieved… or perhaps the standard information suffixing might not be as encumbering as initially imagined. Would love any different ideas. 🍍 Raybeano99 (Talk) 18:54, 8 April 2021 (UTC)

User page problem.[edit]

For any user page but mine it always says "This user has not filled out their profile page yet." I can tell this is a problem as while looking at the abuse filter, examining individual changes, when I go to a user page that the person edited and added stuff, it says this, and it says this in the for the page history too. Gameking1happy (talk) 19:15, 16 February 2021 (UTC)

Yes, it is showing, this is to prevent other people from editing their userpage. --TreeIsLife (talk) 19:18, 16 February 2021 (UTC)
That is nonesense. See my comment below. Dhranios (talk) (Join the wiki videos project!) 19:18, 16 February 2021 (UTC)
If correct, that was the reason --TreeIsLife (talk) 09:06, 18 March 2021 (UTC)
Known fandom problem, they're looking into it; you can still view the pages if you use visual editor. Dhranios (talk) (Join the wiki videos project!) 19:18, 16 February 2021 (UTC)
Yes, doesn't make sense why they would prevent others from viewing your userpage. I would get preventing editing, but viewing is obviously has no harm and is most likely a glitch on Fandom's part. James Haydon (talk) 19:20, 16 February 2021 (UTC)

Reinstate Tutorials/Obtaining discontinued blocks and items[edit]

Currently, Tutorials/Obtaining discontinued blocks and items is a page with no text other than a soft redirect to a Miraheze about discontinued blocks and items.

I am in favour of reinstating this page because it is useful, and has all the information needed on one page. Many players find it neat and challenging to grab all of these discontinued items and show them off to their friends. The page before it’s update was very helpful and detailed all of the blocks, plus a nice roadmap for gaining all of the blocks through their versions. The Miraheze page has all of the items on separate pages, no roadmap, and full of fluff that can be made into a short paragraph if rewritten. John502 (talk) 03:32, 18 February 2021 (UTC)

The reason why the migrate it is because maybe they feel it as an official wiki for obtaining discontinued blocks and items. TheGreatSpring (talk) 03:51, 18 February 2021 (UTC)
"All of the items on separate pages" because it's a wiki, "no roadmap" that's just not true, "and full of fluff that can be made into a short paragraph" no not at all, it says as much info as it can. Tho I may be biased because I made and own the bedrock edition version of that wiki --Gtbot2007 (talk) 15:26, 18 February 2021 (UTC)

"all the information needed on one page" seriously? What existed on those pages was a tiny fraction of what has been obtainable throughout the game's history. - User-12316399 (talk) 19:38, 18 February 2021 (UTC)

Why are there no quotes?[edit]

The wandering trader used to have quote from "Meet the Wandering Trader", but that is no more. The same applies to other pages. Why?--Olivia Capucine Elisabet (talk) 16:13, 21 February 2021 (UTC)

Because there was a community decision about a year ago to scrap these, as they hogged page space while providing little to no useful information to the article. - User-12316399 (talk) 16:56, 21 February 2021 (UTC)
Yes I do think that having quotes on every page is stupid, especially if they aren't related to said thing but only mention it. The only exception is on pages for items and locations in Minecraft Dungeons since they have these quotes in-game rather than in a YouTube video. James Haydon (talk) 17:03, 21 February 2021 (UTC)

Apperance sections[edit]

Should we have them or not?--Olivia Capucine Elisabet (talk) 17:44, 21 February 2021 (UTC)

Signatures[edit]

I'm not sure if this is related to UCP but several signatures are resetting including mine, TheGreatSpring's, and Madminecrafter12. Is their any fix to this, is it related to UCP?Humiebeetalk contribs 01:43, 22 February 2021 (UTC)

Hey Humie! I'd imagine it is related to UCP, since your userpage isn't showing up for me either, which is a "known bug" with UCP (this roll out is going great, huh?)
For what it's worth, I can see your sig right now.-- DigiDuncan (talk) 02:18, 22 February 2021 (UTC)
Don't call me humie I recently changed my signature to attempt to reverse the bug. This bug also happened before the user page bug.Humiebeetalk contribs 03:04, 22 February 2021 (UTC)
Sorry, didn't know about the name thing 😅 Wish I had more info, all I know is that this UCP rollout has messed up a lot, including my own personal Wiki and account, and many features of the platform. -- DigiDuncan (talk) 03:49, 22 February 2021 (UTC)

Old theme[edit]

Is there any way to go back to the theme before the UCP? The one that actually looked like Minecraft? I think they disabled the option to switch back, but it would be nice if someone managed to replicate it with CSS. Skywardthedragon (talk) 01:31, 30 April 2021 (UTC)

Securly for Chromebooks blocks part of content.[edit]

Screenshot 2021-02-24 at 12.50.15 (DELL Chromebook 11 3189 MW Com. portal with Securly for Chromebooks).png Securly for Chromebooks blocks part of content (right for Useful pages). I reached 400 edits! Android 1123581321 (talk) 12:55, 24 February 2021 (UTC)

Remove Securly if possible (I am assuming you can't).  Comment What is being blocked is Widget:Discord. It just seems like your school doesn't like Discord, and Widget:Discord uses discord's servers, and Securly blocks anything from discord's servers. You can also, if possible, use Tor(I am pretty sure Gamepedia unblocked it, I'll check it), a VPN, a proxy, or another computer. Blockofnetherite Talk Contributions 16:42, 24 February 2021 (UTC)
Can you take a screenshot of Widget:Discord with Securly disabled? I reached 400 edits! Android 1123581321 (talk) 09:17, 25 February 2021 (UTC)
I'm surprised that Gamepedia isn't (completely) blacklisted on Securly. Fadyblok240 (talk) 02:24, 26 February 2021 (UTC)

Page patrolling?![edit]

I was looking at my wiki achievements and saw a whole group of achievements called "Page Patrolling," what does that mean? --Gameking1happy (talk) 19:57, 25 February 2021 (UTC)

It means that you go an edit and mark it as patrolled, which can be done by viewing the difference. Only admins and patrollers (myself included) have this ability, which is why you most likely don't know about it. James Haydon (talk) 20:59, 25 February 2021 (UTC)

Help with sorting my userboxes[edit]

On my page which has my userboxes, the boxes are randomly sorted, how could I make it in a scroll box where each box is on top of each other (no boxes to the right or left of each other)? Also, can I easily put it on my user page or do I have to do something, and is there a way I can put the distinguish template (to not have people confuse it for User:Gameking1happy/Userboxes) without it showing the template on my user page? --Gameking1happy (talk) 22:59, 27 February 2021 (UTC)

This is good now. --Gameking1happy (talk) 13:15, 28 February 2021 (UTC)

Need help with 2 things with my talk page and a "template" (which is a page to show userboxes).[edit]

Hello, can someone tell me how to: A, have my userboxes from the "template" (User:Gameking1happy/My Boxes) be on the right side, next to the part which shows subpages, and B, have it NOT show the {{Distinguish}} template that is on the My Boxes page. Also am asking this on my talk page. --Gameking1happy (talk) 13:41, 28 February 2021 (UTC)

I found out about <noinclude>, now all I need is to get the template to the right side, is there something like the center template but instead of the going to the center it goes to the right?

Schematics don't display properly on Safari on iOS. I'm not sure this is the right place to put this... Please advise/edit/etc. Thanks! Grundlesalad (talk) 17:02, 28 February 2021 (UTC)

You forgot to make a section, when you are going to add a new topic press add section, don't press edit source and just add what you will say to the bottom of the page. --Gameking1happy (talk) 17:14, 28 February 2021 (UTC)

Want to know how to do something I saw people do.[edit]

I want to not need to use <small> in my whole signature to make it at a reasonable size (as now the <sub> text is a bit too small, but at normal size is too big), but need a HTML tag, what HTML tag allows you to put text on text, as I saw someone do this in their signature once. --GK1H (PF/T/C/A/S/UB made/UB on UP/PJ) 13:45, 1 March 2021 (UTC)

I don't think it is a template as a few days ago I was looking for a template for something. --GK1H (PF/T/C/A/S/UB made/UB on UP/PJ) 13:46, 1 March 2021 (UTC)
Refer to MCW:TALK again, your signature should not contain templates unless substituted. In other words, even if such a template existed, you are left with the same complex HTML after signing so might as well start with that. Plus, while you can make it visually shorter with different HTML tags, remember that markup length is a problem too, having to scroll past several lines of text for your signature is not ideal. Wikipedia limits to 255 characters. We don't have a strict limit, but I'd advise using close to 255 characters. KnightMiner (t/c) 15:42, 1 March 2021 (UTC)
Ok, I changed it to this as my made userboxes and sandbox can be found on my user page, in the subpages section, my userboxes and projects I am in can be found in other sections, and achievements can be found on my user profile and it isn't really necessary. --GK1H (P/T/C) 16:14, 1 March 2021 (UTC)

Template documentation project: Usage section style[edit]

Recently I opened a discussion regarding this at Minecraft Wiki talk:Projects/Template documentation cleanup.

The project aims to improve the templates documentation to make them clear to all users. The current way to do this is that big templates use a table to explain their parameters, while the small ones just use text. An example of a small template using a table to explain its parameters is at Template:Work in progress/doc/editcopy.

My goal is to make them consistent, but to do that we should either make all small templates have the same text style and all the big templates have the same table style, or make that both types of templates use tables to explain their parameters. You can discuss here first, and then add proposals on the link above. Thejoaqui777 (talk) 18:55, 2 March 2021 (UTC); edited 03:14, 3 March 2021 (UTC)

I would suggest smaller templates to just have a template data for summary and bigger templates to have both template data and detailed explanation of each parameters below it. TemplateData is necessary for visual editor, where it can provide a brief of explanation of each parameters. Table is inevitable as it's auto generated by TemplateData, though only if we are going to make every possible template to be visual editor-friendly.
Retrieved from Wiki Discord: "It seems that the way Wikipedia does this is with TemplateData on its own section. But since we are a very small wiki when compared to Wikipedia, using TemplateData should be enough for a brief summary of parameters.
If there are additional information or details that need to be addressed, then you may include them below the TemplateData (still within the "Usage" section), for example Template:Exclusive/doc has additional information regarding the "Editions" parameter.
Note that TemplateData description can't include links or other text formattings. So if one explanation has to contain lots of links, you may want to describe the information below the TemplateData (like the one on Template:Exclusive)." – ItsPlantseed|⟩ 19:14, 2 March 2021 (UTC)

Release date for versions[edit]

Now TheGreatSpring (talkcontribslogs) changed the Planned versions page to include that the release date of be 1.16.210 to 2021. This was because of consistancy and because 1.17.0 releases after 1.16.210, therefore 1.16.210 releases in 2021. Personally, I don't like these odd release dates as they provide little info and are broad. Also, putting it as present day - June 2021 seems a little odd. I looked at the version histories for edition articles with no mentioned (but obvious) release date and the version history for planned versions. I noticed that there was an inconsistancy - one said no release date while the other said the obvious year. I  Oppose the broad release dates. Any thoughts? Humiebeetalk contribs 03:14, 3 March 2021 (UTC).

Yeah, I wouldn't oppose getting rid of 1.16.210's listed release date at all. Listing 2021 as a release date because 1.16.210 will release before 1.17 is already kinda speculation anyways, and not providing a source for it just encourages further speculation – JEC talk 03:44, 3 March 2021 (UTC)

Break row (or break line or whatever it is called) in visual editor.[edit]

How do I do <br> in the visual editor? --GK1H (P/T/C) 15:05, 3 March 2021 (UTC)

Never mind, found out it just makes formatting confusing as hell, I'll use the source editor for formatting in the visual editor section of my userbox testing page then. --GK1H (P/T/C) 15:22, 3 March 2021 (UTC)

Better moderation[edit]

on one of the talk pages on this wiki, i commented about an invalid template and how it should be removed, but then it got deleted.--Geniusrobot1 (talk) 17:47, 5 March 2021 (UTC)

Which talk page? What invalid template? Who removed it? Give some details, I see no record of such a comment in your contributions. KnightMiner (t/c) 17:52, 5 March 2021 (UTC)

Enabling discussions on the wiki[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The Fandom Minecraft Wiki got archived as part of Project Crossover, but Fandom discussions won't be enabled on this wiki.

We discussed some details of upcoming Minecraft Wiki Crossover (which is between Fandom and Gamepedia), and we came to a topic of enabling discussions on this wiki.

If you did not know what discussions are, they are forum-like social space where community members can talk about the wiki's topic as well as the wiki itself. However, those are built on a different engine, than normal wikis are, so they don't support wikitext. Here are some PROs and CONs of it:

PROs
  • A forum-like place
  • Categories
  • Ability to report (for all users)
  • They may attract many people to the wiki
  • You don't need to add a signature
  • You can add images to the post and on the comments.
CONs
  • It may hurt the wiki's reputation (because it would be much more active, than wiki itself)
  • Hard to moderate (unless there will be Special:SocialActivity)
    • There may be need to hire new moderators (which may not be a problem)
  • We would need to have discussion rules (we can use Fandom's one)
  • IPs can't comment there, only accounts.

Discussions may help to have better crossover, with more people for crossover. What do you think? Do you support it, or not? --TreeIsLife (talk) 19:10, 5 March 2021 (UTC)

For an example of what Discussions looks like, see https://minecraft.fandom.com/f . For the guidelines that TreeIsLife mentioned, you can find a link at the top or on the side, which will take you to https://minecraft.fandom.com/d/g . Finally, if you want some general information on Discussions, check out Help:Discussions on Community Central. SLScool 19:20, 5 March 2021 (UTC)
On the Minecraft Wiki Crossover Discord the consensus was generally in favor of enabling discussions on the Gamepedia wiki. This allows the users of this feature to find their new home on the Gamepedia wiki as well, once the Fandom wiki gets locked. If the wider community consensus here agrees to enabling discussions as well, the planned timeline would be to enable discussions after the domain migration (this possibility is currently being looked into by staff, might have to wait with enabling discussions until the unified skin) and finish the Crossover with that, locking the Fandom wiki. --MarkusRost (talk) 19:46, 5 March 2021 (UTC)
Support section
I  Weak support (or maybe  Neutral, because of the arguments below) this as it was already decided on the Crossover Discord. While wikitext is useful to show templates and things like that, actually we don't do that frequently, and an advantage of the discussions system is that you can share images on the comments, which is really useful to show what we should do on specific situations. That means that there will be more vandalizers. However, it will be easy to set a group of discussion moderators to prevent such things. Thejoaqui777 (talk) 21:40, 5 March 2021 (UTC)
I  Support as I would like a place for discussion, and the cons don't seem too bad. --GK1H (P/T/C) 21:50, 5 March 2021 (UTC)
 Support because I want a way to easily communicate with other wiki editors (i dont have discord).Humiebeetalk contribs 22:15, 5 March 2021 (UTC)
 Support solely to unblock Crossover. The technology itself is not to the standards I'd consider required of any wiki technology (full histories, logs, no permanent deletion, moderator identity disclosure), so if it wasn't plausibly needed for Crossover, and if I had reasons to believe Fandom would refrain from forcing this technology on the wiki no matter its state, I would have opposed. --AttemptToCallNil (talk) 00:02, 6 March 2021 (UTC)
 Support Just for unblocking migration. We can't risk crossover would fail even with this wiki, after the MCSM one. Many people will want this, may attract new editors, especially those, who are getting here from Minecraft Forums. On the other side, i understand people against this. --TreeIsLife (talk) 19:57, 6 March 2021 (UTC)
 Weak support Discussion technology is ok, often overused as a chat platform rather than a forum which creates this weird environment since the technology itself is clearly not made with that in mind (show more button appearing every few posts). I generally don't expect a lot of meaningful discussion happening over there, I fully expect quizzes in type of "what is your favorite block" which is not something I'm interested in. That said, discussions could potentially be a good place for community to communicate with each other, I don't believe it's as good as current communication platform we use (Discord server) but it could be an option for those who don't want to use it. I think discussions present a better way to announce various changes on the wiki, with notification integration and nice formatting. The site notice is quite... Archaic and not pretty. As mc-pl admin I'm interested in turning Discussions on to see how it goes. Perhaps something similar could be suggested in here? Do a trial and see if that's something you'd like? Frisk (talk) 00:59, 7 March 2021 (UTC)
Oppose section
I  Oppose. I believe talk pages are already sufficient and they allow anonymous contributors to chip in, even if it were to be only one. Discussions would hamper this. Furthermore, I am of the school of thought where on-wiki discussions should only be about the wiki itself (or the page in question; hence talk pages), not some chit-chat about the wiki's topic (in our case, Minecraft) even if guidelines or rules exist. Purpose-built forum websites (like the Minecraft Forums or r/Minecraft) and chat programs (like Discord) serve that purpose better. A wiki's speciality is to serve user-generated content about the wiki's topic in question, not to be a catch-all for whatever one may feel like posting. DarkShadowTNT (talk) 23:21, 5 March 2021 (UTC)
 Oppose per DarkShadowTNT. BDJP (t|c) 23:29, 5 March 2021 (UTC)
 Oppose What's the point? If you want to discuss an article, you to the talk page; if you want to discuss the wiki, you come here. What would this add? It seems like a bunch of extra work for admins for no benefit at all. Looking at the link provided, 🤢🤮 this is not what a wiki is for.  Nixinova T  C   23:37, 5 March 2021 (UTC)
 Strong oppose Talk pages have served the wiki just fine for the past over a decade, so there's absolutely nothing to benefit from switching over to this. Not to mention the proposed discussion feature simply looks far less professional and oversimplified. A no from me. - User-12316399 (talk) 00:10, 6 March 2021 (UTC)
 Oppose – My main concern is how this would affect the wiki's reputation if we allow non-wiki discussion like the Fandom wiki currently does. While I don't mind the idea of social aspects within the wiki community, the Discord fills that purpose already and most of the active members there are editors; whereas with Discussions, there may be a substantial amount of people who are only active there and don't edit the wiki and vice versa (which seems to be the case on MCW Fandom). IMO, having two separate communities on the same site makes it harder to manage.
I am also not a fan of its general layout (e.g. lack of search-ability, displaying every post/comment on a single page), although UCP phase 2 may make some changes. I should also mention that a few Fandom wiki admins expressed support in the Crossover Discord for merging even if we decided against enabling discussions, so it might not be a blocking factor. –Sonicwave talk 01:50, 6 March 2021 (UTC)
 Weak oppose per above comments. TheGreatSpring (talk | contribs) (Tagalog translation) 02:24, 6 March 2021 (UTC)
 Oppose Discussions doesn't belong in a wiki-like environment. Compared to talk page, it's not well-structured and also not archivable. It's poorly designed and doesn't give much to the wiki. It shouldn't ever be used for in-wiki discussions, because the lack of navigation and reliability. There are other places for general people to talk about the game like Minecraft Forums. So I don't see any "actual benefit" for us from having it here; just going to add more burden to moderation. – ItsPlantseed|⟩ 05:35, 6 March 2021 (UTC)
I  Strong oppose, it's disorganised and messy, we are too much! MetalManiac at your service fellow human! (talk) 08:31, 6 March 2021 (UTC)
Changed to  Weak oppose per above (I guess I just have to get discord).Humiebeetalk contribs 15:38, 6 March 2021 (UTC)
 Oppose. I don't see the need to add DIscusions--Eduaddad (talk) pt.Wiki Administrator Helper 14:38, 7 March 2021 (UTC)
 Oppose. When I look at the current discussions on the current Minecraft wikia, I don't think this is something that a wiki needs. That type of content fits way better on Reddit. Most of the things there don't even have anything to do with the wiki at all, they're just shitposts about Minecraft. | violine1101 (talk) 15:55, 10 March 2021 (UTC)

Discussion[edit]

I saw some people with argument against discussions, that was similar to - "Basically discussions are talk pages".

So, as i described, they are forum-like. But people said they are basically talk pages. Well now, i see people voting oppose will be even more mad, but discussions can be also named as - well- Minecraft Forum. They have some Wiki things, but other topics are allowed, such as creations, memes,... - based on wiki admins choice. Fandom's Wiki has sections like: "General, Poll, Creations, News (on Minecraft), Q&A or Minecraft Wiki.--TreeIsLife (talk) 20:16, 6 March 2021 (UTC)

I have changed my vote from  Support to  Weak oppose to  Neutral. I understand that it you want it to be a forum but i'm not exactly sure if we need this. All of this is usually documented on reddit OR MCW discord. I really think memes are not nessicary at ALL in this wiki. Creations might be helpful for tutorials and feedback could also be helpful so i'm  Neutral Humiebeetalk contribs 20:29, 6 March 2021 (UTC)
Well, this discussion/vote was suggested by Markus, and the inclusion of Discussions was by Fandom users.--TreeIsLife (talk) 20:49, 6 March 2021 (UTC)
Even still, I do not believe a wiki should be hosting things like memes, polls and creations (unless relevant for an article and placed only there where it's relevant). Like Humiebee said above and I in my vote, there are places already for this which serve such purposes better than a wiki could. If this would block the crossover, then so be it. I would still stand by my vote. Going by Sonicwave, not having Discussions might not be a blocking factor anyway. DarkShadowTNT (talk) 20:59, 6 March 2021 (UTC)
There is a lot of opposition to Discussions on the basis that non-wiki conversations are an integral part of the system and it's impossible to only have wiki-related posts. However, this is not actually the case. The rules can very easily be written to only allow wiki-related posts. For example: suppose this wiki allowed everyone to freely discuss the games on talk pages. You would see a lot of users using talk pages to discuss the game without editing articles/templates/whatever else; you would also see a lot of users editing articles et al. without using talk pages to discuss the game (which is what we currently have). However, this wiki does not allow that, so this only happens very rarely if ever. Similarly, if the rules on Discussions say that users can only discuss the wiki, you would see a lot of users discussing the wiki there without many users discussing the games themselves. While the design of Discussions might make it more likely for people to use Discussions for the wrong purpose than to use talk pages for the wrong purpose, it's still the same principle: whether or not users are allowed to discuss non-wiki matters is a choice that is entirely up to the wiki, regardless of whether it's in Discussions or on talk pages or in some other location. There are still other reasons to oppose discussions, but wiki-related vs. non-wiki-related shouldn't be. SLScool 23:59, 6 March 2021 (UTC)
If we only allowed wiki discussion posts, I don't think Discussions would be worth it over talk pages due to layout issues mentioned above. While they are more intuitive especially for new users, comments take up more space and you have to click multiple times to view all the comments on a long thread, it doesn't support "multi-level replies" like talk pages (or Reddit comments), and it's not searchable so decisions made there would be lost. The ability to add polls may lead people to use that for decision making, instead of forming a consensus as should be done on here. Plus, the very existence of another communication medium fragments wiki discussion further. It may work if we have a rule that important discussions should be taken to wiki talk pages (like with the Discord), but there wouldn't be much point in having it then. –Sonicwave talk 05:05, 7 March 2021 (UTC)

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

making a prototype article for revolutionary traffic light sytems made when i taught myself how to do them[edit]

does anyone know how to create a new wiki page? i want to make a article for this and show my innovative ideas. here is how it goes so far and i would like improvement suggestions: Minecraft traffic signals have long been red green only or without advanced features such as left turn signals without alternative intersection designs such as the continuous flow intersection. but now the modular parts are here. while at the time, the page editor is working on actuated control, actuated signal control is finally a thing for smart intersections. here is a current list: 26 repeater 4 tick 2 phase yellow light included controller, kill switch comprised of 2 inverters. with a input in between the 2 inverters. this is also the base for the yellow light timer, containing 5 4 tick repeaters. and a actuated control max out timer. call prioritizors are being worked on. no progress has been made due to work on other devices related to actuated control. the next build on the line you can make yourself is the night flash controller. the how to's are somewhere else in the wiki if you look it up once these are created. but the last yet not least product of the line is the protected left turn silo for timing left turn intervals. a single controller may be used to control multiple junctions without building seperate controllers. this remote transmission is very useful. it should be cautioned that servers focusing on beauty and not functionality may not like these systems as wire sorting may make a redstone jungle near the intersection. how all of these work will be explained. first up is the 26 repeater fixed timing controller. it works as expected. a torch clock delayed with repeaters. the rows must be 5 blocks long for the output to work properly or the yellow light WILL be knocked out of tune causing the light to malfunction. the yellow light timer gives an all way yellow light or yellow lights only to the desired streets. only giving the yellow lights to certain streets is most desirable when a left turn signal exists. the actuated control max out timer MUST have a repeater delay where on circuit has a single repeater and the second circuit has a high amount of repeaters. this will prevent malicious users from making the traffic light have a sezuire and malfunction. this protection is required only on actuated control since as long as you keep fixed timers protected from vandals, the fixed timer controllers will not malfunction unless you have set up the controller wrong. left turn silos are a bubble stream based system where a single item is dispensed into the bubble stream. this unlocks the left turn output and activates the arrows. the amount of time that passes before the item returns to the dispenser determines the length of the left turn phase which is fixed. just put a roof o the silo or it will not work and the left turn arrow will be green for all eternity or until you fix the issue. that wil be all for now until i make more innovations on the new 2189 model traffic light controller system:New generation of innovation. the official name of this new system you may build on your world. also, i need help. how do i set up a schematic for redstone--A2189 (talk) 22:51, 8 March 2021 (UTC)

This should go in Tutorials/Traffic light or something. Click on the redlink and add whatever info you desire. Just make sure you look at other tutorials for formatting.Humiebeetalk contribs 02:29, 9 March 2021 (UTC)

Template:Unreleased feature[edit]

{{Unreleased feature}} leaves a bad taste. To me, it looks like its trying to circumvent article notability. If people want to create articles for unreleased features, why not use MCW:Sandbox? I don't like the idea of articles under redirect, both because its bad for usability, and because it brings back the exact same problem the original articles had which was a lack of proper article content. Warden is an example of that template's usage.

Alternatively, if people you want to keep using {{Unreleased feature}}, let make a proposal to amend the style guide to allow those articles to exist and remove the redirect. For instance, I'd be a lot more likely to support such an article if you had a clear expiration date before an unreleased feature gets downgraded to a section on mentioned features, along with some notability for which "unreleased features" are notable enough for their own article. We can discuss that under this topic if anyone has clear ideas.

From my point of view, {{Unreleased feature}} in its current form violates the style guide, so we need to either amend the style guide to state when its allowed or remove the usages. KnightMiner (t/c) 06:11, 11 March 2021 (UTC)

 Support deleting the template outright. As for the proposal to amend the style guide to accept unreleased feature - there is too little information. What info is there on Warden that warrants its own page? With the exception of Warden, there are too little details on Caves & Cliffs to warrant an entire page. I would like {{unreleased feature}} to be in the {{redr}} template.Humiebeetalk contribs 23:28, 15 March 2021 (UTC)
 Oppose Deleting it - If we deleted this template, use of {{redr}} won't be enough, and we won't be able to create these pages, as it would be violating much more, than it does now. We would have to say to people who do so "sorry, but you are directly violating our style guide". --TreeIsLife (talk) 07:33, 16 March 2021 (UTC)
That is exactly the point. If it is violating the style guide, why does adding a template make it not in violation? If you think using that template should be allowed, the style guide should be amended to say "articles about unreleased features are fine as long as they are marked with {{Unreleased feature}} and hidden by a redirect".
As it stands, the current wording of the style guide means if someone wants to create an article for an unreleased feature, you tell them it violates the style guide. You dislike telling people that? Make a proposal or agree with one to change the style guide. We could change the style guide to describe when unreleased articles are allowed, instead of circumventing it with secret articles. KnightMiner (t/c) 02:29, 17 March 2021 (UTC)
I am oppose of this due it will just start a domino effect. You will change this, style guide will probably change too, and based on how those changes will be (i saw more strict idea of style guide), it may even mean page like Warden won't exist, even when announced, but unreleased. Also, even when not in style guide, it became as a "hidden point", and if this template would be deleted, it would probably mean that point won't apply any longer.--TreeIsLife (talk) 07:32, 17 March 2021 (UTC)
So let me get this straight, you think we should leave this template (which violates the style guide) alone because you think the style guide is too strict, and yet do not want to change the style guide to be less strict to make the template be allowed? KnightMiner (t/c) 17:08, 17 March 2021 (UTC)
Yes. But probably when I see how other people are voting, i will probably have to accept its removation, and also style guide changes--TreeIsLife (talk) 08:33, 18 March 2021 (UTC)
 Support deletion, and making the style guide more strict; these pages might just as well first be made in the userspace, rather than under the redirect. We have a bunch of stuff in the style guide that goes ignored, including the "page titles should be singular", which was brought up as adiscussion point on discord several times too. I'm getting tired of it just being me who follows the style guide more directly. Dhranios (talk) (Join the wiki videos project!) 09:02, 16 March 2021 (UTC)
 Support deletion of the template. TheGreatSpring (talk | contribs) (Tagalog translation) 11:59, 16 March 2021 (UTC)
How exactly does this template violate the style guide? Fadyblok240 (talk) 01:50, 17 March 2021 (UTC)
The template is to be added to articles that are disallowed under the style guide, using the logic that since the article has a redirect making it hard to get to its okay. Its still an article, it is still about unreleased features, its just that most people won't find it. So maybe its better to say the template itself is not a violation, but using the template for its indented use is a violation. KnightMiner (t/c) 02:29, 17 March 2021 (UTC)
 Support deletion: We already have various templates for marking new and changed behavior and items of upcoming versions, for example Drowned's upcoming switch from dropping gold to dropping copper. Currently the changing drops for Drowned are simply noted within their page, and the Skulk Sensor has a page, but the Warden links to a paragraph in the upcoming version page. I see no reason we shouldn't simply have properly-hatted articles (with whatever information is available) for items and/or mobs that have been confirmed as "upcoming". --MentalMouse42 (talk) 12:04, 18 March 2021 (UTC)

All Wiki Tags on Main Page[edit]

All wiki tags are not listed on this wiki's main page. SpeedoThreeSixty (talk) 18:28, 12 March 2021 (UTC)

Navigation on FandomDesktop[edit]

As you may know, FandomDesktop will use the same navigation, as Oasis, therefore we would have to change this one. Unfortunately, this type of navigation would mean the uncollapsed "navigation" would be gone, and we would have to rework it entirely. What are your opinions on this?

Note: It is possible to add 3 layers into navigation --TreeIsLife (talk) 13:42, 16 March 2021 (UTC)

Mechanics/Redstone problem[edit]

The following discussion of a proposal to move several redstone-related pages was closed. Please do not modify it. Make subsequent comments below this or make a new topic.
 Done. Pages were moved per this discussion. Thejoaqui777 (talk) 19:34, 6 April 2021 (UTC)

Currently, Mechanics/Redstone acts as a page that works like a short version of Mechanics/Redstone/Circuit and a list of Mechanics/Redstone/Components. The page needs to be rewritten to be transformed into a general article about all the redstone mechanics.

While Mechanics itself can be converted into an index page to list related articles, that isn't the actual problem. The problem is with the name of the page itself: Mechanics/Redstone and its subpages. Mechanics is a redirect to Tutorials/Mechanisms, meaning that we have subpages of a redirect. This means that the way of classifying them became more confusing and disorganized over time.

My proposal at Talk:Mechanics/Redstone is that it should be renamed to Redstone mechanics to be its own main article.

Now, adressing the discussion about Mechanics/Redstone/Circuit, it has been proposed to rename the page to Redstone circuits on its talk page. However, I don't think that is the only possible solution to this. Instead, I've proposed to rename it to Redstone mechanics/Circuit. It would still be a subpage, but a subpage of a complete article.

There is also an inconvenient: There exist pages like Mechanics/Redstone/Clock circuit, which use "circuit" on their names, and even have a lot of subpages. These ones should be renamed to Redstone mechanics/Circuit/Clock as an example.

Now, I'll show a table showing what we should do to solve this:

Proposal 1
Original name New name Reason
Mechanics Mechanics It should become an index page like Tutorials/Redstone, to list related articles about mechanics. (Change already made, though it needs improvements)
Mechanics/Redstone Redstone mechanics It should be a general page for all redstone mechanics.
Mechanics/Redstone/Components Redstone mechanics/Component To become a subpage of the new name.
Mechanics/Redstone/Circuit Redstone mechanics/Circuit To become a subpage of the new name, as circuits are part of the mechanics.
Mechanics/Redstone/Clock circuit
Mechanics/Redstone/Pulse circuit
Mechanics/Redstone/Transmission circuit
Mechanics/Redstone/Memory circuit
Mechanics/Redstone/Piston circuits
Redstone mechanics/Circuit/Clock
Redstone mechanics/Circuit/Pulse
Redstone mechanics/Circuit/Transmission
Redstone mechanics/Circuit/Memory
Redstone mechanics/Circuit/Piston
As they are specific circuits, it doesn't make sense to keep them separated as their own pages and not as subpages of the main article.
Example: Mechanics/Redstone/Clock circuit/Clock multiplier Example: Redstone mechanics/Circuit/Clock/Clock multiplier The subpages of the last ones should be converted to the new naming.

What do you think of it? I think it solves the problem. Thejoaqui777 (talk) 02:05, 18 March 2021 (UTC)

Since subpages are inaccessible from Special:RandomRootPage, which is used by "Random page" in the sidebar, renaming the articles without using subpages might make them more visible to readers, which might help in improving the articles. Fadyblok240 (talk) 02:35, 18 March 2021 (UTC)
That's also why Redstone mechanics should have links to all its subpages, and the same for Redstone mechanics/Circuit. Thejoaqui777 (talk) 02:40, 18 March 2021 (UTC)
As I said on my own page, the information currently at Mechanics/Redstone is certainly needed, no matter what name it's accessed by. It's not an abbreviated version of the Redstone Circuits page, it's explicitly the extraction of the mechanics info from that page. I purposely copied an abbreviated subset of that info back to the Circuit page, in the interests of readability/comprehension.
  • Turning Mechanics into an index page is a reasonable idea, and would go well with turning Mechanics/Redstone into a top-level page.
  • IMHO promoting the Redstone/Circuit page to a top-level "Redstone circuits" page would be better than making it a subpage of the new "Redstone mechanics" page -- it is a major topic in its own right, and the circuits already fit awkwardly under Mechanics. (They're equivocally "mechanical", but they're not really about game mechanics.) Note that the general "Circuit" page already has links to the type pages; the Circuit page itself briefly explains the types and offers general info about making redstone circuits.
    • Regardless, the circuit-type pages should stay as become subpages to the "Circuit" page's new location. I think all the internal links within the subtrees are already relative, but if any aren't we can fix them easily enough. Note that the type pages have more levels, notably the schematic breakout pages! (Those do need to be broken out of their respective "main" pages, due to the overhead and limits of the schematic system.)
  • It's also worth noting the index page Tutorials/Redstone, which mostly links to subpages of Tutorials/, but also has a few links into the Mechanics/Redstone tree.
--MentalMouse42 (talk) 03:20, 18 March 2021 (UTC)
That would make the proposal change from the original to this:
Proposal 2
Original name New name Reason
Mechanics Mechanics It should become an index page like Tutorials/Redstone, to list related articles about mechanics. (Change already made, though it needs improvements)
Mechanics/Redstone Redstone mechanics It should be a general page for all redstone mechanics.
Mechanics/Redstone/Components Redstone components To become an article to list all the posssible components, being rewritten for better readability.
Mechanics/Redstone/Circuit Redstone circuits To become its own article, as it is really big to be just a subpage.
Mechanics/Redstone/Clock circuit
Mechanics/Redstone/Pulse circuit
Mechanics/Redstone/Transmission circuit
Mechanics/Redstone/Memory circuit
Mechanics/Redstone/Piston circuits
Redstone circuits/Clock
Redstone circuits/Pulse
Redstone circuits/Transmission
Redstone circuits/Memory
Redstone circuits/Piston
As they are specific circuits, it doesn't make sense to keep them separated as their own pages and not as subpages of the main article.
Example: Mechanics/Redstone/Clock circuit/Clock multiplier Example: Redstone circuits/Clock/Clock multiplier The subpages of the last ones should be converted to the new naming.
That would be another proposal. Which do you think it is better? Proposal 1 or proposal 2? For me, the 2 actually may work better, but it is still worth keeping the 1. Thejoaqui777 (talk) 04:22, 18 March 2021 (UTC)
 Support for Proposal 2. The circuit type pages already have top-level redirects, those should be kept for indexing/search purposes. --MentalMouse42 (talk) 04:37, 18 March 2021 (UTC)
 Strong Support for Proposal 2. --TreeIsLife (talk) 08:20, 18 March 2021 (UTC)
 Strong support for Proposal 2 based on my comments from #The problem with subpages.Humiebeetalk contribs 00:56, 19 March 2021 (UTC)
 Support proposal 2. We do need consistency in naming. We have anvil mechanics already, and the redstone stuff should have the same hierarchy under Mechanics once that is changed from a redirect into its own page. Amatulic (talk) 18:16, 21 March 2021 (UTC)

Convert the Tutorials pages into their own namespaces[edit]

I'm reviving Minecraft Wiki talk:Community portal/Archive 26#Should we move all Tutorials pages to a own namespace?

That discussion actually is worth of reopening. Tutorials are an important part of any game wiki, as it is a secure way to keep documentated facts that aren't able to be into normal articles.

This was opposed before mainly because (if I read the old discussion correctly) other namespaces couldn't be accessed with the "Random page" link. However, that is no longer the case, as now Minecraft Dungeons and Minecraft Earth articles can be accessed with the link.

If we do this, then we should do this (see the table):

Original name New name Reason
Tutorials and Minecraft Dungeons:Tutorials Minecraft tutorials and Minecraft Dungeons tutorials Since both games are active, tutorials need to be split into two namespaces.
Example: Tutorials/Defeating the ender dragon Example: Minecraft tutorials:Defeating the ender dragon To be the same as Minecraft Dungeons and Minecraft Earth.
Example: Talk:Tutorials/Defeating the ender dragon Example: Minecraft tutorials talk:Defeating the ender dragon To be talk pages of their own pages and not subpages of the general Tutorials talk page.

The reason is that tutorials are an important part of the wiki. Though the Minecraft Wiki is meant to explain factual data about the game, it can't do that completely without the tutorial pages. Things such as redstone circuits, general farms, game quirks, functions, and information about the game's UIs all are stored within tutorials. This is factual evidence that can only really be given in a tutorial format, as the main articles oesn't alllow tutorial-like content.

Now I'll show another table showing the advantages, disadvantages and arguments for them:

Advantage Disadvantage Counterargument to disadvantages
Tutorials as their own namespace will be able to be accessed through the Random page link. Tutorials are often badly written, and its quality is seriously questionable. Being acessible through that link means that users will be able to see them more often. Also, tutorials themselves can be rewritten, and it's easy to mark them with the {{rewrite}} template.
Tutorials as their own namespaces can receive a standard definition of what are they exactly, which isn't totally defined. Tutorials describe guides, describe processes, can serve as suggestions or warnings for doing things in-game. The Minecraft Wiki's scope and purpose is to document actual information from the game. Tutorials have a different tone, set of editors, audience and intentions than regular articles. Tutorials always have been part of the wiki, or at least for so many time. The fact itself that they have a different tone, set of editors, audience and intentions also acts as an advantage, since people wants to document its creations in a secure way, making sure that they will be preserved. Many tutorials do this, containing information for both current/recent and old versions.
Tutorial talk pages will be specific for only one tutorial, and wouldn't be anymore a subpage of the general Tutorials page. --- ---
Their shortcut versions would be "MCT" (Minecraft tutorial) and "MDT" (Minecraft Dungeons tutorial). Minecraft Dungeons tutorials would have an inconsistent shortcut. Another proposal can be "MCDT". Though it would be longer and still inconsistent with the usual 3 letter ones, it is more consistent than "MDT".

What do you think of this proposal?, as this really needed to be discussed again. Thejoaqui777 (talk) 00:03, 19 March 2021 (UTC)

 Strong support I actually had forgotten for a while that they weren't a separate namespace. (Or did they used to be? I honestly can't remember.) In any case, Terraria Wiki uses a namespace for their equivalent Guides, so its feasibility is demonstrated by example. --MentalMouse42 (talk) 00:30, 19 March 2021 (UTC)
 Strong support per my comment on #The problem with subpages.Humiebeetalk contribs 00:54, 19 March 2021 (UTC)
 Strong oppose. I don't see how any of the four advantages are substantial or valid. Most visitors would get to tutorials from the search engine (not even the on-site search or the random page button), which means optimizing for the latter two ways should not be done at the expense of the first one, and page moves of any kind are harmful to search engine optimization, while the subpage structure is very well understood by search engines. So #1 is an advantage that will be targeted at the expense of the average reader. #2 is invalid, any policy can be changed to adapt to circumstances, and we shouldn't try to adapt circumstances to policy at substantial expense of user experience. The talk page issue doesn't seem problematic at all, at most weird for the more involved of readers (most of who won't even use talk pages). The namespace shortcuts are not going to be used by readers as they won't have any idea of them (and once again, they'll most likely be coming from search engines who at best won't care about shortcuts); in addition, the proposed shortcuts can conflict with potential "talk" shortcuts. --AttemptToCallNil (talk) 10:02, 19 March 2021 (UTC)
 Comment: It is true. The policy can be changed so how to write tutorials should be explained better than how it is done now. The main reason of this is the point #1, which explains that subpages can't be accessed from the Random page link. If this can break the search engine, maybe we could find a solution to this. Subpages can't be shown easily, and that's another reason of why. Thejoaqui777 (talk) 13:15, 19 March 2021 (UTC)
 Strong Oppose - Namespace? No. I feel we should not make an soup opera from Namespaces. Namespaces are here to seperate functions between pages. All namespaces have purporse. With creating new, however, we should consider why it is needed to make a new namespace. For example, with Minecraft Earth and Dungesons - "Different games". Games, which are not 100%-ly Minecraft, but are from Minecraft Universe (Minecraft Earth, Dungeons, Story Mode) and have potential to have more content, yes. This doesn't. It may have more content, but it is really needed? No. --TreeIsLife (talk) 14:09, 19 March 2021 (UTC)
 Strong support. Tutorials serve a very different purpose to definitive fact-based Minecraft Wiki articles, but are a necessary commodity for this Wiki to serve. (Is there anywhere close to as good a resource as we have here for Redstone logic gates? I don't think so.) New and old players utilize these resources, and they are key to this Wiki's helpfulness, while being very different from say, and article about a block or item. For this reason, and since most people find tutorials through the search bar anyway, and for categorization and organaiztion purposes, I dig this idea. --DigiDuncan (talk) 03:59, 21 March 2021 (UTC)
 Extremely strong support These pages have been in the mainspace for far longer than they should have been and are well overdue for being kicked out. The style guide specifically forbids tutorial info from mainspace articles, so why these insisted on remaining mainspace articles for a decade plus is beyond me. - User-12316399 (talk) 04:29, 21 March 2021 (UTC)

Inconsistancy between Nether Update and Caves & Cliffs[edit]

In the page Nether Update, the Notable features section only contained the notable features. In Caves & Cliffs though, it shows every single feature. It also shows changes as well as having a much higher image rate (not in gallery). What style should be adopt, Nether Update or Caves & Cliffs?Humiebeetalk contribs 14:24, 20 March 2021 (UTC)

I'd say the newer page is just getting more attention as the game and wiki get bigger. I have no trouble with listing all the features, but it might be worth prepending a summary. --MentalMouse42 (talk) 16:17, 20 March 2021 (UTC)
As i said at least twice, Notable features should show notable features, not every feature. So Nether Update style should be adopted (for now).--TreeIsLife (talk) 07:52, 21 March 2021 (UTC)
I  Support the usage of Nether Update's style to write general articles about updates, while Java Edition 1.17 and Bedrock Edition 1.17.0 should be the specific articles to document the information as it is, like with Java Edition 1.16 and Bedrock Edition 1.16.0. Thejoaqui777 (talk) 19:44, 21 March 2021 (UTC)
Fair enough.  Support summary articles for "named updates", detailed articles for specific version numbers. --MentalMouse42 (talk) 19:18, 22 March 2021 (UTC)
Huge  Support for the idea of named articles for summaries and version articles for full changelogs. --DigiDuncan (talk) 21:14, 22 March 2021 (UTC)
 Comment @MentalMouse42: I would agree with that, as the wiki has been extremely active lately in the past few months, way more than it was when the Nether Update was being developed. James Haydon (talk) 21:13, 22 March 2021 (UTC)

Flavors of "renewability"[edit]

I see a lot of infoboxes listing a resource as "renewable", and simply having a single label for everything renewable gives a false impression about practicality.

It might be useful to readers to have some distinctions between flavors of renewability. Logs are easily renewable by planting the saplings dropped from trees when harvesting them. While it's difficult to get a trident, the only way to get one is from a drowned. But is anybody really going to go through the agony of creating and defeating a wither just to get some coal? Technically coal is renewable, but practically it isn't, so it's kind of misleading to give it the same label as an oak log in terms of renewability.

Seeing "Renewable: Yes" in an infobox, therefore, is not useful information to me as a player. I'd like to see some qualifiers, like "Renewability: Easy/Moderate/Hard", indicating the effort and risk required to obtain the resource by means other than mining, in Survival mode.

Examples:

  • Bee nest: Renewability is easy, requiring a small amount of low-risk effort (albeit by grinding) to plant oak or birch trees near flowers.
  • Cobblestone: Renewability is easy, requiring resources to obtain a bucket for water and lava.
  • Iron ingot: Renewability is moderately difficult given that one generally needs several ingots. One can build a basic iron farm in survival mode, but it's a low risk activity that takes effort and time.
  • String: Renewability has variable effort and risk. Risk can be high (going to the Nether to barter, or hunting spiders) or time consuming (relying on chance from fishing, bartering, cat gifts). In my experience, string is one resource I'd like to have early in the game but in some games I have found it extremely difficult to obtain.
  • Sand: I'd say moderate; it's technically renewable by trading, but considering the value of emeralds it's a poor exchange, especially if you need a lot of sand and there is no village available.
  • Mob heads: Renewability is hard. This is something that is renewable more by accident than intentionally. Not practical at all.
  • Clay: Hard, high risk. The only renewable way to get it is to gain Hero of the Village, and then you can get it only if the village has a mason who survived the raid.

I realize there's a lot of subjectivity here, but maybe we could come up with more objective criteria. One idea might be to plot items on a grid with axes representing effort and risk or cost. Amatulic (talk) 18:57, 25 March 2021 (UTC)

@Amatulic:, I have 1 problem, this is opinion based. Also, how do you even make a graph, a poll? At the very most, do something like {{biome}} where it shows only a few options, not something all out.Humiebeetalk contribs 19:08, 25 March 2021 (UTC)
 Oppose, simply too subjective to implement; it's not a game definition, so it is entirely opinion based.
People can judge for themselves by reading the obtaining sections. Dhranios (talk) (Join the wiki videos project!) 19:21, 25 March 2021 (UTC)
 Oppose making changes to the infobox field aside from possibly removing it. I agree that the current information isn't super useful (e.g. it's hardly practical to get renewable resources through the wandering trader), but classifying by cost or risk is subjective, and I can't think of many other classifications that would both be useful and clear enough to not warrant an explanation (which would be too much for an infobox field). I wouldn't be opposed to making a bigger deal on renewability in the obtaining sections, especially for items like concrete powder where it's not immediately obvious without reading the pages of its crafting ingredients. –Sonicwave talk 20:18, 25 March 2021 (UTC)
 Support moving the renewability out of the infobox and into obtaining. Dhranios (talk) (Join the wiki videos project!) 22:45, 25 March 2021 (UTC)
 Support moving the renewability out of the infobox and into obtaining. It does require more explanation than a simple yes/no. --MentalMouse42 (talk) 02:28, 26 March 2021 (UTC)
 Comment The general issue of difficulty in renewability is something that has come up before; the biggest factor in difficulty is actually gating. In general, an up-front investment can reduce the "cost" (time, effort) of most resources by at least one order of magnitude and sometimes more.
  • E.g., String is difficult to obtain in the early game, but once the player has iron armor and weapons, spiders are little threat... and once they can find and farm a spider spawner, it's trivial.
  • Likewise for iron -- early in the game it's just easier to mine for it, but once the player has enough resources to manhandle villagers and build an iron farm....
  • A similar pattern applies to tradeables in general -- initially subject to random chance, but once you invest the time and resources (cash-crop farms, a trading hall, cultivated trades), that gate is basically passed -- the emerald cost of something turns into "how many do you need?".
    • The wandering trader represents a slightly special case, in that you need to wait for a desired offer, and can only get a limited supply.
  • That said, there certainly are a few things where even farming leaves them pretty costly. Nether stars are the poster boy for those...
    • Even on smaller scales: E.g, I recently built a basic music disk farm, where I still need to wait for creepers to come by, lure them into the killing yard, then dodge arrows from my named skelly for a bit. Way better than fooling around in the open night, but not quite trivial.
    • Witch farms probably qualify in this category too, in that the scaling basically means that you really do need to "go big or go home".
  • And when the effort for something is totally out of proportion to the value (e.g., the clay example), it might technically be renewable, but not in practical terms.
--MentalMouse42 (talk) 02:28, 26 March 2021 (UTC)
Addendum: Knowledge also matters a lot: E.g., iron golem farms require a lot of technical knowledge (or exact adherence to a plan), witch farms a little less, and (pigman-based) gold farms a fair bit. --MentalMouse42 (talk) 02:52, 26 March 2021 (UTC)
 Support removing from infobox and adding to obtaining. Also, string is definatly easier to obtain than bee nests.Humiebeetalk contribs 18:57, 26 March 2021 (UTC)
 Support moving from the infobox to the obtaining section. Some items definitely need a more thorough explanation rather than a simple yes/no.--Capopanzo (talk) 00:08, 2 April 2021 (UTC)

New Developementcategory.png[edit]

I think that the developement icon is kind of outdated. So I did a Roboto Mono version of it.– Unsigned comment added by Gugalcrom123 (talkcontribs) at 10:37, 31 March 2021‎ (UTC). Sign comments with ~~~~

Adding edit requests on the wiki[edit]

Currently, it is relatively hard for editors to request edits to protected pages. I have created {{edit protected}} to facilitate such requests. There is even an edit request at MediaWiki talk:Protectedpagetext, which is essential to bring edit requests to the entire wiki. Please discuss any improvements or your opinion below. Fadyblok240 (talk) 16:13, 31 March 2021 (UTC)

So first, the type of sentence "Copy the contents of this into that" won't work, as changing MediaWiki page is not as easy, as changing module, template,...
Secondly, if correct, the page can't be even edited due Fandom's MediaWiki whitelist (aka Abuse problems), so this would need to be discussed by community, and then pass this to WR.

--TreeIsLife (talk) 17:36, 4 April 2021 (UTC)

I  Oppose. While it is true that it is somewhat difficult to request an edit to be made on a protected page, we should instead make the Admin Noticeboard or the Community Portal have a section about that instead. Thejoaqui777 (talk) 19:28, 4 April 2021 (UTC)
Or better yet, on the page's talk page... Dhranios (talk) (Join the wiki videos project!) 19:36, 4 April 2021 (UTC)
I didn't say that all edit requests were going to be made on that particular page. In fact, the proposed template is designed to be placed on the corresponding talk page of the page to be edited. If you checked the wikicode of User:Fadyblok240/MediaWiki/Protectedpagetext, you would have noticed that. Fadyblok240 (talk) 00:37, 5 April 2021 (UTC)
How about we transfer the contents of some MediaWiki pages into templates, and fully protect these templates? If there is no cascading protection, then any administrator would be able to edit these templates to indirectly edit the MediaWiki pages. Only one edit to each MediaWiki page would need to be made, to make the page transclude the associated template. Fadyblok240 (talk) 00:37, 5 April 2021 (UTC)
Then why we even make these templates, when they will be fully protected? We can actually request few pages to be whitelisted, just you need to request that and say reasons why --TreeIsLife (talk) 09:28, 5 April 2021 (UTC)

Message box color criteria[edit]

Message boxes are the most used templates. And we defined recently a little criteria to see which templates should use a specific color. It was:

Criteria Class code Color displayed
Unclassified templates (default)
Warning for disclaimer/deletion of a page class = msgbox-red
Suggesting a page to be moved/split/merged class = msgbox-purple
Advice for maintenance issues class = msgbox-yellow
Information regarding the status of a page class = msgbox-green
Notice about a page's content class = msgbox-orange
Details about editions and/or versions class = msgbox-blue
Unused/custom purposes class = msgbox-magenta

But it was changed to:

Criteria Class code Color displayed
Unclassified templates (default)
Warning for disclaimer/deletion of a page class = msgbox-red
Suggesting a page to be moved/split/merged class = msgbox-purple
Notice for content issues of a page class = msgbox-orange
Notice for style issues of a page class = msgbox-yellow
Information regarding the status of a page class = msgbox-green
Details about editions and/or versions class = msgbox-blue
Unused/custom purposes class = msgbox-magenta

Which of the two should be the color criteria? The problem is the yellow and orange colors, so how should we use them?

 Extra comment: What is style? That's the problem with the second one. {{Rewrite}} would be style or content? What about {{update}}? Thejoaqui777 (talk) 14:16, 16 April 2021 (UTC)

 Support for the second one --TreeIsLife (talk) 13:23, 16 April 2021 (UTC)
 Support Same. – Unsigned comment added by MetalManiacMc (talkcontribs) at 13:47, April 16, 2021 (UTC). Sign comments with ~~~~
 Support the second one because of above.Humiebeetalk contribs 15:25, 16 April 2021 (UTC)

User talk:Mr.Ymnik[edit]

User:Mr.Ymnik created 2 images (File:Vestnik08.jpg, File:Bandicam 2021-03-10 16-16-40-217.jpg) for the purpose of creating a story that breaks Wiki Rule 4 (use an online translator if you can't read Russian). Although articles in the "User" namespace are exempt from rules 4, this is in the talk page and does not contribute to any wiki discussion. Should the talk page and the associated images be deleted? ~DΦC (talk) 19:43, 19 April 2021 (UTC)

Maybe move the page to a subpage of User:Mr.Ymnik? Also, pages in user space should never be referred to as articles. Fadyblok240 (talk) 22:48, 19 April 2021 (UTC)
Gotcha. So, I move the page to something like User:Mr.Ymnik/Vestnik Error? ~DΦC (talk) 22:52, 19 April 2021 (UTC)

SVG files for blocks[edit]

User:Arrran-gpuser created a number of svg files for block renders back in 2018. Should these remain on the wiki or be deleted? They don't currently serve any purpose and the files are ~10x the size of their png counterparts, but they don't get pixelated. ~DΦC (talk) 01:29, 23 April 2021 (UTC)

ComputerCraftedu[edit]

We have pages for Minecraft edu items/blocks, so what about items/blocks from ComputerCraftedu a mod not made nor owned by Mojang but that was also part of Minecraftedu. Like it would be strange if we had ComputerCraftedu info on this wiki but it would be more staring to have Minecraftedu info but not ComputerCraftedu info.– Unsigned comment added by Lego Starwars Timeline (talkcontribs) at 00:03, 29 April 2021 (UTC). Sign comments with ~~~~

Old Wiki theme[edit]

Is there any way to go back to the theme before the UCP? The one that actually looked like Minecraft? I think they disabled the option to switch back, but it would be nice if someone managed to replicate it with CSS.

Skywardthedragon (talk) 13:14, 30 April 2021 (UTC)

If you mean the old mobile theme, no, it's no longer available. The desktop theme should be the same for now (it's going to be changed later). --AttemptToCallNil (talk) 15:09, 30 April 2021 (UTC)

Minecraft plus exists[edit]

The screensaver collection `Minecraft Plus` is not mentioned on the front page of the Minecraft wiki. Even though it's free, and not a game, it's still part of the Minecraft brand so it should really be mentioned--TJC games (talk) 09:00, 1 May 2021 (UTC)

It is a joke feature 🙃 --TreeIsLife (talk) 15:28, 5 May 2021 (UTC)