Minecraft Wiki talk:Community portal

This is the community's main discussion page.

Talk about anything wiki-related here!

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

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

Edit other people's user pages for maintenance tasks?
Although the wiki warns you if you attempt to edit someone else's user pages, I don't know how strict I should interprete this warning. What if there is a maintenance task I'd be working on like eliminating non-existing template calls on pages, and someone has one such red link on one of their user pages, am I supposed to leave it there then because the page is not mine? Or am I allowed to edit user pages for that kind of purposes if it fixes red links (and thereby reduce clogged up special pages)? Secondly, is there any policy I could read up about this, maybe on wikipedia, and would the same policy apply to all (minecraft) wikis or would it be unique to every wiki? – Jack McKalling (t • c • p) 10:29, 20 November 2017 (UTC)
 * A cursory search on Wikipedia policy pages led me to this. This paragraph only mentions significant edits. I am unaware of actual Wikipedia practices on maintenance edits in others' userspace.
 * Personally, I see no reason whatsoever to prohibit editing others' user pages for maintenance purposes. Especially if that user is inactive for a long time and/or cannot be reached. --AttemptToCallNil (report bug, view backtrace) 10:41, 20 November 2017 (UTC)
 * . – Dentedharp90041tce 10:53, 20 November 2017 (UTC)
 * Ok, thanks. This will help me perform some maintenance on a lot of red links. – Jack McKalling (t • c • p) 11:44, 20 November 2017 (UTC)
 * I suggest creating a project to speed up this process. – Dentedharp90041tce 12:56, 20 November 2017 (UTC)

Deleted pages
Now that I've read through the pages you mentioned, I'm still wondering about certain red links in particular that I've come across, however. If someone mentions a template using tl, and the template has been deleted afterwards (not just when it is moved), creating a red link there, I wouldn't be able to resolve the link by renaming or removing it. The link would be discontinued altogether, but it would still show up in Special:WantedTemplates. I've noticed this often happens on old talk pages, in the middle of a discussion. It would not be advised to edit such links, but what else could I do then? – Jack McKalling (t • c • p) 11:44, 20 November 2017 (UTC)
 * Instead of deleting those, you can simply comment them out (enclose them in  and   tags). – Dentedharp90041tce 11:57, 20 November 2017 (UTC)
 * There is also tcode (which does not create a link), but it's not widely used. --AttemptToCallNil (report bug, view backtrace) 12:01, 20 November 2017 (UTC)
 * Thanks, both of those methods could work for me. Awesome! – Jack McKalling (t • c • p) 12:05, 20 November 2017 (UTC)

Translated pages
I'm sorry if this is getting annoying, but I really like to be absolutely sure about what I do or should do. When I attempt to work on the task of eliminating red linked template calls, usually I use the special pages to form a list. But on this English wiki, this list is totally cluttered with template calls on translated subpages, like Coal/ua, which calls the non-existing. Although I can see these translations are very old and also have their own interwiki (by now), and that these subpages could possibly be moved or removed altogether from the English wiki, I don't necessarily want to become involved in their translation process. There are a lot of these pages, and they are making our Special:WantedTemplates unusable. What could be done about these unused, "clutter" pages, all having non-existing template calls? – Jack McKalling (t • c • p) 12:21, 20 November 2017 (UTC)
 * Since some of them already have their own interwiki by now, I think you are allowed to remove these links, but only to the links which are supposed to be part of these interwikis, to avoid conflicts. – Dentedharp90041tce 12:26, 20 November 2017 (UTC)
 * Actually, my above example was not an instance that has its own interwiki, I cannot find the "minecraft-ua" wiki. I did find an example that does, like Nether_Wart/lt using, eventhough there is an [//minecraft-it.gamepedia.com Italian interwiki]. But I'm wondering more about those UA subpages, because there are a lot of them, probably because they should create an interwiki instead. – Jack McKalling (t • c • p) 12:36, 20 November 2017 (UTC)
 * Be careful in your example,, that's the Lithuanian language project, not Italian. – Sealbudsman talk/contr 12:49, 20 November 2017 (UTC)
 * Woops! The i was atually an L, I'll remember that when searching for appropriate translations next time. – Jack McKalling (t • c • p) 15:12, 20 November 2017 (UTC)


 * If a translated page is old enough, it may be removed so that a user may be able to translate the latest version of the English page into their chosen language. This also reduces the red links. – Dentedharp90041tce 12:53, 20 November 2017 (UTC)
 * I could swear I remember that templates weren't supposed to be translated until a project got its own subdomain... If that was the case, I could see it being inconsistently enforced, though.
 * If you come across translation subpages for languages that have their own subdomain, double-check that the page is on the language's wiki, and if it is, tag the subpage here for deletion. There's no reason for us to keep copies of these pages when there's already a dedicated subdomain for them. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 15:14, 20 November 2017 (UTC)
 * Ok thanks, I will check up on that. But if a language doesn't have their own interwiki/subdomain yet, they're not supposed to translate templates yet, and I can resolve their template red links on these subpages here by modifying them to point to our english versions? – Jack McKalling (t • c • p) 15:21, 20 November 2017 (UTC)
 * That's just how I remember things; I would want to find a discussion in which that is explicitly stated before I was comfortable enforcing it as a rule. Hvaing just checked, I didn't see anything relevant mentioned on MCW:Projects. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 15:32, 20 November 2017 (UTC)

Seasons
I see this done way too much, so I decided to post about it here. Can we please stop using seasons as time indicators. Seasons are not global, what is summer in the northern hemisphere is winter in the southern one. I know quarters (Q1, Q2, Q3, and Q4) are also far from perfect but I think they're way better than seasons.

This is not aimed towards anyone in specific, but I see people do this every so often and I figured I might as well try to stop them by posting here (small chance, I know. But still). --Pepijn (talk) 12:08, 25 November 2017 (UTC)


 * Maybe we could discuss putting this in the style guide? – Sealbudsman talk/contr 18:55, 26 November 2017 (UTC)

Problems with Wiki
Today, the look of the Minecraft wiki changed. Of course, the look by itself would be fine, but it also removed a lot of editing features and created many loading problems. It made it much harder to access subpages, because they aren't shown at the top of the page anymore, and did not allow visual editing - anytime I clicked on "Edit", it would stay at the reader's point of view. Also, when I tried to edit the source, which is the only editing available right now, there was no tool bar, which makes it very difficult to add images or references. Finally, ever since the look changed, the Minecraft wiki is loading much, much slower, and a lot of the time when I click "Show Preview" or "Save Changes" after an edit, it says that an error has occurred. All of this started just today.

Is the Minecraft wiki like this for anybody else, or is it just my personal computer? Also, does anybody know why this is or if there is a solution to it? Thanks. Madminecrafter12 (talk) 14:45, 25 November 2017 (UTC)Madminecrafter12 Madminecrafter12 (talk) 14:45, 25 November 2017 (UTC)
 * Gamepedia wikis experience many problems right now. Up to the point where I need to look at recent changes with the API. Nothing we can do. Gamepedia staff is aware of all of the issues. piotrex43 (Talk page) 17:10, 25 November 2017 (UTC)
 * Good to know, thanks for clarifying! Madminecrafter12 (talk) 19:44, 25 November 2017 (UTC)
 * Should be all good now! piotrex43 (Talk page) 20:00, 25 November 2017 (UTC)

Block renders.
Does anyone know who creates the block renders on the wiki and how they're created? --Pepijn (talk) 18:03, 27 November 2017 (UTC)
 * Minecraft Wiki:Standardized views This page might be helpfull for you ;) . –Preceding unsigned comment was added by Oakar567 (talk • contribs) at 19:12, 27 November 2017 (UTC). Please sign your posts with
 * Yes, thank you very much :D. --Pepijn (talk) 20:20, 27 November 2017 (UTC)

Demoting inactive admins
Currently, there are [ 12 admin accounts] (ignoring the special account, the staff accounts and , and Majr's adminbot ), of which five have not edited or performed any log actions in the past year (and of those five, four have been inactive for at least two years). A complete list of current admins, with date of their last edit or log action, follows: I propose to demote admins who have been inactive for a year or longer, as well as admins who have an extremely low rate of activity and haven't made use of any admin tools in at least a year. In these cases, a message would be left on the user's talk page, and (if possible) emailed to them, telling them their admin usergroup is about to be removed, and they would be given a month or so to respond if they wish; answering that they want to keep the group would be enough to prevent it from being removed. In addition, any admin who had their group removed purely because of inactivity would be able to request it back if they become active again.
 * - July 30, 2014
 * - today
 * - last month
 * - November 27, 2013
 * - June 22, 2011
 * - December 11, 2013
 * - September 27, 2016
 * - last month
 * - last week
 * - yesterday
 * - April 2, 2017
 * - January 19, 2017

The accounts who would immediately be eligible for demotion under this procedure include the five admins who've been inactive for at least a year (Citricsquid, Hower64, IKJames, Kanegasi, Kizzycocoa), as well as the three who've had a very low level of activity without any admin actions for a year (Oliver Scholz, Powup333, Quatroking). In the case of Citricsquid and Quatroking, their bureaucrat and checkuser usergroups would also be removed, and they would be able to request the groups back at any time, just like with the admin group.

For those accounts who are not admins/bureaucrats on another language version (Hower64, IKJames, Kanegasi, Kizzycocoa), this demotion would also include removal of the Directors usergroup. Activity on other wikis isn't being considered either; it's not my goal to implement this on any wiki but the English one (though other language wikis who want to implement their own inactive admin demotion process should feel free to do so regardless).

Note that this was inspired by Wikipedia's inactive admin demotion process (where I also cobbed a lot of the details for this initial proposal from), and the German wiki's similar process (though I don't have a relevant link for it); both of these have been running for some time now without apparent issues. Thoughts? 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 19:05, 27 November 2017 (UTC)


 * Sounds reasonable to me. To be clear, I wouldn't consider this as any sort of punishment for being inactive – life circumstances and interests change over time. (Personally, I know I don't have as much time to spend here as I used to.) Rather, it's de-cluttering the list of admins and making the wiki friendlier for new users. The abuse filter and other messages direct users to contact an administrator for assitance; if they try to contact an admin who hasn't been active in years (and possibly no longer uses the email address on file), they aren't likely to get a helpful response. I agree with the reinstatement policy: they've all proven trustworthy enough to be admins in the past, so if they want to be involved with the wiki again, I see no reason not to let them. -- Orthotopetalk 20:17, 27 November 2017 (UTC)


 * Yes, I probably didn't make it clear enough myself, but this wouldn't be a black mark on an admin's file or anything of the sort; being demoted for inactivity would be a purely procedural affair and shouldn't reflect on the admin themself.
 * Another argument for doing this is security: having inactive accounts lying around with these extra permissions is an unnecessary risk, in the event e.g. an account is compromised; or if a formerly-active admin has become disillusioned with the franchise or community or whatever, and decides to use their account's extra privileges to vandalize, or give it to someone who will; etc. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 20:28, 27 November 2017 (UTC)
 * This all sounds appropriate to me ^^ -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 23:15, 27 November 2017 (UTC)


 * This also sounds reasonable to me, especially since it would more accurately represent the amount of admins on this wiki. It is worth asking what would happen with Citricsquid's and Quatroking's rights on other language? In addition, I assume director rights would go with that? – KnightMiner  · (t) 05:23, 28 November 2017 (UTC)


 * I explained both of those in my opening: this would have no effect on other language wikis (though they'd be perfectly free to pursue demotions for inactivity themselves), and Director would be removed from admins if they have no rights on any other wikis. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 06:03, 28 November 2017 (UTC)


 * Oh, missed that one paragraph. – KnightMiner  · (t) 06:45, 28 November 2017 (UTC)


 * Looks good. A similar proposal is requested on the Russian Minecraft Wiki by AttemptToCallNil. —  BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 14:28, 28 November 2017 (UTC)


 * Can you link the Russian proposal, by chance? 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 19:17, 28 November 2017 (UTC)


 * That proposal was actually inspired by this one. --AttemptToCallNil (report bug, view backtrace) 20:05, 28 November 2017 (UTC)


 * Aah, thanks for the link. Looks like both proposals are on-track to be implemented. (Also, good idea pointing out that admins will need to answer on-wiki whether they want to keep their rights or not; I thought about that after the discussion here was underway.) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 20:24, 28 November 2017 (UTC)


 * Sounds good to me, for the reasons stated above. - Sonicwave ( talk &#124; c )  19:01, 28 November 2017 (UTC)


 * Sounds good to me too so far, but I wonder about a few things. What describes inacitivity exactly, or how do we decide when it is in effect? How exactly do we detect it, like by automated signal from the system or by manual inspection? And who detects it, a bot, a random user, or another admin? What is exactly done, when, and by whom, and where would we describe this process publicly? What if there is no active admin left to change user groups, that by some chance the last admin has become inactive by our previously determined definition? Will there be exception possibilities to inactivity? Lots of questions, but I guess that'd be the perfectionist in me and maybe not necessary ones. – Jack McKalling (t • c • p) 20:46, 28 November 2017 (UTC)


 * Everything's handled manually; we don't have enough admins to justify getting anything automatic set up (unless someone with the ability to do so, really really wants to).
 * As I explained above, "inactive" means no edits or log actions for at least a year, or a very low level of activity in the past year, without any admin actions in that time. This is determined just by looking at the admin's contributions and log actions. Anyone can check for inactive admins in this way, though there's no real reason to check very often.
 * Inactive admins are notified on their talk page (and by email, if they have it enabled) and given a month to respond; if they don't respond, or they answer saying to go ahead and remove their rights, a bureaucrat will remove the admin group, any other privileged groups (bureaucrat and checkuser currently), and (if the inactive admin is not an admin/bureaucrat on any other-language Minecraft wikis) the director group. If they answer instead that they want to keep their rights, the process stops there for them and they won't be demoted at that time.
 * Unless someone wanted to write up an administration/administrator project page where this could go, for now probably this discussion will serve as the public description of the process. If someone can point out a page we already have where it would be a good it, that would also be an option.
 * Even if all current admins/bureaucrats end up inactive for a year (pretty unlikely, but not impossible), staff can still remove rights if that's what the community wants, and then later promote someone else to admin/bureaucrat.
 * I think that's everything, please let me know if I missed something or if I didn't explain something very well. =) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 22:05, 28 November 2017 (UTC)


 * Hello, inactive admin here. I hold no strong objections, though it will be a shame, having worked on this wiki for quite some time.
 * I was kept on, because the old Gamepedia rep Wynthyst (Rest in peace) said that it was useful to have old admins on the books, in the case of emergencies. I've been open to step in during such emergencies. but, I doubt I will ever retain any full-time moderation here. If it is the policy of the Minecraft Wiki to remove my adminship, I've no objections.
 * my only concern is that, in being demoted, I will no longer be able to pop in now and then to curate the Herobrine page specifically, of which I have quite a history. I was banned by fellow mods at least twice for creating the page, in an attempt to address "Herospam" (which, as I predicted, is now largely ancient history, as the page eradicated any need to vandalise other pages). I have also run interviews for the page with previous community figures who were involved in the initial hoax. I am a trusted editor for that page, and will not vandalise it. It is one of my proudest contributions to the Minecraft community, second only to the in-game implementation of Cake after my Quest for Cake campaign on ModDB.
 * If it is within the admin's power at all, I would like to retain access to that specific page so I can do some cleanup on it as and when updates arise and I find myself on the MCWiki, viewing that page. Beyond that, I do not feel I will need any access to the admin tools in the long run, unless I am needed in an emergency. So again, if it's the policy of the MCWiki, I have no objections to being demoted. --Kizzycocoa 03:22, 29 November 2017 (UTC)


 * Keep in mind that being demoted for inactivity isn't a black mark on you as an editor; it would be purely procedural and you could ask for the right back at any time if you needed it again. =)
 * I note that the protection on Herobrine hasn't been touched since mid-2011; I'd be willing to try and see if it can be lowered to semi now, if no one thinks that would be problematic. Another option would be for you to retain the Directors group, which would allow you to continue editing Herobrine (and other protected pages) without requiring the protection level to be dropped. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 04:26, 29 November 2017 (UTC)
 * Oh, not at all. I fully understand this isn't a black mark. People just, shift interests. I was interested in Minecraft, then drifted onto Portal, then FNaF and now, sorta drifting a little. these things change.
 * I would strongly advise against unprotecting Herobrine. I feel that page is a vandalism magnet, and that allowing it to be edited would be a bad idea.
 * I would be perfectly happy with the Director solution, provided this is not objectionable to the Minecraft Wiki community and moderation. --Kizzycocoa 12:26, 30 November 2017 (UTC)
 * I'd like to second this suggestion (in relation to keeping Herobrine protected). I've seen what the name 'Herobrine' can do on the forums and if not a vandalism magnet then I cannot help share my worries about pranks and such. Some topics can be toxic. ShelLuser (talk) 14:32, 30 November 2017 (UTC)


 * Yeah, I agree the director solution would make sense. You are easily reachable and still use your account, so it is not like it is admin rights lying around on an inactive account. I also feel like with your editing style, unless you plan to stay for awhile, requesting rights back to make one quick edit is not really practical (might as well request the edit), so I support you keeping the ability to edit Herobrine. – KnightMiner  · (t) 19:41, 30 November 2017 (UTC)


 * Sounds reasonable to me as well, however I do want to make one comment: do be careful that we don't favour quantity over quality. With this I'm specifically referring to the second part of the suggestion regarding "low rate of activity", sometimes quality heavily outweighs quantity. However, I definitely agree that no activity within one whole year easily accounts for that. But still wanted to share. ShelLuser (talk) 13:04, 29 November 2017 (UTC)

Merge bark with wood
Just want to get some more opinions on it, see Talk:Bark. A user named has also been trying to make pages for the smooth blocks that finally got an item form in the 1.13 snapshots (but were in the game as blocks for a while). I think these smooth blocks can just go under the block page they are the smooth "variant" of, no need for a separate page. --Pepijn (talk) 12:38, 9 December 2017 (UTC)

I have a problem with Korean wiki, So I would like to ask for help.
Hello, I'm a korean wiki users. I need some help, so I write this article. At the Obtaining(구하기) section In the Mushroom (block) page in korean wiki, the color of the table(red, green etc.) is not displayed and strange words('style="background:') are displayed. Other documents(Documentation of template:version, too. Why happens this problem? I couldn't find the answer. Anyone who know the solution please leave a comment here. Thank you. –Preceding unsigned comment was added by Leehan020816 (talk • contribs) at 7:18, 13 December 2017 (UTC). Please sign your posts with
 * I added the english names back to ko:틀:Table Choice because they are used by some templates. That fixed your problem.  HorseHead.png MarkusRost (talk) 08:09, 13 December 2017 (UTC)
 * Thank you! Now it works fine !! Thank you for editing :-)--Leehan020816 (talk) 12:01, 13 December 2017 (UTC)

Second level horizontal lists no longer use small font

 * L1_1
 * L2_1
 * L2_2
 * L2_3
 * L1_2

produces:


 * L1_1
 * L2_1
 * L2_2
 * L2_3
 * L1_2

(The styles are to differentiate the output from the rest of the text.)

There's also an extra space after opening parentheses of such lists which can be removed if the first sublist element is written without any space after the initial asterisks.

There is also some extra space before closing parentheses which cannot be selected or removed via code formatting changes. --AttemptToCallNil (report bug, view backtrace) 19:16, 15 December 2017 (UTC)
 * Edit: I primarily meant navboxes. I definitely recall them using small font for inner lists. --AttemptToCallNil (report bug, view backtrace) 19:23, 15 December 2017 (UTC)


 * Don't you mean third level horizontal list that is made smaller?


 * L1_1
 * L2_1
 * L2_2
 * L3_1
 * L3_2
 * L2_3
 * L1_2


 * namely produces:


 * L1_1
 * L2_1
 * L2_2
 * L3_1
 * L3_2
 * L2_3
 * L1_2
 * which, to me, seems like it has always been the case. Second-level horizontal list is put between parentheses and normal font size and third-level horizontal list is put between parentheses and smaller font size. As for the spaces between the parentheses and the text, I think it is a CSS issue (especially the right parenthese), likely something with  in several CSS rules that determine how the horizontal list looks like. --  DarkShadowTNT  NL Admin ( t  ♦  c ) 19:35, 15 December 2017 (UTC)
 * Doesn't that mean navboxes used to use third level lists? Or am I too tired to remember correctly, and typical navbox sublists were never written in small font in first place? --AttemptToCallNil (report bug, view backtrace) 05:43, 16 December 2017 (UTC)


 * I do recall seeing some navboxes using third level lists in the past. It seems they don't use the third level lists anymore, maybe because the text was a tad too small to click or tap on properly. At least, for navboxes that are used on most pages. Navboxes from the Aether mod, for example, do use third level lists and maybe some other mod pages too. -- DarkShadowTNT  NL Admin ( t  ♦  c ) 13:40, 16 December 2017 (UTC)


 * The spacing that is mentioned has been changed recently to fix a small issue in navboxes, see here. – [ Jack McKalling ] [ Grid Book.png Grid Book and Quill.png Grid Diamond Pickaxe.png ] 13:53, 16 December 2017 (UTC)

Where should data and protocol versions be documented?
There's two pieces of version-specific information that aren't currently documented on this wiki:


 * Protocol versions, which are used in the network protocol to make sure servers and clients are compatible.
 * Data versions, which are used in chunks and in other files for the DataVersion tag, so that data can be upgraded between different versions.

While neither of these things are useful for the average player, they're useful for developers. Protocol versions are currently documented on wiki.vg (n.b. the overlap between content here and on wiki.vg is another thing which I've been meaning to post about for around a year but haven't gotten to yet, but let's just not worry about that for now). However, data versions are undocumented on either wiki. I've generated a list of them using Burger, though.

Where should these be put on this wiki? For sure it would be useful to have them on Version nav, but I'm thinking it'd also be useful to have them (or at least data versions) on another table somewhere so that it's easy to look up the version(s) corresponding to each number.

I'd be willing to handle adding the information to whatever articles need it (I may want to script the process though since it'd be adding information to all the versions). I just don't know where. --Pokechu22 (talk) 00:03, 17 December 2017 (UTC)


 * Are there any arguments or reasons not to add "Data versions" and "Protocol versions" articles (or maybe "version history", to match our other version history pages)? If not, I think that'd be the natural choice. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 00:51, 17 December 2017 (UTC)


 * The only issue I have with that is that it feels awkward to create articles for each. Maybe a combined "Version numbers" article would be better.  (Also, there is PE; I have no clue how or if PE numbers its protocol) --Pokechu22 (talk) 02:47, 17 December 2017 (UTC)


 * If the mentioned subjects are about the internals of the game engine, so technical that it requires reverse engineering to figure out, then it's probably not intended for the scope of this wiki. The source code is not meant for the public, it is obfuscated for a reason. So I don't even think doing this is legal. I'm not sure though, I just glanced over these subjects and I'm not certain what it's all about. But that's my two cents. – [ Jack McKalling ] [ Grid Book.png Grid Book and Quill.png Grid Diamond Pickaxe.png ] 20:11, 17 December 2017 (UTC)


 * Data versions are stored in several parts of NBT. We document the NBT format even though that's internal.  Also, MCP is (partially) maintained by mojang devs (Searge in particular) -- in particular the SRG deobfuscation mappings -- and the EULA doesn't prohibit reverse engineering (only redistribution) unlike that for most games.
 * Whether or not it is in scope is a valid question, though. wiki.vg hosts the majority of the technical documentation (except for some classic stuff and other things, but again I'm not ready to hold the discussion about the overlap yet); it would be entirely possible to put the documentation for data versions there (PVNs are already there). --Pokechu22 (talk) 20:20, 17 December 2017 (UTC)


 * I see reason to be cautious about this. This very technical data will have to be obtained, maintained, and explained by experts well versed in the subject matter. Will the data be verifiable by means of automation and be noncontroversial as to its meaning and interpretation? Probably both, but if there's room for differing opinions we could get ourselves stuck between two camps of experts with no way to vet any statements they make nor participate with them in the consensus building process. In a normal wiki you'd have a professional community to fall back on, but you won't have that in this case. – Auldrick (talk &middot; contribs) 23:45, 17 December 2017 (UTC)
 * Very good point. I would consider this one of the reasons for it being out of scope. All editors should have equal viable access to the source of information, like in-game observations, twitter posts and the website, but internal source code which would require expert analysis does not belong to that. It would at least require (Java) programming knowledge and trusted deobfuscation technologies. I wouldn't classify the NBT format to be internal source code however, as it is a portable format used to communicate with the source code. It's more of a data container similar to json files, used to e.g. enhance in-game command abilities. So NBT does fall under the scope of this wiki and is open to be used and interpreted by the public. – [ <span class="gamepedia_pro_user">Jack McKalling ] [ Grid Book.png Grid Book and Quill.png Grid Diamond Pickaxe.png ] 00:10, 18 December 2017 (UTC)
 * Burger, which I mentioned before, automatically extracts this data. Here's sample data for 17w50a (well, that's actually burger + burger vitrine; burger itself gives json data).
 * There's other internal data we have on the wiki. For instance, numeric entity IDs are not displayed anywhere in game, but are cataloged on here (and on wiki.vg).  Hardness is also an arbitrary, non-observable value (break times are, but individual hardness isn't), and we catalogue it; we also catalogue blast resistances. --Pokechu22 (talk) 00:22, 18 December 2017 (UTC)
 * Also worth noting that data version numbers are observable via just launching each version, loading a world, and observing the information in level.dat. However, protocol version numbers aren't observable that way, so it's either burger or capturing the handshake packet for each version.  --Pokechu22 (talk) 00:28, 18 December 2017 (UTC)


 * I have no problem with us documenting NBT data, data/damage values, IDs, or any other internal data as long as it's verifiable and noncontroversial, which was the point of my comment. I'm reassured by these replies. – Auldrick (talk &middot; contribs) 00:50, 18 December 2017 (UTC)

I've learned (by complete happenstance and on two separate occasions) that: <ul> <li>The German wiki currently has data versions, listed both on their version history page (which has multiple versions on it) and an incomplete list on their data values page. (I don't speak German).

What's more, they also mention that you can use to check data versions and branch with command blocks -- but this probably also means that it's visible through. So that's a way to verify these ingame, without even using an NBT editor.</li> <li>The Dutch wiki has added protocol version numbers to their version pages (as mentioned in the Gamepedia slack). They actually did this in a way that didn't require bulk edits to all of the pages; instead, they changed their version nav template to automatically add the version:

which we'd probably change to something like:

They did this by creating a template that gets the version number given a version's name, using this module and this data. It looks like since then, they've also done the same for data versions.

The template can also generate a table, but the keys aren't sorted right now so that's a bit of a mess -- something for someone who knows lua better to handle.</li></ul>

I think that we should probably take the same approach as the dutch wiki, with the template to add the information automatically. While the template does mean you need to edit a different page to add info to the article, you'd still need to manually edit it to add it to a table that would be on data values; the template can do both and it would also mean that we wouldn't need to edit all the old articles.

The one thing that may be difficult for us is that we use our version nav template for all editions of the game, while they only cover Java Edition. So while they only have a few versions that would have no protocol info, we have a ton of them. (PE does actually appear to have a protocol version of some sort, but I don't know if the values for it are documented and I don't work with PE). A similar issue is present for data versions, as only versions after 1.9 have them; we wouldn't want to include info about those on versions they don't apply to.

In case it wasn't clear, I also thing it makes sense to put both of these numbers in the data values page; IMO there isn't a need for a separate article.

Anyways, those are my rambling thoughts. --Pokechu22 (talk) 01:43, 8 January 2018 (UTC)


 * Bump, sort of. I've edited the links in the text above to link to the correct modules, as I've renamed the modules while updating them (for hopefully a while, not counting releases). They still do the same thing, though. Thanks to pokechu22 tables are now generated correctly (see here) and we now only have to edit one module instead of two to get the version data in, which is good. -- DarkShadowTNT  NL Admin ( t  ♦  c ) 15:56, 27 January 2018 (UTC)

Wiki inconsistencies
As I was looking through this wiki, I noticed a few inconsistencies that need to be addressed.


 * About a year ago at Talk:Diamond it was said that diamonds being obtainable by mining a nether reactor core is for the history section only, and is not to be included under Diamond,(as per mcw:UPTODATE). However, at Iron Ingot it clearly lists that mining a nether reactor core drops iron ingots. This goes against what was said on the diamond talk page before. Something needs to be done: either remove Iron Ingot from the Iron Ingot page, or add nether reactor core info to the Diamonds page.
 * At 1.3.1, it says that the /kill command was added in 1.3.1. However, at Commands it says that the /kill command was added in 1.2.6. Which is correct?

This last one is less of a concern but I'd figure I bring it up anyway:
 * Concerning the Spawning section in mob articles and what information is allowed there. At Talk:Chicken it mentions that the fact the Chickens being able to spawn as Chicken Jockeys does not exist under Chicken because the Chicken Jockey's spawning is "handled when a baby zombie spawns". However, at Skeleton the fact that skeletons can spawn as a Spider Jockey and as a part of a skeleton horse trap are documented there. Using the above logic, neither of those should be there, because the skeleton doesn't handle the spawning for either (the spider/skeleton horse trap does). You could even take it one step further and say the same on other articles, (e.g.: Witch wouldn't say that witches spawn from villagers struck by lightning, because the spawning is handled by the lightning and not the witch). The point is, I vote to add that chickens can spawn as chicken jockies under Chicken because that would make it consistent with every other mob article on this wiki.

-EatingSilencerforBreakfast (talk) 01:58, 17 December 2017 (UTC)


 * Regarding /kill: The command does not exist in the release 1.2.5 server, but does exist in the release 1.3.1 server. However, the comment about alpha 1.2.6 was added at the time that version was released.  So probably, the command was removed somewhere in the middle.  Unfortunately we don't have servers for those versions, so it's not possible to check when it was removed :/
 * Regarding chicken spawning: adding it there (making it clear that it is the zombie that does the spawning, though, because the spawn conditions vary) --Pokechu22 (talk) 03:03, 17 December 2017 (UTC)

Regarding the /kill part, during Alpha 1.2.6, it was only for SMP (Survival Multiplayer). It was added to single player on release 1.3.1 Skylord wars (talk) 09:17, 17 December 2017 (UTC)


 * I've removed the nether reactor bit from the iron ingot page, as I believe it's uncontroversial in being out of date - please challenge me if I'm wrong.
 * I support mentioning chicken jockey spawning, as Pokechu describes. – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 05:44, 18 December 2017 (UTC)


 * I added the chicken jockey information at Chicken. -EatingSilencerforBreakfast (talk) 01:12, 27 December 2017 (UTC)

I noticed something similar. On the Beta 1.9 Prerelease 2 page it says that "Milk is now drinkable, resetting all potion effects currently afflicted upon the player." However, the milk page says that milk was made drinkable in Beta 1.8 but wasn't able to cure status effects until Beta 1.9 Prerelease 2, and on the 1.0.0 page, it mentions absolutely nothing about milk. --Madminecrafter12 (talk) 02:35, 4 January 2018 (UTC)

Mod Screenshot Licensing
How should files of screenshots that show mods in Minecraft be licensed? I know it's showing the game Minecraft, which would usually be Mojang, but because it shows mods that are not supported by Minecraft, shouldn't it use a separate license? --Madminecrafter12 (talk) 20:58, 1 January 2018 (UTC)
 * Correct. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 22:16, 1 January 2018 (UTC)

Internal error with history for "Tutorials/Creating a challenge map"
When I click on the "history" tab for the page Tutorials/Creating a challenge map, it has a giant box in red saying, "[7ae048a3990d5e9ae0099026] /index.php?title=Tutorials/Creating_a_challenge_map&action=history Wikimedia\Assert\ParameterAssertionException from line 63 of /var/app/current/vendor/wikimedia/assert/src/Assert.php: Bad value for parameter $dbkey: invalid DB key 'Brenn_'", and then it keeps going. The name of the page says it is "internal error". See https://minecraft.gamepedia.com/index.php?title=Tutorials/Creating_a_challenge_map&action=history, and you'll see what I mean. Does anyone know why this is and how to fix it?--Madminecrafter12 (talk) 01:33, 13 January 2018 (UTC)
 * Comment: you need to set your displayed changes limit to 250 or higher to get this error. A limit of 100 will not produce this error.
 * This seems to be caused by an invalid username in history. This is not the first time such an error occurs, and like the previous time, it should be reported to Curse. --AttemptToCallNil (report bug, view backtrace) 06:47, 13 January 2018 (UTC)


 * These are the first and last diffs that cause the issue. -- Orthotopetalk 07:05, 13 January 2018 (UTC)


 * I had [ this problem] for another page too, but it's fixed now. – [ <span class="gamepedia_pro_user">Jack McKalling ] [ Grid Book.png Grid Book and Quill.png Grid Diamond Pickaxe.png ] 10:39, 13 January 2018 (UTC)


 * Fixed by Gamepedia staff. --AttemptToCallNil (report bug, view backtrace) 15:22, 13 January 2018 (UTC)


 * Great, thanks! --Madminecrafter12 (talk) 19:27, 13 January 2018 (UTC)
 * Also, the maximum number of changes I have is 200, which is not 250 or higher, so I don't know why the error happened. --Madminecrafter12 (talk) 19:28, 13 January 2018 (UTC)
 * Never mind, I previously didn't read Orthotope's comment thoroughly--Madminecrafter12 (talk) 19:29, 13 January 2018 (UTC)

Archive this page
Someone? It's already 2018. – ITechieGamertce 14:45, 18 January 2018 (UTC)

Plural case of redirects
I'm not exactly clear on when a plural redirect is acceptable. There have been many times when I have made a redirect to a page that's the plural case that the page got deleted, and other times where there was no request for deletion. I looked in the "Redirect Cleanup" project and it said that plural redirects should only be used when the singular case could not be linked to when writing the plural case (for example, Grass Blocks would be possible). However, if this is true, than hundreds of the redirects on the Minecraft Wiki that have been existing for many years, would have to be deleted (Zombies, Sponges, Slabs, etc.). Could somebody please explain when a plural case can become a redirect, even if the singular case could be linked to when writing the plural case?-- Madminecrafter12 Talk • Contributions 14:11, 11 February 2018 (UTC)


 * It's all about if the editor who cares about redirects saw the change in recent changes. As you can see, that project isn't really active, and while I'd go for the option #3 for redirect usefulness (no plurals at all, use pipe links instead) the consensus so far is keeping less regular plurals because they are actually useful for linking. Really, I think that this project could use some activity, I'm thinking about suggesting some categorization for redirects. Even a few templates keeping them in some nice categories like in WP:TMR would be useful, to be honest. --Hubry (talk) 16:48, 11 February 2018 (UTC)
 * Thanks for the info! For now I think I'm not going to make any plural links, but not mark existing ones for deletion, until it's more clear what the best option would be.-- Madminecrafter12 Talk • Contributions 17:05, 11 February 2018 (UTC)


 * As far as I'm concerned, deleting these redirects is a waste of time; redirects are cheap, and there's no point to deleting redirects unless they're actually problematic (vandalism, preventing a pagemove, etc.) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 10:39, 12 February 2018 (UTC)


 * ...thanks for linking that, I think I am a bit deletion-happy in case of redirects and you are right. Though I still think the amount of redirects we have for some pages is slightly excessive, I will stop marking those for deletion. I think WP:CHEAP should probably be mentioned in the style guide. --Hubry (talk) 12:59, 12 February 2018 (UTC)


 * In my personal opinion, I see no big problem with having plural redirects, as like mentioned on WP:CHEAP, redirects take up very little space. Also, as a user, I've noticed that plural redirects seem to make searching easier - for example, the reason I created the redirect, Tutorials/Command blocks (it's now deleted), is because many times I would search for that, and I would have to take the time to search for the page Tutorials/Command block (which, admittedly, does not take much time, but I still think that a redirect here would be helpful here). On the Redirect Cleanup talk page, users have mentioned that part of the reason why plural redirects are unnecessary is because if somebody searched for a page of the plural case, the singular case is bound to come up first. But the thing is, the search system takes a second or so to register what is being typed, and that's after every letter, meaning that if a user searched in the search box at normal typing speed, the singular case page would not come up before they have fully typed the plural version of the page. However, if most of the community thinks that new plural redirects are unnecessary (which it currently seems like they do), I don't think it's necessarily worth it to have a huge discussion on it.-- Madminecrafter12 Talk • Contributions 17:05, 11 February 2018 (UTC)


 * At minimum, I'd say redirects like Entities for Entity should be kept (as I'm not aware of a way to do  or something like that).  I'd say though that more redirects for similar forms are useful though, for user use &mdash; e.g. I created ids a while back to redirect to the data values page because I didn't want to type the whole thing (mainly for entering right into the address bar, not searching, though it's useful for both).  --Pokechu22 (talk) 16:21, 12 February 2018 (UTC)

Stripped Log
Something very strange is going on with the stripped log page. The whole toolbar is covering the page, and the history template is not working correctly. As for as I know, there is nothing I added that should cause this, so I'm not sure why this is happening.-- Madminecrafter12 Talk • Contributions 23:48, 14 February 2018 (UTC)


 * There was a missing curly brace, so it wasn't transcluding the history footer. The resulting unclosed html tags cause major layout issues. -- Orthotopetalk 00:02, 15 February 2018 (UTC)


 * Great, thanks, I didn't even notice that was there.--Orange Glazed Terracotta.png Madminecrafter12 Talk • Contributions 00:22, 15 February 2018 (UTC)


 * Sounds like this was a case for Minecraft Wiki:Projects/Cleanup open tags. However the unclosed tag was in a used template in this case as said above. If you check that project page, it'll give a thorough explanation on what happens and why, which may help you when you encounter a similar case in the future. The project should have covered all article pages already, but unfortunately the problem keeps happening if not everyone is aware of this. – [ <span class="gamepedia_pro_user">Jack McKalling ] [ Grid Book.png Grid Book and Quill.png Grid Diamond Pickaxe.png ] 11:08, 19 February 2018 (UTC)

Complex turtle behavior?
In this article, Java edition developers mention some complex turtle behaviors that aren't already mentioned at Turtle (such as turtles having a home beach). I'd add them to the turtle article but I'm not sure how some of them work. -EatingSilencerforBreakfast (talk) 21:56, 17 February 2018 (UTC)


 * I think it would be safe to mention that on the page, as it seems pretty clear that this is a fact. Many times it seems like Minecraft developers say something that is not a fact just to further describe the fact, but in the article it seems like it's written like it's true fact.--Orange Glazed Terracotta.png Madminecrafter12 Talk • Contributions 14:15, 18 February 2018 (UTC)


 * I've added it to the article.--Orange Glazed Terracotta.png Madminecrafter12 Talk • Contributions 14:39, 18 February 2018 (UTC)

Another wiki inconsistency
I found another wiki inconsistency and decided to post it here before I make any changes:

On some animal articles (specifically Horse, Pig, Sheep, Llama, and Rabbit), information about breeding is stored in their 'Behavior' section. However, in other animal articles, its stored under 'Spawning' (specifically Cow, Mooshroom, Chicken, and Ocelot). Wolf and Villager are different in that breeding is kept in a separate section of its own. For consistency, I say that breeding should be documented in a singular section across the entire wiki (all Breeding sections be under Behavior, for example).

-EatingSilencerforBreakfast (talk) 00:28, 27 February 2018 (UTC)


 * I would go with either a separate section or put it under Behavior. However, I would be fine with putting it under "Spawning," but I do agree that there needs to be one thing throughout. The style guide for features does not say anything about breeding, so once we come to a decision, we should make sure to put it in the style guide.--Orange Glazed Terracotta.png Madminecrafter12 Talk • Contributions 00:47, 27 February 2018 (UTC)


 * I don't think the style guide prohibits you doing it one way or the other, and I'm not sure it fits better in Spawning or Behavior or on its own. I don't so much care which one we choose, I just agree it's good to pick one and be consistent. –  Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 03:02, 28 February 2018 (UTC)