Minecraft Wiki
Register
Advertisement

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 to MCW:Admin noticeboard and discussions about a single page do not belong here.

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


Clock circuit, Logic circuit, Pulse circuit, Memory circuit, Transmission circuit

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

 Weak oppose. According to MCW:NOTABILITY, "Gameplay strategies, guides, how-to's, etc., should be subarticles of Tutorials." The redstone articles are more like a encyclopedia than most tutorial pages. Tutorial pages are usually aimed more at readers wanting to construct something rather than to learn about something. That doesn't necessarily mean they couldn't go under tutorials though. jahunsbe (talk) 13:30, 12 March 2019 (UTC)
 Oppose. But I agree at the same time, that they're not right in their current state. These pages are not tutorials in the same sense of the word like the other tutorials. They are indeed more about documenting something rather than guiding you through something. These pages are documenting game mechanics, and are using a completely different tone than any other "tutorial". Similar to enchantment mechanics, which has been (in my opinion) erroneously moved to a subpage of Tutorials. I bet there are more examples of this, like anvil mechanics, village mechanics. You can see the pattern here. In my opinion we should rather be looking for a new top level page, like Mechanics (for game mechanics, redstone mechanics, anything about not specifically one particular game object), next to the tutorial one, and then move all these pages as a subpage of that instead. – Jack McKalling [ Book and Quill Diamond Pickaxe ] 14:57, 12 March 2019 (UTC)

Proposal

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

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

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

Reversion of the proposal

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

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

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

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

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

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

I oppose the current proposal, but I would support moving them to something like Villages/Mechanics (for example). It keeps these pages better tied to their parents, is much more clear, and could help with the accessibility issues by having them clearly linked on their main pages. One problem with the current proposal is that simple redirects don't work. You can't just have Village redirect to Mechanics/Village, as the main village page is still used. -PancakeIdentity (talk) 20:40, 13 October 2019 (UTC)
Thanks for you guys' imput. Sad it was late, sorry that this caused frustration, but better late than never. This is yet another case where the com portal's function failed. Please understand your feedback is and will always be welcome, regardless of frustrated reactions. Anyway, I too am not an expert in SEO/searchability/redirects. I should have provided arguments for my proposal though. I've participated in the tutorials discussion too, and because you and others opposed to namespaces, I didn't again suggest it here. However these pages do share similarities with the tutorials, and I wanted to address that. Although I didn't start the discussion, I did have the very same idea before and had clear ideals. I'd gladly hear any other proposals, because my main point is and will be, these pages aren't following the proposed article structure as suggested by the style guide, and this has to be addressed in some way. – Jack McKalling [ Book and Quill Diamond Pickaxe ] 21:06, 13 October 2019 (UTC)
I think you had the right idea, but I disagree with the details. I'd propose moving the mechanics to pages like Village/Mechanics, Trading/Mechanics, etc. I would also propose moving the redstone circuits to something like Redstone/Circuits/X. –Preceding unsigned comment was added by PancakeIdentity (talkcontribs) at 22:52, 13 October 2019 (UTC). Please sign your posts with ~~~~
I would actually support that far more than "Mechanics/Village", etc. I believe it is more meaningful to have the mechanics pages be structurally/logically dependent on the thing mechanics of which are described than on the concept of mechanics. I might actually support the same with tutorials, like mob farming and combat tactics as subpages of corresponding mobs, and e. g. "Cactus/Farming". --AttemptToCallNil (report bug, view backtrace) 23:50, 13 October 2019 (UTC)
This proposal of PancakeIdentity & ATCN makes sense to me; I support that scheme. Memetics talk | edits 07:30, 26 October 2019 (UTC)
Here's the fact. Tutorials are community-made guides that guides you in the game. They are never official guides by Mojang or in the game. Logic gates, redstone circuits are all community-made concepts, they're not coded into the game. Mechanics in the other hand such as enchantment mechanics are mechanics that are coded in the game. I can't think of a good proposal, but I'll  Support PancakeIdentity because it makes much more sense.--skylord_wars (talk) 16:36, 28 October 2019 (UTC)
I would also support making them subpages when available.  Nixinova T  C  01:45, 6 November 2019 (UTC)
Great, I also like this proposal better than mine. It's good to have consistency, and giving each article that has specific mechanics its own /mechanics subpage makes sense and keeps these related and close together. I agree that is better than keeping all mechanics subpages together instead. Now that I've seen the latter in action in page titles and links, it doesn't even look right after all anyway. For readers it makes more sense to go from for instance "village" to "village/mechanics" than to "mechanics/village", because it's a completely separate top level page. – Jack McKalling [ Book and Quill Diamond Pickaxe ] 15:15, 11 November 2019 (UTC)
 Support moving pages to Mechanics/x and having redstone circuits as tutorials, per the arguments described above. I am wondering if, for example, the Village page should transclude its mechanics page using {{LoadPage}}. The BlobsPaper 23:06, 5 January 2020 (UTC)
 Support moving mechanics pages to the Village/Mechanics format for reasons given above. I'm not sure about tutorials though, since there are some tutorial topics that don't have a clear root article (e.g. Tutorials/Tips and tricks) and they tend to contain more subjective information than regular articles. We could add a template to the top of all tutorial-style articles to inform readers that the article is a tutorial or has community-made content. –Sonicwave talk 01:35, 5 February 2020 (UTC)
I've gone ahead and  Moved the village, enchanting, and anvil pages to the format "X/Mechanics" because I feel like there's a pretty clear consensus to do so.
I'm not clear on what needs to be changed about Trading and Dyeing, because if these two pages were moved as is, neither would have a base page. For trading, are we suggesting that it should be moved to Trading/Mechanics and have Trading redirect there? If so, that seems unnecessary and by that logic, the enchanting, brewing, and smelting redirects should exist only as redirects to their mechanics subpages. And for Dyeing, dye is actually a collection of items in the game so moving that makes even less sense; is the suggestion to split the dye page into one article about the items themselves and another about the mechanic?
I haven't moved the redstone pages yet because I don't think it's clear yet from this discussion whether they should be mechanics subpages of Redstone or tutorial pages.--Madminecrafter12 (Talk to me | View what I've done) 15:22, 5 February 2020 (UTC)
I see no reason to enforce a pointless redirect scheme for the sake of ensuring page relation consistency. If the mechanics are not descendants of a base something, they are a base something. Support leaving the above as is (without any moves or redirects). --AttemptToCallNil (report bug, view backtrace) 15:33, 5 February 2020 (UTC)
Yeah, that's what I was thinking.--Madminecrafter12 (Talk to me | View what I've done) 23:35, 5 February 2020 (UTC)
Re:dye; I think that was the idea. I would support just having a "Dyeing" page and no mechanics subpage. -PancakeIdentity (talk) 05:08, 6 February 2020 (UTC)
About the redstone pages, I  Support having them be subpages of redstone rather than tutorial pages. Putting them under redstone keeps them all better organized in one place. It would, however, probably be helpful to have links to the pages in Tutorials and maybe Template:Tutorials. I think the "Redstone/Circuits/X" format mentioned above would work well with Circuits having a list of subpages. jahunsbe (talk) 15:11, 10 February 2020 (UTC)
This is why Wikipedia has disabled sub pages in the main-space. --Fadyblok240 (talk) 23:41, 16 August 2020 (UTC)

Sound file attribution

This was discussed before in this archived thread, but didn't get very far. Samuel Åberg's twitter ("slamp0000") describes him as the lead sound designer for Minecraft; however most sounds on this wiki have {{License C418}} slapped on them. In addition, this minecraft.net attribution page shows that some sounds were taken from Freesound.org, though likely edited afterwards. Since it's not clear which sounds were created by C418 or slamp0000, perhaps all non-music sounds (not taken from Freesound) should simply be tagged with {{License Mojang}}; the sounds listed on the "Sound attributions" page would instead be tagged with the license listed there. –Sonicwave talk 19:03, 27 August 2019 (UTC)

Not a licensing expert, but I agree with this proposal. --AttemptToCallNil (report bug, view backtrace) 19:05, 27 August 2019 (UTC)
I might go ahead and begin slowly changing the non-music sound descriptions to use {{License Mojang}} instead of {{License C418}}. I'm not sure how to figure out which sounds are from Freesound without listening to everything on the attribution page and seeing what sounds familiar, since the files don't have attribution info in their metadata (unless I looked in the wrong place).
Also, License C418 says "In agreement with C418, Minecraft sounds are allowed to be hosted on the wiki. All music must be shortened to the first 30 seconds"; is this agreement publicly viewable or was it made through something like a private IRC channel? –Sonicwave talk 06:11, 5 October 2019 (UTC)
 Support. Sounds we know specifically to be from C418 (with a source) should still use the license, but I think using the general Mojang license is better in most cases. -PancakeIdentity (talk) 04:38, 20 May 2020 (UTC)

Add item icons to infoboxes where the item has a different texture than the block

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

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

 Support FVbico (talk) 00:30, 10 November 2019 (UTC)
 Support as the full-sized images are quite useful for people quickly wanting to download texture files.  Nixinova T  C  06:20, 10 November 2019 (UTC)
 Oppose - the only reason that items display large versions of their texture files in the infobox is because that's the image that describes the item the best and there's no better image. Having a massive item texture there alongside the existing 3D render would just clutter the page and add nothing of value. - User-12316399 (talk) 13:56, 10 November 2019 (UTC)
"Would just clutter the page and add nothing of value" – This has never seemed to stop you before.  Nixinova T  C  04:48, 12 December 2019 (UTC)
 Support for both blocks and entities. --Capopanzone (talk | contribs) 10:21, 11 November 2019 (UTC)
 Support – don't see why not, especially for String which has many uses unrelated to its block form. –Sonicwave talk 00:56, 18 August 2020 (UTC)

Articles on Mojang staff and related persons - do we really need them?

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

I feel like, at best, we should try to expand the articles as much as possible, much like how Wikipedia does it with their policy on biographies of living persons, making sure that information about them is backed up be reliable sources. I do recall mentioning back in 2015 that we could possibly use LinkedIn profiles as a source for reliable information, though discussion never went anywhere beyond that. -BDJP (t|c) 21:30, 23 November 2019 (UTC)
We mention devs pretty often in history sections, and it might be useful to have these pages in those cases. Especially when they commonly go by nicknames (i.e. Jeb or Dinnerbone). Other than that, I don't know. I would like to see the general staff page updated though. -PancakeIdentity (talk) 04:41, 27 November 2019 (UTC)
Other than the obvious ones I think there should just be an "employees" page that lists mainly job-related info; this also avoids the BLP issues we've had in the past.  Nixinova T  C  06:03, 27 November 2019 (UTC)
I would support having a Mojang employees page, consolidating the short pages there, and having a link from there (after a brief overview) to longer pages like for Jeb. Memetics talk | edits 22:42, 10 April 2020 (UTC)

Remove separate employee pages

This wiki tries to create a page for every single Mojang employee, yet the vast majority are either redlinks or one-line stubs. This is hardly useful, and really the only information you need is name, date of employment, and job title, which can easily be done in just a table. It would be so much easier to maintain employee pages of they were all just in a table instead of spread out across hundreds of pages. Additionally, this leads to the wiki coming across BLP issues (eg: ez) and not having proper policy on how pages on people should be handled (we're not Wikipedia). These issues can be easily solved by migrating all employee information into e.g. Employees(yes, plural). Excepting, of course, very notable employees like Notch.  Nixinova T  C   05:50, 24 July 2020 (UTC)

I would support removing pages for employees that have hardly any information. There is currently a table at Mojang Studios#Employees, which could be split into a separate page and get additional columns for join date and other notable Minecraft-related info/trivia. (Also see the previous discussion on this topic.) –Sonicwave talk 17:40, 24 July 2020 (UTC)
 Strong support I agree, like whats the point of making these tiny stub pages that almost no one goes to? Completely Agree The BumblebeeBee 18:55, 24 July 2020 (UTC)
Moved to previous section that I didn't see when creating this section Nixinova 01:08, 25 July 2020 (UTC)
 Support. Just a note, I'd say Lena Raine and C418 should still have their own pages both as they are extremely well known (especially C418) in-community, and neither are Mojang employees. In general, though, we'd need to have a general guideline for who gets their own page. Things like a well-known nickname, notability in and out of community, and role in the company (ex: Jonas Martensson and Helen Chiang aren't too well known in the community, but hold important positions at Mojang, which may justify them have unique pages?). -PancakeIdentity (talk) 08:43, 27 July 2020 (UTC)

Make templates for common NBT practices.

NBT have several basic tags, and there are many common practices in Minecraft: Java Edition based on those tags. Mojang does use some functions to parse these practices accordingly, I showed three of them here using yarn's mappings:

  • Boolean-like TAG_Bytes: Parsed by net/minecraft/nbt/CompoundTag#readBoolean. They are technically TAG_Bytes. They use 0 to represent false, and all the other possible values to represent true. e.g. NoGravity tag for entities. I've made a possible template User:SPGoding/Sandbox/Nbt practice/boolean for them:
    {{:User:SPGoding/Sandbox/Nbt practice/boolean|NoGravity|if true, the entity does not fall if in the air.}}
      •  NoGravity: 1 or 0 (true/false) - if true, the entity does not fall if in the air.
  • UUID: An TAG_Int_Array with four TAG_Ints which represents the bits of an UUID. I've made a possible template User:SPGoding/Sandbox/Nbt practice/uuid_longs for them:
    {{:User:SPGoding/Sandbox/Nbt practice/uuid_longs|UUID|This entity's|indent=*:**}}
  • Block state TAG_Compounds: Parsed by net/minecraft/nbt/NbtHelper#toBlockState. A TAG_Compound with a TAG_String named Name and a TAG_Compound named Properties with all the block properties stored. e.g. carriedBlockState tag for enderman entities.

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

How they function may be similar, but this would result in complicating the NBT providing even more (it's already complicated for people unfamiliar with the wiki to provide or correct NBT info). Additionally, UUID tags are extremely invonsistent in java, it's one {l:,m:}, another time Least:,Most: and another time UUID:""; you cannot template that.
In short, it'd complicate the most complicated part of the wiki even more, needlessly. FVbico (talk) 20:17, 21 December 2019 (UTC)
Thanks for your quick reply. However, I don't think this template would complicate things too much, to the contrary, it would make changing similar stuff easier. For instance, the function Mojang used to get a BlockState has been called for 5 times. Let's see how many times they have been changed on this Wiki:
There are still two pages (Sand/BE and Enderman/ED) with the similar situation, but I believe there's no need to put them here anymore. I'm sure everyone can find where the problem is: people have to update the 5 pages individually if they want to improve the content of the BlockState structure. I believe this is much more complex than simply updating one universal template, and I believe you are more aware of this than anybody else because all these awesome changes are just made by you. Moreover, the function used to read boolean-like TAG_Bytes has been called 84 times, which means if anyone want to update the current description of it, they have to change tons of pages separately. However, if we had a template for those common cases, this would no longer be a problem.
Here is all my opinion, I really appreciate for your patience. Merry Christmas! --SPGoding (Talk) 23:10, 21 December 2019 (UTC)
 Support. I think it's the right idea, and if you can solve FVBico's objection to UUIDs where "you can't template that", then I feel it's got no major problems. Yes, doing the nbt templates is complicated, but I don't see this adding significantly to that, relative to the benefit. – Sealbudsman talk | contribs 15:47, 4 January 2020 (UTC)
Just wanted to say, the UUID issue is fixed in the 1.16 snapshots. -PancakeIdentity (talk) 06:04, 17 March 2020 (UTC)
I've updated the demo template. Thanks for telling me! SPGoding (Talk) 01:51, 21 March 2020 (UTC)

Changes to the upcoming template (and similar)

From here on out, Bedrock and Java will match version numbers. I was thinking that to avoid spam and compress those ugly upcoming tags, we could just allow, for example, {{upcoming||1.16}} to be used. Individual versions could still be used for version exclusive features, of course. This would help compress those editor notes which can make pages look ugly and harder to read (See Log for example). I think this, along with the proposal above about modifying the {{in}} template, would help us greatly improve the readability of articles. -PancakeIdentity (talk) 04:50, 17 March 2020 (UTC)

 Support We could have "1.16" redirect to Nether Update, to include both editions. The BlobsPaper 15:16, 17 March 2020 (UTC)
 Support. --dr03ramos Piston (talk) Admin wiki[pt] 21:03, 18 March 2020 (UTC)
A couple notes from a discussion on discord: {{INUpcoming}} and {{inUpcoming}} could say "In the Nether Update (1.16), ...". In the normal {{upcoming}} template, we could also say "Nether Update" as opposed to "1.16". Just a couple more ideas. Personally, I'm neutral on these specific suggestions. -PancakeIdentity (talk) 02:19, 19 March 2020 (UTC)
 Support unless Mojang doesn't keep up this consistency. I'd be happy to update/create/fix templates like {{in}} etc if needed.  Nixinova T  C 
I tried implementing something like this, but I couldn't get it to work. I could get Nether Update, but not the other way around. If someone who has more template knowledge than me wants to give it a try, you can edit User:PancakeIdentity/UpcomingMockup. -PancakeIdentity (talk) 23:05, 10 April 2020 (UTC)
Yeah, I think it's too long to type "upcoming JE 1.16 & BE 1.16.1" a million times. I'll try to see if it works, your suggestion. 13:48, 25 April 2020--106.201.186.23 08:18, 25 April 2020 (UTC)
These templates are functional in my userspace. User:PancakeIdentity/UpcomingMockup, User:PancakeIdentity/UntilMockup, User:PancakeIdentity/InUpcomingMockup, User:PancakeIdentity/InUntilMockup. They could be implemented, but they no longer accept a 2nd version argument so cleanup will need to be done. -PancakeIdentity (talk) 01:18, 22 April 2020 (UTC)

Should sprite files be interlaced?

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

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

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

I would support interlacing. Otherwise we would need to update the sprite positions, and the incorrect sprites may appear for the next day due to server cache. The BlobsPaper 15:15, 25 March 2020 (UTC)
Do we even still need sprite sheets? --AttemptToCallNil (report bug, view backtrace) 17:15, 25 March 2020 (UTC)
I doubt it, unless InvSprite pulls directly from that big image. -PancakeIdentity (talk) 21:14, 25 March 2020 (UTC)
@PancakeIdentity: The sprites are directly pulled from the large images; deleting these images would break the templates. The BlobsPaper 02:18, 26 March 2020 (UTC)
I meant, why not go back to the old system of individual files per image? The performance issues seem to no longer be substantial (there are issues if you're using, like, _hundreds_ of different images per page). As for the sprites in navboxes, they're not really needed; the large navboxes themselves could be candidates for deletion as they aren't very effective for navigation (a task better accomplished by a well-designed category system).
I should also note that there's the possibility that with the transition to UCP, functionality critical to the sprite system may become unsupported without any replacement (except to use individual files). --AttemptToCallNil (report bug, view backtrace) 09:42, 26 March 2020 (UTC)
iirc, sprites are introduced to optimize numbers of HTTP request, thus reducing protocol overhead. And on the SEO side, search engines seem to favor well-written sites. I know HTTP protocol has been overhauled in recent years but I'm not a web developer, so I don't know if these theories are still true today. For templates, it's true templates aren't intended for navigation on MediaWiki, but the readers would prefer easy-to-read template rather than plain category page imo.  CuervoTalk 16:39, 27 March 2020 (UTC)
I'd  Support this, although the Sprite editor would have to be changed to support this feature. Also, is there a variation of progressive JPEGs for PNGs? These first load a really low quality version of the image before scaling up the resolution once more of the image loads (for 16x16 images it wouldn't appear much different at all).  Nixinova T  C  01:42, 31 March 2020 (UTC)

Cleaning up the meaning of "1.16"

Should we change pages such as the 1.16 disambig page to be a bit more useful?

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

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

This change would also obviously any future (1.17+) versions, though I don't think it'd be necessary to apply it to older versions, as many of these issues don't apply there. -PancakeIdentity (talk) 02:22, 1 April 2020 (UTC)

I don't see the issue here. I fixed the wording of the version nav to be less confusing, and the disambiguation page is just leading to different 1.16s.  Nixinova T  C  02:36, 1 April 2020 (UTC)
My main concern was with the possible new {{upcoming|1.16}}, linking to a disambig page where 1/2 the pages linked aren't about the intended version might not be a good idea. We could do something like "1.16 redirects here. For other versions numbered 1.16, see [links to the PS 1.16s]." -PancakeIdentity (talk) 05:56, 1 April 2020 (UTC)
 Support this. Redirect 1.16 to Nether Update, and put a hatnote on the top of the page to something like 1.16 (disambiguation). Thomanski (talk) 14:16, 1 April 2020 (UTC)
Yeah, this is what I was thinking. -PancakeIdentity (talk) 23:06, 10 April 2020 (UTC)
I think it's too soon to do stuff like this. For all we know Bedrock could once again start releasing nothing updates again. "1.16" as a disambiguation works fine and in my opinion is the least confusing way; when you search "1.16" you get a disambig instead of a short page that makes it look like (on first glance) that a comprehensive changelog page doesn't exist, which may be off putting for readers. Putting the year in front of the disambig items also alleviates confusion as to whether PS 1.16s had the nethere update, etc, or not.  Nixinova T  C  01:15, 20 April 2020 (UTC)
Except they've literally said they intend to keep Java and Bedrock version numbers in line from here on out. Everything else, I understand. But I don't think it makes sense to assume things will change for no reason when they've said otherwise. But yeah, I don't really think it's needed anymore. ATCN managed to solve the upcoming template issue which was my main concern. -PancakeIdentity (talk) 05:42, 20 April 2020 (UTC)
I know what was said, but Mojang have said a lot of things like that which don't end up happening. Especially when the quote is "That is the plan…" instead of something like "Yes, that is what we'll be doing from now on". Anyway, whatever.  Nixinova T  C  05:48, 20 April 2020 (UTC)
My preference is for 1.16 to redirect to Java Edition 1.16 and for 1.16.0 to redirect to Bedrock Edition 1.16.0. The change away from this was a backwards step. With the update versions now consistent, I would support a redirect to Nether Update as a second choice. It might not stay that way but both the most recent update and their intention is for consistency so may as well take advantage of it. Never commented before so lmk if I did something wrong. Miss lauralot (talk) 04:20, 6 July 2020 (UTC)
While that is technically correct, I usually refer to both as simply 1.16. Redirecting 1.16 and 1.16.0 to different articles would cause confusion. So we should redirect them to a page that does not prioritize either edition, and that is the Nether Update page. The BlobsPaper 16:59, 6 July 2020 (UTC)
I'd support redirecting 1.16.0 to Bedrock's page. I think 1.16 is general enough that it shouldn't redirect to Java's page. -PancakeIdentity (talk) 19:57, 6 July 2020 (UTC)

Proposal: replace pseudo-headings based on definition lists

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

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

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

Is there an easy way to make headings under a certain level not appear in the table of contents? One problem I can immediately think of if we replaced these pseudo-headings with real smaller headings is pages like Java Edition 1.9 would have an extremely cluttered TOC (although we could simply convert the headings in cases like that to bold I guess).--Madminecrafter12 (Talk to me | View what I've done) 17:32, 14 April 2020 (UTC)
We have {{TOC limit}}. --AttemptToCallNil (report bug, view backtrace) 18:13, 14 April 2020 (UTC)
 Neutral or  Weak support. I see the benefits, and I guess I don't see any issues with the actual idea. I honestly always just thought that was the correct way to do it. I don't feel strongly about this at all though. -PancakeIdentity (talk) 22:34, 14 April 2020 (UTC)
 Oppose on practicality. While Wikipedia needs to be 100% accessible by blind people I wouldn't think MCW needs to be; if you're blind you're not going to be playing video games like this and as such won't be reading the wiki. I don't think it's worth the effort for the 6 people who would read the wiki that need it. Unless I'm missing something in the reasoning.  Nixinova T  C  21:20, 21 April 2020 (UTC)
If this is really an issue I'd much prefer using JavaScript to replace definition lists with regular bold text over restricting the whole wiki and having to reteach everyone what to do.  Nixinova T  C  21:24, 21 April 2020 (UTC)
Yeah this is a good point. It's possible we have a limited view of this, but I'm not sure how helpful optimizing this wiki for screen readers would be. If someone more qualified to speak on this thinks different, I'd love to hear it, but as it stands, I don't think re-teaching the wiki this somewhat minor detail is needed. -PancakeIdentity (talk) 04:47, 20 May 2020 (UTC)

Reworking the {{LootChestItem}} template

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

I'm pretty sure the French wiki already does something like this. This would also have tied in to the whole loot rework I've been trying to do, so I'm definitely in support of this (the exact same lines of text being repeated over and over is annoying as hell, and tables just look a hundred times better anyway with said information). I don't think we should account for luck though, since it isn't a survival feature as far as chest loot is concerned. - User-12316399 (talk) 23:13, 15 April 2020 (UTC)
It's not even a non-survival feature outside of fishing. -PancakeIdentity (talk) 23:17, 15 April 2020 (UTC)
User:Sealbudsman seems to have a work-in-progress on his userpage (which uses Template:LootChestItem2 and Module:LootChest2); perhaps we could expand off of that? –Sonicwave talk 03:48, 16 April 2020 (UTC)
Those look like they have potential. -PancakeIdentity (talk) 19:12, 16 April 2020 (UTC)
I changed the template to use the base3 (table) version of the module a day or two ago, which is much better, while Sealbudsman's template is still in development.  Nixinova T  C  01:11, 20 April 2020 (UTC)
 Important The template still has issues. Whenever a loot table is the same across editions, this template only lists them under Java edition. This makes it look like they can only be obtained from woodland mansions and (in 1.16.0) ruined portals. However, I know for a fact that they can also be obtained from desert temples. It is even more confusing because the chance of getting an enchanted apple from a mansion chest is the same across editions only other parts of the loot table are different. The BlobsPaper 17:27, 20 April 2020 (UTC)
The old text-based template had this exact same issue. It's something that needs to be fixed, yes; but it's not a reason to not use the table template. -PancakeIdentity (talk) 17:35, 20 April 2020 (UTC)
Personally I wouldn't mind having duplicate information if it's the same in both editions, you'd have a section with every chest loot info for java and a section with every chest loot info for bedrock.--Capopanzone (talk | contribs) 19:39, 21 April 2020 (UTC)
 Agree Most readers will just look at the list for their preferred edition, so listing the same chance on both would be simpler. The BlobsPaper 20:28, 21 April 2020 (UTC)
My only worry with this is the possibility of big tables with lots of repeat info, especially if Bedrock loot tables are made to generally match Java's. What I think would be a good solution would be a general section without a version bar for info that's the same in both. And then, both a Java and Bedrock section that displays entries that are different from each other. -PancakeIdentity (talk) 22:28, 21 April 2020 (UTC)
I made some adjustments to Module:LootChest. Now, the loot table is given to both editions, even when identical. When using {{LootChestItem}}, the table explicitly lists loot for both editions. I would like to have a way to more simply state that the loot table is the same across editions, but the module uses several functions that I am not familiar with.
I am not sure if there is an easy way to implement this, but we could document when the loot tables only have minor differences. For example, ruined portals can have glistering melons in stacks of 4-12 in Java Edition, while they come in stacks on 1 in Bedrock Edition. Even worse, the chest loot is almost identical for woodland mansions, but the weights are scaled up by a factor of 5 in Bedrock Edition. The BlobsPaper 18:35, 9 May 2020 (UTC)

List of all additions on Java Edition pages (1.12 - 1.16)

On Java Edition version pages 1.12, 1.13, 1.14, 1.15 and 1.16, probably same user (85.247.222.38 & Groovy goose) added on these pages inventory with all "blocks, items and spawn eggs" added in that version. I'm really disappointed about these edits, as those inventory tables look really confusing and we already have guides for Java versions and for Bedrock, we will have soon. So I suggest to remove them from these pages. --Treeislife2 (talk) 09:12, 16 April 2020 (UTC)

 Strong Oppose for these additions. We already have guides + it is only for inventory items with the inventory textures. --Treeislife2 (talk) 09:12, 16 April 2020 (UTC)
But  Weak Support  Neutral, if it will be on guides pages. --Treeislife2 (talk) 09:42, 22 April 2020 (UTC)
 Neutral. I don't really see any problem with them. — Thomanski | t | c | 18:09, 16 April 2020 (UTC)
 Neutral/ Weak support. I don't see a need for them, but I always am not totally opposed to including them. -PancakeIdentity (talk) 19:11, 16 April 2020 (UTC)
 Weak support for major updates only. I honestly think it provides a nice overview of all the items added in the update (not all readers know that you can easily find a direct list of the features added on the corresponding named update page) and isn't too much clutter imo. The only reservation I have is looking at the former Java Edition 1.9 on my phone with desktop view, the left side of the inventory of items is completely cut off, and since it's not in the form of an image you can't just click on it and see it in a bigger view. If we could add a parameter to Template:Inventory to make fewer cells per row that might fix it, but then again all different devices are different and this is likely an issue we can't fix for everybody.--Madminecrafter12 (Talk to me | View what I've done) 19:32, 16 April 2020 (UTC)
You say inventory grid gets cut off, you can't see all 9. How many can you see? – Sealbudsman talk | contribs 20:11, 16 April 2020 (UTC)
I see 7 clearly while the furthest to the left is completely cut off and the remaining slot directly to the right can only be partially seen. Scrolling and zooming do not help. Again, though, this likely varies different between mobile devices.--Madminecrafter12 (Talk to me | View what I've done) 20:35, 16 April 2020 (UTC)
Yeah, that's a problem. – Sealbudsman talk | contribs 21:43, 16 April 2020 (UTC)
 Support having it, but not heavily so, even though I did like it. I'd be interested in why they were confusing. As for the observation that we already having guides .. well, these lists aren't guides, they're quite unlike a guide except having similar subject matter. And having the same information in two different forms in two places on the wiki, it's somewhat common I think. – Sealbudsman talk | contribs 20:11, 16 April 2020 (UTC)
 Support Looks quite good, and provides a neat little overview over everything that's been added. It can also be used as a shortcut to the respective article if you're interested in reading more about a certain item or block. | violine1101(Talk) 16:35, 19 April 2020 (UTC)
 Support on major releases, as it's a useful overview. It definitely shouldn't be on pages that have only one or a few new additions (like in Indev) that are obvious by a quick glance at the additions section. Nixinova T C 01:12, 20 April 2020 (UTC)
 Strong Oppose for using a inventory image or Template:Inventory to list blocks. The item form of a block is not equal to the block itself. Many blocks don't have a item form, and also many blocks do not exactly correspond to the form of the item. Such as bubble columns in 1.13, in [1], there is a bubble columns in inventory. This is totally wrong, bubble columns have no item form in java edition, and the sprite of it in Template:Inventory is only for bedrock edition. Another thing, using new textures on pages of old game versions is also very inappropriate.
But I  Weak support for adding a neat little overview. However, use game screenshots or block renders to list blocks.--Chixvv (talk) 08:28, 20 April 2020 (UTC)
 Strong Oppose for these additions. (Sorry for the bad english) We already use a picture alongside the link, and a brief description of the block/item/mob, and I personally think that this is more intuitive:
Furnace JE1 Furnaces
  • Used to smelt blocks and items.
  • Replaces the old smelting system.

Thanks, RosilloGames (talk) 19:06, 21 April 2020 (UTC)

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

Solutions

Because discussion stopped for 1 month, I've recently decided to put it again to discuss. As mentioned above, we have several opinions, what to do with addition images

  1. List of additions in inventory form, above sections - original solution
  2. Adding images before the name of addition (blocks, items, even the terrain can be) - Style was used on Beta articles and earlier. - RosilloGames solution
  3. Don't do anything - and another solution

It will be good to make some solution, or we/I will need to close this discussion to avoid these-type edits. I will keep discussion/voting for 2 weeks. --Treeislife2 (talk) 19:42, 25 May 2020 (UTC)

So, by now, I  Support solution 2 (Adding images before the name of addition ) --Treeislife2 (talk) 19:42, 25 May 2020 (UTC)
I'd personally  Support solution 3, though I don't really have any issues with 1 or 2. I just don't think they're necessary as we have the named version release pages and guides for quick overviews. See also the version page detail discussion. -PancakeIdentity (talk) 04:06, 27 May 2020 (UTC)

Handling of Legacy Sprites

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

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

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

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

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

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

The spritesheets are too large so I  Support splitting off the legacy sprites.  Nixinova T  C  01:17, 9 May 2020 (UTC)
 Support for splitting off the legacy sprites. --Treeislife2 (talk) 19:42, 9 May 2020 (UTC)
 Oppose I see no reason to keep the sprites in any form (split or not); we already have revision renders, and aside from invsprite in version pages and history sections, I see no use for them. FVbico (talk) 19:51, 9 May 2020 (UTC)
So we're ignoring pages like Java Edition 1.13/Flattening then, which use modern sprites despite the fact that they have no business using block sprites from a year ahead of what they document? - User-12316399 (talk) 20:22, 9 May 2020 (UTC)
I'm not ignoring them, those can be changed to the renders instead of the sprites. FVbico (talk) 20:24, 9 May 2020 (UTC)
I mean there are examples of things like historical crafting recipes and such, I'm not sure if they can use renders. If they can, then yeah, I don't see much a need either. If they can't, is it worth all the effort to fix it? -PancakeIdentity (talk) 21:33, 9 May 2020 (UTC)
While they could be replaced with renders on pages like the mentioned flattening page, the 16x16 block sprites are almost exactly the same size as the text itself, and replacing these with renders would either require scaling them down to being indecipherably small or having them be bigger in a way that unnecessarily stretches the template out. Since blocksprite has them at just the right size to be able to convey the necessary information, I'm still sticking with keeping the legacy sprites in a dedicated template. - User-12316399 (talk) 21:40, 9 May 2020 (UTC)
This would just be very inconsistent in my opinion. And I think User-12316399 also got a very strong argument here. Sagessylu (talk) 14:03, 16 May 2020 (UTC)
If we were to keep them, would you rather they be split or kept together? -PancakeIdentity (talk) 17:55, 16 May 2020 (UTC)
 Support I don't see any reasons for which we shouldn't split. It would indeed make the sprite sheets smaller and easier to maintain. Sagessylu (talk) 14:03, 16 May 2020 (UTC)

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

As there hasn't been any opposition in the given time frame I'm proceeding with the split of templates. Again, since both parties agree with having legacy sprites removed from the main template this shouldn't be controversial, and the dedicated legacy templates can just be deleted if that side wins. - User-12316399 (talk) 12:35, 13 May 2020 (UTC)
This was open for only 4 days, and 1 oppose and 1 support; you're in no position to say to go through immediately until there is more support. FVbico (talk) 14:00, 13 May 2020 (UTC)
In case I can still give my opinion, I'd say I  Support splitting sprites into their legacy versions, especially the {{InvSprite}}. I think removing them completely is a little extreme. I can also run the bot User:Dr03bot if needed. --dr03ramos Piston (talk) Admin wiki[pt] 01:03, 24 May 2020 (UTC)
I won't be touching invsprite so someone else will have to do that one if it needs changed. - User-12316399 (talk) 04:35, 27 May 2020 (UTC)
 Support, now it seems that {{BlockLink}}'s doc can not be loaded by {{documentation}} at all, I think we need split it no matter whether legacy sprites should be removed.--Chixvv (talk) 00:35, 7 June 2020 (UTC)
I tweaked Module:Documentation a bit, it should work better now. I think this shouldn't affect split discussions though. --AttemptToCallNil (report bug, view backtrace) 01:45, 7 June 2020 (UTC)
 Support splitting legacy sprites to a separate sprite sheet. It's more visually consistent with current sprites than revision renders, at least for blocks and entities. –Sonicwave talk 00:38, 18 August 2020 (UTC)

Seems like consensus is to remove old sprites so I'll be doing that soon enough. - User-12316399 (talk) 11:56, 28 September 2020 (UTC)

Terrible tutorial pages

Let's face it, the tutorial pages are incredibly bad 90% of the time. So herby a request to rewrite the pages from scratch or discussion to delete them.

An example: the commands page lists commands not valid in any version, advocates terrible setups ("to clear a reeled in fishing rod" can be done so much easier...) and more. FVbico (talk) 15:20, 13 May 2020 (UTC)

 Support-ish?. I agree the tutorial pages really need clean up. They ignored by our more active editors most of the time so they kinda get out of hand. I just feel hesitant about strongly supporting this fully for some reason. No real objections from me though I don't think. As for the commands tutorial, imo most commands pages should (aim to) explain commands well enough that tutorials aren't needed. (Edit: The below comments have mostly explained my thoughts better than I did) -PancakeIdentity (talk 17:02 13, May 2020 (UTC).
 Comment Since the tutorials pages are subpages of Tutorials, they can't be accessed by Special:Random the "Random page" link. Fadyblok240 (talk) 16:48, 26 August 2020 (UTC)
 Support Rewriting the tutorials pages, but  Oppose deleting them except perhaps on a case by case basis. I would lean away from deleting even pages like the commands page which borderlines on "miscellaneous builds." They have a lot of content and can be useful in seeing how to apply redstone/command knowledge. For example, Tutorials/Traps has a lot of inspiring ideas for someone wanting to build a trap, especially for someone new to Minecraft. It might be beneficial to remove messy tutorials from the ginormous {{Tutorials}}, however. That really needs cleaning up. jahunsbe (talk) 00:55, 15 May 2020 (UTC)
 Support, but only if done on a case-by-case basis. I totally agree that lots of tutorials pages suck, but not to the extent that they should be deleted or completely rewritten in all cases. I agree deletion/complete rewriting for pages that are really terrible (for ex : Tutorials/Desert shelter, Tutorials/Airlock, Tutorials/Pig parking lot, etc.) Sagessylu (talk) 13:56, 16 May 2020 (UTC)
Could Goldenghost1000 please explain why he cancelled the small edit I made to my own comment, if I may ask ? Sagessylu (talk) 14:00, 18 May 2020 (UTC)
I'm sorry, undo my undo. I thought it was a useless vandal edit, sorry. If you like to discuss further than go to my user page. Thanks User:Goldenghost1000 (talk) 14:27, 18 May 2020 (UTC)
OK, I understand. But please, be more careful the next time :) Sagessylu (talk) 16:25, 18 May 2020 (UTC)
 Strong Support and I think we should move Beginners Guide Rewrite to Guides Rewrite and add here all guides and their progress (of a rewrite). --Treeislife2 (talk) 17:20, 21 May 2020 (UTC)

But there is already a project called Tutorial Modernization--Treeislife2 (talk) 06:37, 15 June 2020 (UTC)

Yes, but, to my knowledge, the purpose of this project is to update the content of the tutorial pages to the latest version, and not to rewrite them or clean them up. Sagessylu (discuss | edits)
 Very Strong Oppose No, they're all good. I went to Tutorials/PvP and read it one day. I started reading it when I was bored instead of actually playing Minecraft. That shows you how good the tutorials are. 182.65.102.56 08:35, 27 July 2020 (UTC)
Well, if that specific tutorial is helpful and up to date, you need not worry. This was not a proposal to get rid of all tutorials, but to update and modernize them instead. This process may involve removing some useless tutorials, but there's no need to worry about important tutorials, such as for PVP. -PancakeIdentity (talk) 08:46, 27 July 2020 (UTC)

Reworking mob categories

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

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

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

 Support the "Friendly" and "Hostile" categories as they are simpler and as they arguably match the code more closely. I don't approve the "Animal" category you suggested as it causes problems, as you said, with villagers, but also with Polar Bears and Hoglins (both animals and hostile). By the way, we should also think of a new definition for the new "Hostile mob" category. It isn't that simple : why are zombie pigmen hostile mobs and not wolfs or dolphins ? I have a (pretty quirky) definition for it, but I'll post it only if you're interested. Sagessylu (talk) 12:21, 21 May 2020 (UTC)
Support following the sound category names. FVbico (talk) 12:24, 21 May 2020 (UTC)
Support disbanding the "neutral" category. I compared mobs that implement "Enemy" in the code, are included in the Monster Hunter advancements, or specify a hostile sound category; they are mostly the same except that the advancement doesn't include giants or Illusioners (as might be expected), and hostile sound category includes killer rabbits but not slimes or magma cubes. "Monster" would be clearer than "hostile" since mobs like bees and polar bears are not included in any of these, despite having hostile behavior. –Sonicwave talk 18:42, 22 May 2020 (UTC)
Yeah, "Friendly" and "Monster" seem the best way to go imo. I also think that, in case of discrepancies, we should prioritize what makes most sense (slimes would be "monsters", etc.) -PancakeIdentity (talk) 20:54, 22 May 2020 (UTC)
 Support using categories like "Friendly" and "Monster,"  However I think terms like passive, neutral, and hostile could still be useful as a short description of a mob's behavior in info boxes. The behavior should be more thoroughly explained in the behavior section. For example, as noted on wolf, wild wolves are neutral and tamed wolves are passive. To give a general idea of panda, it could possibly say Neutral (Aggressive Pandas), Mostly Passive (Other Pandas). Without the terms being tied to categories, it is alright for them to be somewhat ambiguous so long as they are properly explained in the behavior section. jahunsbe (talk) 02:14, 24 May 2020 (UTC)
Yeah, I'd support keeping the ideas of this terminology around, even if it's not how we group mobs. I would still say we should figure out a better name for "neutral" though. -PancakeIdentity (talk) 02:23, 25 May 2020 (UTC)
Maybe we could say "Defensive" instead of "Neutral"? Makes more sense in my opinion, what do you think? Sagessylu (talk) 14:35, 26 May 2020 (UTC)
They aren't defensive though, they attack under conditions, not just when attacked. Endermen when looked at, Spiders in darkness, Piglins if you don't wear gold, etc. FVbico (talk) 14:43, 26 May 2020 (UTC)
I mean, neutral mobs are mainly quite defensive, and Endermen feel provoked when you look at them, so in this sense we can say they are defensive, Spiders could be "Hostile/Defensive" and Piglins "Mostly Hostile"? I feel like it's quite hard to keep mobs in static categories anyway. Sagessylu (talk) 09:58, 29 May 2020 (UTC)
I'd support defensive for things that only attack out of defense. Other than that, I'm not sure we need a set term for it? Hostile describes most of the mobs fairly well, we can describe that they are not always aggrsive in their description areas. -PancakeIdentity (talk) 04:13, 27 May 2020 (UTC)
I think we could also use the term "Aggressive" to describe mobs which become hostile and repeatedly attack (or attempt to kill) when provoked. There would need to be an exception to the term Defensive for mobs which are not "Aggressive" but can be provoked even if the player doesn't attack (Pufferfish).
  • Hostile - Seeks out and attempts to kill the player. Example: Creeper
  • Passive - Never attacks the player. Example: Sheep
  • Aggressive - Becomes hostile when provoked. Example: Spider (light > 11)
  • Defensive - Provoked only by getting attacked. Example: Llama
    • OR Not Aggressive yet otherwise provoke-able. Example: Pufferfish
Using this terminology, llamas and pufferfish would be Defensive, spiders Aggressively Defensive, and endermen Aggressive. The term "Group" could also be used to describe mobs which are provoked when group members are. For example, Zombie Pigmen would be Aggressively Group Defensive. All of this terminology might make things too confusing though, so I don't know. It would definitely need to be explained in the behavior section. jahunsbe (talk) 15:09, 30 May 2020 (UTC)
Like I said above, I'm not sure we really set terms for all these behaviors. I feel it'd get too confusing too quickly. -PancakeIdentity (talk) 18:56, 30 May 2020 (UTC)
 Oppose any change. They're officially known as "neutral" by Mojang, and Hostile and Passive work fine with clarification.  Nixinova T  C   06:53, 5 June 2020 (UTC)
So, would dolphins, iron golems, llamas, and pandas be passive and spiders, cave spiders, and piglins be hostile? -PancakeIdentity (talk) 18:03, 5 June 2020 (UTC)
Passive and Hostile should have an implied "always" before them, and Neutral should be the "everything else" term. So, e.g. iron golems would have an overall classification of "Neutral" but with a specific clarification of "Passive when player-made and Neutral when natural". Spiders likewise. Piglins are neutral as "not wearing gold" ≈ "provoking" and llamas are neutral as they are defensive.  Nixinova T  C   00:40, 30 July 2020 (UTC)
 Support, but keeping it to a single term.
I acknowledge that Henrik's attention to the anger management code is noteworthy, and indicates that Mojang considers the Neutral mobs in a single category, but I do think the wiki can push against old (bad) terminology and just use a new word, and people will start using it. I believe we on the wiki were early adopters / pushers / popularizers of the term "bedrock edition", and I think we were right to create a term then ... and now.
What that term would be ... I don't know if Aggressive and Defensive capture it ... Provokable? Volatile? Excitable? – Sealbudsman talk | contribs 16:14, 22 June 2020 (UTC)
Provokable describes the actual behavior about as cleanly as you can in a simple, single word descriptor. I like that. Also, like I said below, I don't think recognizing this "neutral" classification is irreconcilable with using the in-game groups of Friendly and Monster (even if we don't actually use the word neutral). -PancakeIdentity (talk) 23:05, 15 July 2020 (UTC)
Having thought about it a bit, I think it's possible to rework things into friendly/monster and have a "neutral" category in the mob categories section. This allows us to document mob groups as the game sees them while still recognizing the "neutral" status used by Mojangsters and (sort of) the game code. -PancakeIdentity (talk) 22:59, 15 July 2020 (UTC)
In my opinion an "Animal", "(Non-Player) Character" and "Monster" could work. Although I'm hesitant about calling anything "Monster" specifically. In my opinion something is a monster if no one feels affectionate about them, as in, disassociative to their individuality. However in that sense I find the word insensitive and insulting. I would personally categorize this stuff to behaviour, such as "attacks player near babies", "attacks player once provoked/looked at", "never attacks player", etc. Because it would be more concise and always be accurate. More complicated however, because that way a mob can belong to multiple categories. So I do think grouping by type of creature like this is better, specially better than by their current type of hostility. Because most important of all, against what is currently done, hostility is not consistent between mobs. We need to improve this. A mob's hostility can change over the course of certain player actions, and sometimes depends on situation and other factors. It's not anything a mob is always permanently considered to "have" or "be".
Using terms such as "friendly" and "monster" (specially without further context when there is further distinction needed), although might be more true to what the game defines them as, it isn't necessarily true and accurate for every player. It isn't concise. It doesn't always meet the expectations of what someone might think it means and it is important in my opinion, that we honour that. Saying it like "polar bears are friendlies", can have the effect of upsetting someone when they're killed just because there was a baby around and they didn't know they would defend them. It does happen to newer players, and this sort of "ignorance" to behaviour violates what the wiki is intended to do; documenting the game "as it is". If people can get confused so significantly by the way things are classified, the wiki's not serving that purpose. I'm not necessarily voting for any suggestion, I just wanted to put my opinion out there, because I'm not active in discussions anymore for my own reasons (may come back later) and I specifically had thoughts I found relevant. – Jack McKalling [ Book and Quill Diamond Pickaxe ] 23:40, 15 July 2020 (UTC)
This seems like a far too philosophical argument for this topic tbh -PancakeIdentity (talk) 23:06, 29 July 2020 (UTC)
I honestly don't think we should categorize mob behaviors with just one or two words. Especially since basically every new mob that gets added, get more and more complicated behaviors than the previous one, I don't think they can simply be summarized as just 'Monster', for instance. — Thomanski | t | c | 09:06, 17 July 2020 (UTC)
Some rambling and unrelated thoughts:
I'm in favor of the friendly/monster classification, but I also see the point of passive/neutral/hostile classification. The latter is based on the mobs' in-game behaviour, which could be, but isn't, clearly defined. However, the solution should above all else follow the technicalities of the game, and pillagers should be neutral.
Hostility also needs to be defined, as well as attacking. Now, I don't give too much value to intuition where logic can be used, but I think we can unanimously agree that ghasts are hostile. So let's assume a hypothetical mob that is identical to ghast, except that its distance of perception is slightly more than its attack distance. Would it, due to that minor difference, not be hostile? It does not change its movement because of the player, and thus would not chase the player, nor could it attack. In fact, its behaviour would be identical to ghast, except that it would look at the player from a bit further away. With no relevant difference in behaviour, this mob and ghast should be classified the same way, which means the definition should be such that it classifies this hypothetical mob as hostile. The solution would be that hostility towards the player means attacking the player, provided it is possible.
Now, for pufferfish, it is passive, neutral, or hostile. If it is not hostile when it damages the player, it is passive, whereas if it is hostile when it damages the player, either 1) it is hostile - it attacks when it can, and it can only do so when the player gets close enough to it; or, 2) ghasts are neutral, and coincidentally have no situations in practice where they are passive.
There have also been opinions voiced that passive mobs can't/won't deal damage to the player, or that friendly mobs don't attack the player. This, however, is untrue, as these claims do not follow from any definitions, and are without basis. Such misunderstandings should be prevented with disclaimers within articles, rather than by shaping the classifications around them. Blue Banana whotookthisname (talk) 23:56, 29 July 2020 (UTC)

Brewing, smelting, grinding, looming, smithing, stone cutting usage

I wonder if anyone is interested in some other type of usage templates besides {{crafting usage}}? Looking at Module:crafting usage, it occurs to me that the same module can be adopted to serve many other usage without too much change in the code. If anyone finds that interesting, I can start working on that.

For the technical reader, the DPL category search of {{crafting usage}} will be reused, but with a different target template in the include parameter. This will mean that the recipe categories will not only include crafting table recipes, but I personally think that makes sense.--Arthur200000 (talk) 15:59, 25 May 2020 (UTC)

 Weak support. Don't see why not, but these methods of crafting are also far less complicated than crafting tables; they're likely not very necessary. -PancakeIdentity (talk) 04:04, 27 May 2020 (UTC)
I could support this, but Crafting usage is quite inefficiently done. The DPL & category system by itself is not a good way to do it, but replacing it would require installing something more serious like the Cargo extension. Also, crafting is certainly much common than any other means of production combined. — BabylonAS *Happy Camper* 07:36, 24 September 2020 (UTC)

Using sprite grid with schematic sprites

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

{{Sprite grid
|r=Schematic/Data:+ra-ew
|p=Schematic/Data:+pr-ew
|d=Schematic/Data:+dr-ew
|S=Schematic/Data:+si-$n
|.=Schematic/Data:+ellipsis-ew
|_=air
|_____S_______________________________
|.rrrppprdprdpprrrrrrrrrrrrrrrrrrdppr.
}}


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

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

Should unreleased versions be documented on the wiki?

[2] There's been a very long discussion that actually got quite heated, on the Discord server, about the question; should versions that are unreleased be documented on the wiki? Because this decision seems clearly controversial and the Discord is generally not the place to make definite decisions, I figured I'd bring this to the wiki since no one else has done so. I personally haven't made up my opinion on this (yet).--Madminecrafter12 (Talk to me | View what I've done) 02:45, 13 June 2020 (UTC)

Reposting and reformatting my statement from Discord:
Some Minecraft versions have never been intentionally released, but their existence was made available by accessing internal data for a software distribution service.
Stating the wiki's purpose, MCW is a wiki on Minecraft and all related topics, striving to be as complete and accurate as possible.
When we say some completeness (i. e. some information that is accurate and related to Minecraft) is inappropriate, it's because:
  1. this information is unacceptable to host on MCW, such as due to breach of law or contract (copyright infringement, non-public info, etc.)
  2. hosting this information will create a precedent for other similar information, which cannot be managed (e. g. galleries of custom builds with no limits on how many there can be)
  3. this information is not a good fit for MCW, either for technical or community reasons, and should be hosted on another wiki or another website entirely (mods and non-English pages have their own wikis; videos are too large for the wiki and are hosted on YouTube; etc.)
(if I missed a point, please inform me)
Non-public versions like the one found aren't `2` (there aren't an unbounded number of them) or `3` (hardly needs an external resource), but may be `1` if the access to the version list data, and its disclosure, is somehow illegal.
I'm not sure this is the case, I can see how it could be a breach of the Terms of Use for that software distribution service, but for it to be _illegal_, it would have to be more than that, I guess? --AttemptToCallNil (report bug, view backtrace) 02:47, 13 June 2020 (UTC)
 Yes, of course. The wiki should strive (and is striving) towards having complete documentation on the developmental history of the game. And that includes unreleased versions. We've had pre-Classic on the wiki for years without issue, and most of those did not advance past compilation. Unreleased versions in amongst release versions should not, however, be listed in infobox navigation or on their parent² pages, and should only be listed in the navbox and on Version history in italics.  Nixinova T  C   02:52, 13 June 2020 (UTC)
 Support with contingencies. I'll re-state what I said on discord:
Changelogs on them should be as complete as possible. Of course, these would have to be done with testing, but testing being required is hardly an argument for not documenting something. I'd be opposed to distributing versions we don't have access to, but I don't think we have Bedrock versions archived on the wiki in general anyway. These changelogs should not impact the changelogs of released betas. For example: Beta A is released, Beta B is not, and Beta C is. The page for Beta C would include everything changed in Beta B (possibly with a note that they were changed in Beta B?).
I'd also say, if we get word that this could get us in legal trouble, I'd say remove them right away. It's worth noting that this is different than say pre-classic versions. First off, the legal protections surrounding Java and Bedrock seem to be different (I may be wrong about this), but definitely, at the time, everything was much looser. Second, we have freely available evidence of those versions from the chat logs linked in references, while the only proof for the existence of these betas and the changes within them are obtained through a much more "gray area" method.
TL;DR: Support, but lets be careful about it and not let it impact how we document actually released betas. -PancakeIdentity (talk) 03:45, 13 June 2020 (UTC)
Addendum with some thoughts I missed: We should treat them like dev builds for the next released beta. The changelog for the released beta is a compilation of all changes from the previous unreleased ones, the parent should be set to the next released beta, etc. Also worth noting that there's multiple legal angles to look at this from, both Minecraft/Mojang's TOS/EULA and those of the Google Play Store, which is where most of the modern unreleased betas have been pulled from afaik. -PancakeIdentity (talk) 05:32, 13 June 2020 (UTC)
For my case, I posted a leaked changelog of an unknown beta back in 2018. It's not really leaked since the changelog is from Minecraft.net but for some reason the developers pushed back the release date. Here's the leaked changelog. I'm supportive  Support of if the changelog is made public or if it doesn't violate any of the laws.--skylord_wars (talk) 05:00, 13 June 2020 (UTC)
 Neutral -- yes, but only if it's reasonable. The discussion emerged because there are apparently some old Bedrock betas that were uploaded to the Play store, but actually never made available to the public. As far as I understand it, you need a third-party app in order to actually be able to access these versions.
Often, the only thing known about these versions is that they exist; not much else is known, since Mojang obviously usually doesn't release changelogs for unreleased versions. As such in order to get a complete changelog, the changes would need to be (re)discovered manually, which is very time-consuming and in my opinion not worth it. Additionally I don't think having a lot of articles about unreleased versions that are basically empty and just say that the version exists is desirable. Apart from that, there's the issue of how released versions' changelogs should be handled: If a released version is after an unreleased version and the changelog of the unreleased version is known, should the contents of the unreleased version's changelog be removed from the regular version's changelog? I don't think so.
I don't think that unreleased versions shouldn't be documented at all, but they shouldn't be treated the same as released versions and get an own page (except if they're notable enough or there's enough content to warrant an own page). Proposed solutions to this are having these versions in a Trivia section somewhere (e.g. in the next released version's article), in an extra section in the version history page, or an extra single article to specifically document unreleased versions.
Lastly, I want to point out that there are a huge amount of unreleased versions of Minecraft, for instance every git commit could be considered its own version. Documenting those would just be worthless. But these versions are not known to the public anyway; there's only a small number of unreleased versions altogether that made it to the public at some point. But there's a point where useful information ends and unnecessary clutter starts. | violine1101(Talk) 07:16, 13 June 2020 (UTC)
The difference is that these were packaged and ready to go, just not pushed out to users. They have distinct identities and version numbers (they're why betas sometimes skip versions). Comparing it to git commits seems like a bit of a slippery slope. -PancakeIdentity (talk) 08:30, 13 June 2020 (UTC)
"which is very time-consuming and in my opinion not worth it.": Well, you don't have to be the one to do this; "should the contents of the unreleased version's changelog be removed from the regular version's changelog?": No, they should be treated as dev builds of the dev builds, and have their changelogs detailed on the release version two; "every git commit could be considered its own version.": no, not at all, that's not a compiled build, these bedrock versions have been compiled, their version number bumped, and actually uploaded to the store, so they obviously have some amount of completeness to them.  Nixinova T  C   19:24, 13 June 2020 (UTC)
 Neutral I guess this seems to be something people want, but:
Now having taken a look at the pages for unreleased Bedrock beta pages that do already exist, they seem to turn out the exact same way, I'd imagined these pages to turn out: They are currently still blank and already exist for quite a few weeks. I do know, that there are a lot of pages already (e.g. older versions for Java Edition and Launcher versions) that are blank but there's evidence that they were released to the public and therefore they should of course be documented.
But even if we do test things out and figure out the additions, changes and bug fixes that have been made in those versions, the readers would then turn to the next (released) beta and would see info that has already been mentioned on the previous (unreleased) beta page. And finding out the differences between those two betas by comparing both pages would probably be annoying and should be avoided. I actually like the idea of having that disclaimer and the categories but those pages should differ even further in my opinion and should be as different as possible, in terms of how things are documented. ---- Elite hog (talk) 10:41, 13 June 2020 (UTC)
"the readers would then turn to the next (released) beta and would see info that has already been mentioned on the previous (unreleased) beta page." unreleased versions and release versions would not go together in the infobox navigation. It's a similar situation to e.g. 16w50a vs 1.11.1. "They are currently still blank and already exist for quite a few weeks.: Yes, I'll have to ask the omni guys what's changed in the version, I just haven't got round to that yet.  Nixinova T  C   19:24, 13 June 2020 (UTC)
 Yes, of course, but with notice, that version was never released. --Treeislife2 (talk) 06:42, 15 June 2020 (UTC)
 Yes, per above reasons. — Thomanski | t | c | 14:33, 22 June 2020 (UTC)
 Yes for reasons already said. – Sealbudsman talk | contribs 15:59, 22 June 2020 (UTC)
 Support nothing to add---Humiebee Discuss anything with me Look at my edits 23:31, 12 August 2020 (UTC)
 Yes, nothing to add Blockofnetherite Talk Contributions 23:49, 18 August 2020 (UTC)

Collapses for Fixes section

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

 Oppose for making collapses. If yes, then at least implement code to Module, not to article (+ do some formatting). --Treeislife2 (talk) 09:34, 21 June 2020 (UTC)
 Weak support if uncollapsed by default, and changed in the module as said above. — Thomanski | t | c | 14:30, 22 June 2020 (UTC)
Oppose auto-collapse, some support for collapsed by default. -PancakeIdentity (talk) 03:46, 23 June 2020 (UTC)
 Oppose the auto-collapse, because it makes it easy to scroll and miss the fixes. However, I'm  Neutral if it is collapsed by default, and done properly. Sagessylu (discuss | edits) 15:39, 25 June 2020 (UTC)

Convert some disambiguation pages into broad concept articles

Some disambiguation pages, such as Jockey, hold the title of a primary topic. I think these pages could be rewritten as broad concept articles. For example, the page mob doesn't simply show a list of all mobs in Minecraft, but also show common properties of mobs. Also, there are some disambiguation pages that could be classified as set index articles. See WP:Broad-concept article for more information. --Fadyblok240 (talk) 16:32, 26 July 2020 (UTC)

 Support. This is more of a narrow concept, but Insomnia does something similar, though on a much smaller scale; a description of the mechanic with links to various related pages. -PancakeIdentity (talk) 08:37, 27 July 2020 (UTC)
Do you think I should start a list of disambiguation pages to be converted into articles?Fadyblok240 (talk) 17:53, 3 August 2020 (UTC)

"Attempted Fixes" section on version pages?

I mentioned this on the discord and people seemed to like the idea, so I thought I'd bring it here for formal discussion. Should we have an "attempted fixes" section on version pages? These would be tickets that Mojang listed in their blog post (or were otherwise marked as fixed by them prior to the version's release), but were not actually fixed. Seems like it'd be simple to implement and to me it makes sense to document this stuff. -PancakeIdentity (talk) 07:11, 30 July 2020 (UTC)

 Support It would be useful and can be done rather quickly. Sagessylu (discuss | edits) 08:07, 30 July 2020 (UTC)
 Support The changelog for Bedrock Edition 1.11.0 says that they fixed falling through the world at powers of 2, but they did not actually fix this. The BlobsPaper 18:14, 30 July 2020 (UTC)
 Weak Support Agree with the reasons above but might take a long time and be a hassleHumiebee talk contributions 17:28, 4 August 2020 (UTC)
 Support, as those fixes were at least mentioned in the blog posts and should also be worth mentioning on the wiki. ---- Elite hog (talk) 09:03, 16 August 2020 (UTC)
 Support, might reduce some confusion for people seeing those attempted fixes listed on the official changelogs. –Sonicwave talk 00:23, 18 August 2020 (UTC)

Regarding Project:Welcome

Is this project still alive in anyway form or shape? I'm guessing not because I asked this same question there 2 days ago without reply. If so would anybody be interested to restart it? Because as a new user I have some ideas about what could be done better. Asarta (Talk) 09:18, 3 August 2020 (UTC)

I looked at the list of users, and most of them are from far back. AFAIK the only active user on the list is Madminecrafter12. I will contact them. The BlobsPaper 15:17, 3 August 2020 (UTC)
I've seen a few users welcomed (though, it's usually a preface to a warning :P). -PancakeIdentity (talk) 05:41, 5 August 2020 (UTC)

Rework command pages

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

Some changes I suggest:

  • Use {{argument}} and {{literal}} to show arguments and their types (these two templates are still WIP). Use {{arg desc}} to show formats of arguments.
  • Use result table to list results of commands. Results includes:
    • Unparseable‌[Java Edition only] - Syntax is wrong, command is unknown, or arguments are illegal
    • Failed - The command is executed but the success count is 0
    • Successful - The command is executed and the success count is not 0
    • Terminate‌[Java Edition only] - Does nothing and doesn't output anything.
    • Exception‌[Java Edition only] - Throw an exception other than brigadier.exceptions.CommandSyntaxException during execution.
  • Use output table to list results of commands. Outputs includes:
    • Success Count - Success count stored in command block when the command is executed by it.
    • /execute store success ...[Java Edition only] - Success value stored by /execute store succeess ...
    • /execute store result ...[Java Edition only] - Result value stored by /execute store result ...

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

Now all templates are done, and I'll edit these command pages tomorrow.--Chixvv (talk) 13:24, 19 August 2020 (UTC)
I see you've implemented this, and I  Support the changes.  Nixinova T  C   03:39, 20 August 2020 (UTC)
 Support as it does improve the layout of the page.-- LakeJasonFace Lakejason0 (TalkContribs) 10:26, 21 August 2020 (UTC)

Bedrock Technical Wiki corporation

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

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

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

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

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

Kind Regards,

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

So is it going to be a separate wiki or merged into this wiki?, I also have bedrock but i dont have discord ---Humiebee Discuss anything with me Look at my edits 16:10, 12 August 2020 (UTC)
We will be releasing articles on our discord but will add the information from these articles as simplified as possible on this wiki. ItsRichHeart (talk) 21:34, 12 August 2020 (UTC)
Oh 😑---Humiebee Discuss anything with me Look at my edits 21:37, 12 August 2020 (UTC)
If there's a problem with bedrock content on the wiki, the solution is to fix it when possible, not move it off wiki as that would just exacerbate the problem.  Nixinova T  C   00:09, 15 August 2020 (UTC)
This. Splitting the community, in terms of both editors and readers, is not helpful. Do what you need to allow Bedrock to be documented fully on here. -PancakeIdentity (talk) 09:00, 16 August 2020 (UTC)
I think setting up a new wiki for unique technichal things in BE for only developers and technology players is not bad. However, we should also work together to make this wiki better, especially in the field of non-technological game behaviors. If you find false info here, just fix it. Note it is not all of editors here that are ignorant of the bedrock edition. Just edit it as long as you like, and we'll help defend against vandalism.--Chixvv (talk) 16:04, 16 August 2020 (UTC)
I propose that the information be on this wiki whenever possible. However, you can consolidate the information on discord to help us port it here. The BlobsPaper 19:22, 17 August 2020 (UTC)

request to create more protection levels

currently, we only have 2 levels of protections (and 1 abuse filter) that limit editing, Stop ip-addresses, Stop newcomers, and Stop all but admins. So i think that like wikipedia, we should hava a protection level that only autopatrol/experienced users(look at recent changes) can edit so that pages such as Template:Version/FP can be edited by trusted users, instead of admins only.---Humiebee Discuss anything with me Look at my edits 23:29, 12 August 2020 (UTC)

Autopatrol-level protection was suggested several times in the past (mostly in the Discord), but I believe it was mentioned that custom protection levels may cause technical issues, though I personally don't recall major issues with the custom directors protection that we already have. Autopatrol protection on Template:Version/FP wouldn't work since it's overridden by the main page's cascading protection (which is admin-only). –Sonicwave talk 23:51, 12 August 2020 (UTC)
I looked at previous discussions and unfortunately.......they can't add it😭😡---Humiebee Discuss anything with me Look at my edits 22:19, 16 August 2020 (UTC)
 Support more protection levels (specifically autopatrol) as they'd be useful in general, even if not applicable in the specific situation mentioned in the proposal. -PancakeIdentity (talk) 08:58, 16 August 2020 (UTC)
 Strong Oppose. Why? What are problems with current one? Also, auto patrols shouldn't are basicly editors, who are so editing, that admins have problems with monitoring other users. --TreeIsLife (talk) 22:56, 9 September 2020 (UTC)
 Disagree with that argument.  Strong Support for more protection levels. Autopatrol level protection is important, especially when abusive persistent vandalism and sockpuppetry forced the admins to set full protection. One example is Human, which was bombed over and over by sockpuppets until full protection halted all edits, delaying useful grammar edits for a month. That protection of Human recently wore off, but Splash is fully protected due to sockpuppetry. This isn't good, as the page has a work in progress template, and many other things there may need constructive editing. Expanding the protection from directors to autopatrol allows more edits, while requiring enough contribution to the wiki to be trusted. Blockofnetherite Talk Contributions 03:09, 21 September 2020 (UTC)
Not to mention that the WIP template doesn't use the section param. For now maybe the protection duration should be reduced to about 1 week instead of 1 month to resume constructive edits sooner. By the way, you should submit Gamepedia help tickets regarding the creation and modification of new protection levels, as even the admins of the wiki cannot modify protection levels. Fadyblok240 (talk) 02:33, 22 September 2020 (UTC)
The difference is that autopatrol users have been marked by an admin as having useful edits, so locking a page to autopatrol and above would be useful for pages that get sockpuppeted. It's especially useful now as accounts are now really easy to make due to the move away form solely Twitch, and since semi protection only locks it to registered accounts it's very easy to get around, leading to situations where Splash is director protected only due to spam from new accounts. I'll work on making an abuse filter that accomplishes autopatrol level page locking later.  Nixinova T  C   03:22, 21 September 2020 (UTC)
 Support a protection level similar to Wikipedia's semi-protection and extended-confirmed protection, based a mandatory combination of account age and number of edits on this wiki (say, 10 days and 20 edits).  Support a protection level allowing the autopatrol right only in extreme cases because it casts too wide a net, too many constructive editors don't have that right. ~ Amatulic (talk) 05:28, 21 September 2020 (UTC)
 Support. TheGreatSpring (talk) 05:30, 21 September 2020 (UTC)
Is it possible to create a protection level in which only 'Experienced Users' (recent changes) can edit, similar to wikipedias 30/500 protection? pages like splash could be demoted.---Humiebee Discuss anything with me Look at my edits 19:32, 21 September 2020 (UTC)
You're referring to "extended confirmed protection". I suggested 10/20 in my vote above. Maybe 10/100. For this wiki, 30/500 seems a bit aggressive. ~ Amatulic (talk) 05:47, 22 September 2020 (UTC)
True, I guess that is quite agressive, maybe wikipedia's semi-protection? I would be fine with yours. With the excpetion of previously blocked users, I never see vandalism on the 'learners' section.---Humiebee Discuss anything with me Look at my edits 12:02, 23 September 2020 (UTC)

Can create a EarthEntitySprite?

Because there will be more and more creatures in Minecraft Earth.Odyssey08 (talk) 08:39, 14 August 2020 (UTC)

Is there a benefit from splitting it from the current entity sprite sheet? -PancakeIdentity (talk) 08:57, 16 August 2020 (UTC)
 Oppose why, no point as there is already a normal entity sprite.  Agree with PancakeIdentity---Humiebee Discuss anything with me Look at my edits 22:18, 16 August 2020 (UTC)
 Support for consistency. There's already a DungeonsEntitySprite (with 72 sprites) and the EarthEntitySprite would have about 48 sprites, expanding rather quickly, so it's as reasonable as the Dungeons one. Sagessylu (discuss | edits) 14:20, 17 August 2020 (UTC)
changed to  Support---Humiebee Discuss anything with me Look at my edits 19:21, 17 August 2020 (UTC)

Proposal: remove images from history and put them into separate gallery subpages

This is distracting with how many animations there are. This is annoying to read and translate with how many images there are. This disrupts the flow of text because the images are large.

I propose to not put historical images into history lists directly, but instead maintain a history gallery subpage with the images. Notably, that would be a subpage and not a section, as I don't believe most readers would need those images, and so they're an invariable bandwidth/performance strain. --AttemptToCallNil (report bug, view backtrace) 09:26, 21 August 2020 (UTC)

 Support, and while doing that for revisions, maybe it's also an idea to do it for the block states sections like with redstone wire? Currently, some block states are hard to understand with the explanation they have. Images for visual block state differences would help. FVbico (talk) 09:37, 21 August 2020 (UTC)
 Support, it took a lot of time to update these spawn egg images on Chinese Wiki (from sprites to images), and barely does nothing. It might be a bit useful when there are a little images along with historical texts, but only a little.-- LakeJasonFace Lakejason0 (TalkContribs) 10:07, 21 August 2020 (UTC)
 Support, they are just an eyesore at this point. I had this idea beforehand but not encouraged enough to make a remark. For now, I would only think that separating them is the best decision. – ItsPlantseed|⟩ 10:30, 21 August 2020 (UTC)
I'd say this is more of an issue with the History template itself than its contents, and we can all agree that said template is way overdue for a revamping. - User-12316399 (talk) 12:00, 21 August 2020 (UTC)
 Agree with you, also  Neutral about this topic---Humiebee Discuss anything with me Look at my edits 12:56, 21 August 2020 (UTC)
 Support, sheep kinda does this already. -PancakeIdentity (talk) 03:32, 23 August 2020 (UTC)
 Support. — Thomanski | t | c | 13:15, 23 August 2020 (UTC)

Proposal

I have created a potential mock-up on User:Thomanski/Sandbox/Gallery for Log. Any feedback appreciated. — Thomanski | t | c | 13:15, 23 August 2020 (UTC)

 Support. -DEJVOSS (talk) 13:47, 26 August 2020 (UTC)
Changed to  Support---Humiebee Discuss anything with me Look at my edits 17:29, 4 September 2020 (UTC)

The problem with subpages

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. Fadyblok240 (talk) 02:40, 27 August 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
---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
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?

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

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. Fadyblok240 (talk) 02:16, 19 September 2020 (UTC)

Documentation template revamp

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)

Move the Greek and Turkish Wiki back into translation projects

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)

Replace /ED, etc, subpages with DPL section transclusion

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

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)

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

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.

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)

Add shorthand Namespaces for certain things

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
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)

New proposal

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.
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)

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

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)

Can I edit "Bedrock Edition scripting documentation"

I am thinking of editing Bedrock Edition scripting documentation but I am not sure if I am allowed to. This is my first time contributing to wikis. I want to add on to the createEntity() that if the Type is specified as item_entity then TemplateIdentifier should be the item identifier and not the identifier of an entity. 73.241.136.27 02:57, 15 September 2020 (UTC)

I don't see any protections. Well, most of pages are not protected. But admins are mostly blocking pages with hype. These are: Minecon few hours before beggining, new major update (planned/released) and of course, pages with vandalism. And, IPs can't create any new pages (except talk pages), so you should Create a new account which will grant you abiloty to create pages + you will can use this account on any other Gamepedia and even Fandom wiki--TreeIsLife (talk) 13:01, 15 September 2020 (UTC).
Okay thanks, I will create an account. 73.241.136.27 17:22, 15 September 2020 (UTC)

Change formatting for hatnotes

Currently, there is excessive padding around hatnotes. A proposed change of mine would condense the spacing, making the hatnotes more similar to that of Wikipedia's. The following should be added to the common.css file:

/* Hatnotes and disambiguation notices */
.hatnote {
	font-style: italic;
}
.hatnote i {
	font-style: normal;
}
div.hatnote {
	/* @noflip */
	padding-left: 1.6em;
	margin-bottom: 0.5em;
}
div.hatnote + div.hatnote {
	margin-top: -0.5em;
}

to replace

/* [[Template:Dablink]] */
.dablink {
    padding-left: 2em;
}

Also the contents of {{Hatnote/sandbox}} should replace the contents of {{Hatnote}}, which currently has hardcoded css values.

Fadyblok240 (talk) 05:26, 26 September 2020 (UTC)

What's the benefit of putting on these stylesheets as opposed to raw inline styles? The latter seems like it would be way easier to keep updated.  Nixinova T  C   02:12, 27 September 2020 (UTC)
Here's the thing: the current template forces italics, and italic markup cannot cancel it. Using the new stylesheets would allow italics within italics (i.e. no italics). Also, when the new styles get implemented, we don't have to worry much about changing them for a very long time. Fadyblok240 (talk) 04:53, 27 September 2020 (UTC)
Hatnote comparision

Change the main discussion from MCT:CP to MCW:Centralized discussion

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.
  7. However, it fits more nicely

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

Advertisement