Talk: Community portal

This is the community's main discussion page.
Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the feedback site.
This page is for community discussion; generally, wiki issue reports 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 [ ] 14:57, 12 March 2019 (UTC)

Proposal

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

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

If what Jack's suggesting is that Mechanics is its own section, not part of Tutorials but on the same level as Tutorials, then I  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 [ ] 07:20, 28 April 2019 (UTC)

 Support – Nixinova   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 [ ] 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, eventhough we've subpaged it with all the circuit pages. It would be a good idea to add some overview content to that sub-main page as well. – Jack McKalling [ ] 12:49, 10 October 2019 (UTC)

Reversion of the proposal

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

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

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

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

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

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

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

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

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

I would actually support that far more than "Mechanics/Village", etc. I believe it is more meaningful to have the mechanics pages be structurally/logically dependent on the thing mechanics of which are described than on the concept of mechanics. I might actually support the same with tutorials, like mob farming and combat tactics as subpages of corresponding mobs, and e. g. "Cactus/Farming". --AttemptToCallNil (report bug, view backtrace) 23:50, 13 October 2019 (UTC)

This proposal of PancakeIdentity & ATCN makes sense to me; I support that scheme. —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 [ ] 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 Blobs 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)

Chemistry

(See Also: User:Blobs2/Renewable resources#Quasi-Renewable Resources)

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

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

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

 Support this as the chemistry blocks are not renewable. —HaydenBobMutthew ^{(talk, contribs)} 04:43, 19 August 2019 (UTC)

Sound file attribution

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

Not a licensing expert, but I agree with this proposal. --AttemptToCallNil (report bug, view backtrace) 19:05, 27 August 2019 (UTC)

I might go ahead and begin slowly changing the non-music sound descriptions to use {{License Mojang}} instead of {{License C418}}. I'm not sure how to figure out which sounds are from Freesound without listening to everything on the attribution page and seeing what sounds familiar, since the files don't have attribution info in their metadata (unless I looked in the wrong place).

Also, License C418 says "In agreement with C418, Minecraft sounds are allowed to be hosted on the wiki. All music must be shortened to the first 30 seconds"; is this agreement publicly viewable or was it made through something like a private IRC channel? –Sonicwave ^talk 06:11, 5 October 2019 (UTC)

 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)

Some changes I've made to infoboxes

I've done some stuff to infoboxes today and felt like I should check in here and ask for other peoples' thoughts on the matter before I proceed further.

Template:Fluid

I've decided to create a new infobox to split off fluids into. This might be a bit excessive, since there's technically only three fluids in the entire franchise, but they do behave considerably differently from other blocks, and it's worth noting that they probably won't even be considered blocks anymore with the planned fluid split (assuming that actually ends up going through, of course). I've equipped this template with its own set of parameters specific to liquids, and it seems to hold together relatively well. See Water, Lava and Mud for examples.

Biome colorations in Template:Biome

I added some fields to the Biome infobox that record biome-specific plant, water, sky and fog colour codes. A test case can be seen at Badlands#Badlands (I haven't filled in the details on any other infoboxes, though). While they fulfil their job I feel as though they take up quite a big chunk of vertical space, which I feel could potentially be alleviated by compressing all of these values into some sort of "Biome colors" title, collapsed by default but expandable, like what can be seen here. Are there any other thing whose colours/appearances vary by biome (I think fog is one, or at least it will be in 1.16), and should I even continue with this in the first place?

Splitting sounds and drops into their own sections

This is another thing I've considered doing for a while. I decided to give it a shot (see Anvil#Sounds and Barrel#Sounds) and want feedback on this way of setting it out. I thought that sounds took up a bit much space on some of the infoboxes, and also believed that there was much more that could be said about them in a dedicated section (i.e. their internal IDs, their subtitles, volumes, pitch ranges, and the sound type category thing you specify in playsound).

Drops is another thing I'm not really happy with being inside the infobox, since again, there's a lot more that could be elaborated upon that would end up clogging up the template were it kept in it, such as how many of each item it could drop with Fortune, different drops depending on tools, and other conditional stuff. A dedicated section for drops, roughly equivalent to the Obtaining section, seems like a better move. Granted, this may result in lots of trivial repeated information (Breaking a barrel with any tool drops a barrel.), but this shouldn't be too much of an issue. On the topic of drops and obtaining, I think we should try reformatting the Obtaining section to more closely resemble the French wiki's obtaining sections, since monotonous paragraphs of text are boring, harder to digest and retrieve information from, and are generally less pleasing to the eye.

Any thoughts on these? - User-12316399 (talk) 19:36, 30 September 2019 (UTC)

I've now split off all block and enchantment sounds into respective sections and removed the Sounds parameter from the infobox template. Eventually I'll complete items and then mobs as well. - User-12316399 (talk) 07:46, 3 October 2019 (UTC)

...and some changes I want to make

Removing the Drops and Experience fields

I've detailed in the section below my proposals for how these would be documented. With those moved into that new section, these fields would become redundant and could be removed.

Removing data values

I'm not sure these (numerical IDs, at least) should be documented within the infobox, since the plan appears to be to remove them and perform a flattening across Bedrock Edition for parity reasons. We could probably keep the namespaced IDs there, though, since those will be official for as far as we can see going forward. Numeric IDs will still be kept in their own section. I'm also not sure about tags, these could probably also be relocated to a more technical section lower down.

Currently underway. - 23:51, 5 March 2020 (UTC)

Flammability values

Certain blocks are more flammable than others, should the values for them be documented in the Flammable row?

Removing the tool fields

These are already documented in the very first section of most blocks, so do they really need to be documented in the infobox? (I do feel as though the section in question is rather incomplete in itself, and could do with more info such as the effects of Haste, Efficiency, and different tool types, as only listing unenchanted tool times feels very incomplete.)

Add more parameters

Now that we've relocated a bunch of block info to dedicated sections where they can be described in further detail, is there anything we could replace them with in the infobox that doesn't need much further elaboration? Two that come to mind are how much they slow entities passing through them (the value we'd show here would be the number they multiply entity movement by), and how slippery the block is (this only applies to a small set of blocks, though).

Any thoughts on these ones? - User-12316399 (talk) 09:36, 1 October 2019 (UTC)

We should keep numerical IDs until the flattening. The Blobs 13:59, 1 October 2019 (UTC)

Should they be marked as Bedrock Edition exclusive as to not cause confusion? - User-12316399 (talk) 14:37, 1 October 2019 (UTC)

I'd support that. Make sure to use the short=1 tag. -PancakeIdentity (talk) 01:45, 13 October 2019 (UTC)

Replies

I feel like you should have copied the templates into your sandbox and made changes to them to see if they really work and fit. "Editing in production" has a risk of ruining pages. Lê Duy Quang (Make some words | Contributions) at 9h58:44 | 1/10/2019 (UTC)

Regarding sounds, what would go under "Pitch, Volume, and Min. volume"? The default sounds.json file does specify volume and pitch for some of the sounds, but all of the sounds already have different pitches and volumes anyway, so in my opinion this wouldn't make much sense for a casual reader. I can see the "source" column being useful (though it would be better renamed "category", "type" or "volume setting"), though that would require reading decompiled code since categories are no longer specified in sounds.json since 1.9.

Also, we should probably amend Minecraft Wiki:Style guide/Features to specify where the sounds section should be placed within the article. –Sonicwave ^talk 05:48, 5 October 2019 (UTC)

Those parameters are pretty much completely ripped off from the playsound command with no real knowledge of how they work. However, it's definitely possible to see that pitch is definitely one worth noting - glass breaking sounds and piston sounds are always lower pitched than their default values from the command, and some sound sources have variable pitches, such as sheep (and don't forget that baby animals are affected).

As for where to put these, I've just been putting them before Data values or Achievements, whatever comes first. - User-12316399 (talk) 20:52, 5 October 2019 (UTC)

The biome colors definitely need to be listed somewhere. Any chance we could display what these colors actually look like? Also, I'm not sure about removing them from infoboxes, but I definitely support expanding the breaking time table/template to include Haste and Efficiency. -PancakeIdentity (talk) 01:45, 13 October 2019 (UTC)

I would  Support to have colors inside infoboxes.--skylord_wars (talk) 08:19, 2 December 2019 (UTC)

I am not sure about including Haste or Efficiency in breaking rows, ad it would make them too complicated. Even if we only show Efficiency for diamond tools and only show Haste for diamond tools with Efficiency V, that is 13 scenarios instead of the current 6. The Breaking page does a good job of explaining the times in these situations. The Blobs 14:46, 2 December 2019 (UTC)

03/2020

A good amount of the parameters proposed for removal have now been removed from the infoboxes in question. There's a few more things I want to bring up:

• Are there any more parameters people want added to specific infoboxes that I haven't yet mentioned?
• I'm considering removing the Light source section from the Usage section of pages since most of the time it just pointlessly duplicates a single value shown in the infobox anyway.
• Also considering moving information about a block or item's fuel value into the furnace as well, given it is just a constant value. This would also get rid of a section.
• On some lesser-known infoboxes exist some parameters I'm not too happy with, since they include a very wide range of things: the Consists of section for structures, and the Blocks section for biomes, the former of which should already be detailed in the respective /Structure subpage, and the latter of which could probably be moved out into the main article body as there does tend to be a lot of whitespace to fill.
• Biome-related colours have been made optional parameters on the biome infobox, which I disagree with, as they should be filled in for every biome as they indeed do affect every biome on Bexrock Edition at least.

That's about close to all I have to say on the matter for right now. - User-12316399 (talk) 20:36, 6 March 2020 (UTC)

•  Oppose removing fuel value and light source from the article bodies. I'm ok with it being in both the article and infobox, I just hesitate to hide basic functions of a block/item in the infobox. My general sense is that a lot of users tend to not read the majority of the infobox as it tends to be largely technical stuff. It hides the information more, especially since it'd remove the header from the Contents section.
•  Support removing blocks section from the biomes infoboxes. Lots of info for what should be a smaller thing.

Related, I'd  Oppose removing the "consists of" section for structures as it works great for some structures and terrain features (mossy boulders for example).

•  Oppose making biome colors mandatory (I think). If there's Java-exclusive biomes, would they need the biome color info? I wouldn't think so but I'm not too familiar with those pages. -PancakeIdentity (talk) 21:28, 6 March 2020 (UTC)

Surely for cases of Consists of that can be clearly described, either the name of the structure or the introductory paragraph would offer sufficient information as to make it redundant?

Maybe having mandatory biome colours could be a temporary measure, to make sure all pages without them filled in are added to a category, to make pages with them not filled in easier to find. Also, simply because a biome doesn't have exclusive colours doesn't mean it doesn't have colours at all, so noting both java's and bedrock's values would be beneficial even if java's would be a lot more boring.

I've got pretty much all of the values I could think of added to a test template, a few examples of these can be found at Template:User-12316399/Block/doc. Feedback highly desired. - User-12316399 (talk) 01:29, 7 March 2020 (UTC)

Module/database thing for infobox values

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

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

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

For items (and blocks that exist as items):

• Renewability (boolean)
• Stackability (number)

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

Why does the word "Cargo" come to mind? --AttemptToCallNil (report bug, view backtrace) 14:54, 10 October 2019 (UTC)

I definitely support the new parameters, such as movement speed and slipperiness. The hardness and blast resistance values are used outside of infoboxes, but not all parameters are. I would support having a module in this case so we get the same value across pages. I would not support a module for renewability because the Renewable resource and Non-renewable resource pages would still need to list the items manually. The Blobs 23:51, 10 October 2019 (UTC)

About transparency and documentation of its behaviors

The behavior of transparent blocks is extremely complex and there's not different "categories" like the wiki likes to say they are. Almost every block is unique in some way. I've been documenting placement behaviors (placing transparent blocks that require support on other transparent blocks) at Opacity/Placement. This page currently only covers Java Edition. The problem with this page is that the tables are very large, and it could very quickly get out of control if new blocks are added or the Bedrock information is included. In addition, the page is kind of hidden away. I'd propose some sort of on-page documentation for each transparent block's transparency behavior. This could also cover stuff like mob spawning, light levels, etc. However, I'm not sure the best way to go about this. I'd love some discussion, as the current way we deal with this is not very good. Thoughts? -PancakeIdentity (talk) 01:57, 12 October 2019 (UTC)

I agree that documenting a block's behavior on its article is the better way. Should we pick some articles to experiment with adding that information to them? --AttemptToCallNil (report bug, view backtrace) 07:39, 12 October 2019 (UTC)

It looks like Torch has a decent table on it. Maybe something like that? We could also probably just copy the shulker box/piston sections on Opacity/Placement to the shulker box and piston pages. -PancakeIdentity (talk) 17:03, 12 October 2019 (UTC)

Yes, something like the table on Torch – and with your improvements (good work on that) I'd even say exactly like that. Also agree on shulker boxes and pistons, I think this information should be on their articles. --AttemptToCallNil (report bug, view backtrace) 17:28, 12 October 2019 (UTC)

The other thing I was wondering is how to document how a free-standing block's transparency works (such as Spawner, Glass, Brewing Stand, etc). Right now, most just have something in the infobox, but this doesn't provide a lot of information. For example, glass and spawners being listed as being partially transparent leads to misconceptions about placement behaviors, spawning, etc. Should we make a new section on the pages dedicated to this? Maybe a "Transparency" section? I'm not sure. This could help trim down these placement sections, as if we say that all blocks can be placed on spawners on the Spawners page, it doesn't need to be documented everywhere else.-PancakeIdentity (talk) 17:44, 12 October 2019 (UTC)

I would support a transparency section. I am not sure why so many different properties of blocks are categorized as transparency, so we definitely need more information. For example, ice is transparent but polar bears can spawn. This means that ice would need to be considered opaque in mob spawning, at least according to the Bedrock Edition algorithm. The Blobs 18:04, 12 October 2019 (UTC)

Yeah, the behavior is pretty complicated. Ice seems to act as an opaque block (aside from rendering), like glass and light sources. It just has a hard-coded behavior to not allow snow on it to keep ice environments clean. -PancakeIdentity (talk) 18:09, 12 October 2019 (UTC)

I've always found the non-light-related definitions of "transparent blocks" to be unintuitive (suffocates mobs, allows spawning, block placement etc.), so I would support documenting these behaviors separately. I might even support changing "transparency" to something like "light-blocking", since many "transparent" blocks aren't visually transparent (like chests). The table on Torch#Placement seems good, although I'm not sure if it would be better to have top and side placement in separate columns. –Sonicwave ^talk 18:48, 12 October 2019 (UTC)

I agree, it seems like an outdated community term. I think it's time we try to move away from it. And I'll try to split the top/side placement and see how it goes. -PancakeIdentity (talk) 19:24, 12 October 2019 (UTC)

 Agree. They should be different infobox params instead of being shoved into a footnote.  Nixinova  T  C  19:42, 12 October 2019 (UTC)

I think we should split it into rendering, light blocking, and mob spawning. Then the placement rules can be detailed elsewhere and not attached to any of these three. -PancakeIdentity (talk) 23:22, 12 October 2019 (UTC)

Those properties plus placement are not an exhaustive list. We would need information about chest opening, water currents, etc. This is more information than belongs in an infobox. I propose that we reserve the infoboxes for the properties that will affect the most players, and document the rest in a "Behavior" section. The Blobs 00:07, 13 October 2019 (UTC)

I agree. However, with the chest example specifically, I think that fits better on the chest page and not each block's page. -PancakeIdentity (talk) 01:38, 13 October 2019 (UTC)

 Agree. Visual transparency should be moved to model as that page fits better.--skylord_wars (talk) 08:30, 2 December 2019 (UTC)

There is already a page zh:教程/不透明度 about opacity in Chinese wiki, which is collected and collated by Chinese players. Different opacity is introduced here, and the transparency list in java edition is listed, except mob spawning. This may be useful and perhaps it can be translated to English. -Chixvv (talk) 09:53, 25 February 2020 (UTC)

In addition, 实体方块 does not mean solid block in Chinese, so don't be misled by machine translation.--Chixvv (talk) 09:59, 25 February 2020 (UTC)

Information on mob spawning in Java edition has now been added to the Chinese page. --Chixvv (talk) 15:23, 25 February 2020 (UTC)

I've accounted for different "transparency" block properties in my proposed block infobox overhaul, which can be seen here; please tell me if there's anything more that can be added. - User-12316399 (talk) 12:10, 7 March 2020 (UTC)

From Discord: Proper game rules and predicates regarding block placement

Summarizing a discussion that occurred just now on the Discord server in the #wiki channel.

Discord server member tryashtar provided us with rather useful information regarding block placement. This clearly invalidates "transparency"-based descriptions of placement rules. (Note that this relates to JE exclusively.) Quoting tryashtar:

- pressure plates require the block below to have a rim (e.g. hopper) or center point on top (e.g. glass pane)
- rails require the block below to have a rim
- banners and cakes require the supporting block to be a solid material (materials should probably be documented somewhere)
- bells and levers require the supporting face to be "full"
- carpet just needs to be above anything but air
- lanterns need a center point on top (if place on top) or below (if placed below) -- for example a lantern can hang below a down-pointing hopper but can't be placed on top
- redstone dust requires a full face below, but is also hardcoded to allow hoppers

The "rim" and "center point on top" are apparently well-defined in-game predicates; for example, the center point is a 2x2 center square on the hitbox (not visual box) assuming the surface is a 16x16 square grid. Quoting tryashtar on the "rim", "It's a predicate that is created specifically by removing the entire center section from a full cube, leaving only the, well, rim".

In references to other placement quirks (by tryashtar):

Sea pickles just check if the below block has a non-empty upward face
Not a block but item frames are really interesting, they can be placed anywhere that doesn't intersect with their hitbox (and support block material must be solid (or a repeater/comparator))

By the same person, on leaves' exceptional behavior:

Leaves are considered to have faces that are "full" but not "sturdy"

This rule-based system would probably be far better than exhaustive lists of compatible blocks. In addition, 3D wireframes have been proposed to be made for the predicates mentioned. --AttemptToCallNil (report bug, view backtrace) 21:33, 12 October 2019 (UTC)

Having old sprite textures on, for e.g, snapshot pages

Hello, should we use old sprites textures for old content like snapshots before Texture Update ?

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

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

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

 Agree Up-to-date content should be used on non-historical pages/sections. Version pages are historical pages, and therefore it would make a lot of sense for images to remain accurate to that version, which can be more easily done with images being separately versioned now. –Majr ᐸ Talk
Contribs 08:22, 4 November 2019 (UTC)

Worth noting that this will likely be somewhat decided by this discussion. If we decide to keep and use legacy sprites, yes, they should be used for historical uses. -PancakeIdentity (talk) 04:41, 20 May 2020 (UTC)

Definition of "Partially Implemented"

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

I think the meaning the phrase "partially implemented" is obvious enough to most readers if it refers to combat mechanics and similar features. What we should do instead is rename the "Partially Implemented" sections. Since these features were "added" shortly after being mentioned, I propose the term "Mentioned with partial implementation". However, feel free to give other suggestions. The Blobs 04:21, 23 October 2019 (UTC)

I think the best option will be in section "Deleted features" --Rychlik (disc) 12:17, 23 October 2019 (UTC)

 Oppose Many readers would confuse that with removed features. The Blobs 13:44, 23 October 2019 (UTC)

Discussion management: existing measures aren't working

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

Draft: User:FVbico/Open discussions.

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

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

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

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

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

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

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

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)

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 olmost no one goes to? Completely Agree The Bumblebee 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=*:**}}

  • •  UUID‌: This entity's Universally Unique IDentifier. The 128-bit UUID is stored as four 32-bit integers, ordered from most to least significant

• 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:

• Chunk_format/Vehicle
  •  DisplayState: Optional. The custom block in the minecart.
    •  Name: The namespaced ID of the custom block.
    •  Properties: Optional. The block states of the custom block.
      •  Name: The block state name and it's value.
• • Edit 1243175: First introduced.
  • Edit 1255212: Change the format of Properties.
  • Edit 1379673: Change name ID to namespaced ID.
• Chunk_format/Projectile
  •  inBlockState: Optional. The block the arrow is in.
    •  Name: The namespaced ID of the block.
    •  Properties: Optional. The block states of the block.
      •  Name: The block state name and its value.
• • Edit 1243162: First introduced.
  • Edit 1255211: Change the format of Properties.
  • Edit 1379671: Change name ID to Namespaced ID.
  • Edit 1379674: Change uppercased Namespaced ID to namespaced ID.
• Piston/BE
  •  blockState: The moving block represented by this block entity.
    •  Name: The namespaced ID of the block.
    •  Properties: Optional. The block states of the block.
      •  Name: The block state name and its value.
• • Edit 1242720: First introduced.
  • Edit 1255215: Change the format of Properties.
  • Edit 1379679: Change name ID to namespaced ID.

There are still two pages (Sand/BE and Enderman/ED) with the similar situation, but I believe there's no need to put them here anymore. I'm sure everyone can find where the problem is: people have to update the 5 pages individually if they want to improve the content of the BlockState structure. I believe this is much more complex than simply updating one universal template, and I believe you are more aware of this than anybody else because all these awesome changes are just made by you. Moreover, the function used to read boolean-like TAG_Bytes has been called 84 times, which means if anyone want to update the current description of it, they have to change tons of pages seperately. However, if we had a template for those common cases, this would no longer be a problem.

Here is all my opinion, I really appreciate for your patience. Merry Christmas! --SPGoding (Talk) 23:10, 21 December 2019 (UTC)

 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)

Trading information on pages

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

Leather page
== Usage ==
=== Trading ===
{{Trading information|Leather}}

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

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

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

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

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

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

 Support If you can get someone willing to do it, this would be very helpful. -PancakeIdentity (talk) 00:16, 5 January 2020 (UTC)

Chunk Loading overhaul

Hello there. I noticed many community pages, videos etc. (outside of the wiki) talking about (often now older) changes to chunk loading like the 15 seconds chunk loading on the other side of Nether Portal after entity pass trought. And then i noticed that this wasn't even stated anywhere on this wiki.

https://gist.github.com/Drovolon/24bfaae00d57e7a8ca64b792e14fa7c6 This page very nicely states how new chunk loading works and i would like to distribute its information to pages like chunks, nether portal etc. overhauling and renovating them more or less.

And here comes the question...

Is that information real and up to date? Can anyone confirm or deny it please?

Thank you, have a nice day. Klusimo (talk) 06:12, 3 March 2020 (UTC)

 Support Information about chunk loading is really needed to be added, and the content in that page you mentioned was obtained from the source code and is still not out of date.

And you know, these theories apply only to Java edition. ---Chixvv (talk) 15:44, 4 March 2020 (UTC)

Alright ill start punping these informations to pages, ill do it solo i can :D. As for the java vs bedrock, ill add more info needed and let bedrock players test it. Klusimo (talk) 09:05, 7 March 2020 (UTC)

Remove Spawn Chunks page

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

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

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

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

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

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

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

There are already a page for bedrock edition - ticking area, why not create another new page with title like processing chunk only for java edition, and move all the information about chunk loading to these two pages. Then create a disambiguation page contains chunk, ticking area, processing chunk, commands/forceload, commands/tickingarea, and so on. That Spawn chunk can be redirected to processing chunk. These are my suggestions so you could take it if you like. -Chixvv (talk) 10:50, 9 March 2020 (UTC)

Not bad idea but rather that "processing chunk", i think Chunk loading would be better. But I think its too complicated when we have it in chunk page (also not much would be left in the chunk page). In both scenarios removing spawn chunk page is what would be optimal.Klusimo (talk) 11:09, 9 March 2020 (UTC)

i think Java edition and bedrock editon should not be treated differently. so we can merge ticking area to chunk, or create a new page for java edition. since there isn't much useful information in ticking area(it only introduces that in ticking area events are processed and other chunk not), perhaps merge ticking area to chunk is also a choice. In doing so, both spawn chunk and ticking area page should be removed.-Chixvv (talk) 11:39, 9 March 2020 (UTC)

Agree, I will definitely add it there. So now we also have suggestion to remove ticking area once i merge it. forceload should be removed too. Klusimo (talk) 08:07, 10 March 2020 (UTC)

Added ticking area to chunk page. Now we only need to remove spawn chunks forceload and ticking area page. (Definitelly not their command pages).Klusimo (talk) 08:33, 10 March 2020 (UTC)

Ok, so update to my suggestion, since their pages are stubs and it is already in chunk page now, i suggest removal of spawn chunks/forceload/ticking area pages(not their commands pages though). Klusimo (talk) 08:35, 10 March 2020 (UTC)

 Strong oppose deleting these pages, at least with Chunk's current state. Spawn chunks are only described by the brief start ticket section. To figure out how the spawn chunks work, a reader has to read technical information about chunk levels and level propagation. The spawn chunks page may need updating, but it readily provides the size of spawn chunks, what runs in spawn chunks, and where entities work in the spawn chunks. I don't think all of this information is easily available on the chunks page. There is not enough information about ticking area either. The ticking area page provides information about which events can run and which events are suspended that isn't described on the Chunk page. While it would be possible to merge more information into Chunk, I don't know if that would be a good idea as I feel like it would make it more difficult to find information.

Instead, I would say that the Spawn chunks page should be updated with more recent information. It should be explained that the spawn chunks have a level of 22 which means that "All game aspects are active." A table or image should be made which shows level propagation in the spawn chunks. It can then be explained how the edges of the a spawn chunks do not process entities since they have a level of 32. All of this should link to the Chunk page for more a thorough and technical explanation. jahunsbe (talk) 19:12, 12 March 2020 (UTC)

I get what youre saying but instead of that you can create secction in the chunk page. Its a stub after all now and it needs alot of testing, editing etc. so we can easily add more info about spawn chunks here. The thing is you can update several pages or have one page with all the info. It just needs more edits. You can contribute yourself. Klusimo (talk) 08:51, 14 March 2020 (UTC)

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

Changes to the upcoming template (and similar)

From here on out, Bedrock and Java will match version numbers. I was thinking that to avoid spam and compress those ugly upcoming tags, we could just allow, for example, {{upcoming||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 Blobs 15:16, 17 March 2020 (UTC)

 Support. --dr03ramos (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)

Creation of Tutorials/Experience farming

Hello,

Experience is quite an important thing in Minecraft. However, experience farming doesn't have a tutorial page. I do know that there are quite a few farms that provide additionnal experience, but this page could list all the farms that are good at getting it.

Should we do it ? Sagessylu (talk) 18:57, 23 March 2020 (UTC)

 Support I know many farm designs for Bedrock Edition, and can help expand such a tutorial. The Blobs 21:30, 23 March 2020 (UTC)

Generally on wikis, you should be bold! Go ahead and create the article, there should be nothing wrong with it and community consensus is rarely needed for page creation. -PancakeIdentity (talk) 23:19, 24 March 2020 (UTC)

OK, thanks, I'll do my best ! To @TheBlobs : you're welcome, because I'm playing on Java Edition. Sagessylu (talk) 13:20, 4 April 2020 (UTC)

Split in Tutorials/Cobblestone farming and Tutorials/Stone farming

Hello,

I think we should split Tutorials/Cobblestone farming between Tutorials/Cobblestone farming and Tutorials/Stone farming because the cobblestone farming is getting seriously big and also because there is "cobblestone" in the title and not "stone".

Does anyone oppose ? Sagessylu (talk) 19:00, 23 March 2020 (UTC)

I would keep them merged, since any stone generator can be used as a cobblestone farms by using a pickaxe without Silk Touch. Conversely, you can use a cobblestone farm as a stone farm by smelting the cobblestone. The Blobs 21:29, 23 March 2020 (UTC)

In the future, discuss splits and stuff on those pages. There's not really a need to discuss it on the Community Portal. -PancakeIdentity (talk) 23:18, 24 March 2020 (UTC)

@The Blobs : Well, that's a good thing to point out. Something still needs to be done to make this page clearer though.

@PancakeIdentity : I actually already did that, but I did not receive a single answer in a whole month. Not a lot of people seem to look at tutorials talk pages (which I can perfectly understand by the way) : it looks almost impossible, in my opinion, to discuss splits and stuff on these pages, and that's why I put that here. Sorry for the inconvenience :-D Sagessylu (talk) 13:30, 4 April 2020 (UTC)

"Recent wiki news" section of the community portal

It is currently unclear what is to be included under the "Recent wiki news" section of the community portal. Should it contain policy changes, user right changes, important discussion outcomes, wiki design changes... all of the above? Or should we just remove it completely? Currently the newest item is from September 2019 and the oldest from November 2018. I just figured I'd bring this up here so we could decide what exactly this section should be used for, assuming we don't just remove it completely.--Madminecrafter12 ^{(Talk to me | View what I've done)} 00:50, 25 March 2020 (UTC)

I think just anything that the average editor should take note of should go there. Mostly the stuff you listed. It just needs to be kept up with. -PancakeIdentity (talk) 01:10, 25 March 2020 (UTC)

I support PancakeIdentity's propose. We could make a kind of guide to determinates what should be written there... Ma (talk)

I think we should list major discussion outcomes or design/layout changes there, since there isn't a clear notice of those outcomes anywhere if you're not keeping up with talk page discussions or recent changes. –Sonicwave ^talk 06:12, 16 April 2020 (UTC)

Should sprite files be interlaced?

Currently, sprites (like 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?

-- Cuervo^Talk 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 Blobs 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 Blobs 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.  Cuervo^Talk 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)

Names for wood variants

We've been using the names Nether Wood/Overworld Wood in most cases when the distinction is necessary. However, 20w13a added the #non_flammable_wood block and item tags. Should we change our naming system to be "Non-Flammable Wood" and "Flammable Wood"? The current system is only referenced by the code, and the proposed system is only referenced by tags, which is a step more visible but still not an official name. I also think the nether/overworld system might be a bit more immediately recognizable for the average user, but the flammable system better describes the functional differences.

What do you all think? -PancakeIdentity (talk) 20:56, 25 March 2020 (UTC)

Agreed Ma (talk)

I prefer "Overworld wood" and "Nether wood" as it's more recognizable for the average reader.--Capopanzone (talk | contribs) 00:38, 26 March 2020 (UTC)

20w13a also contains the inconsistent name "#logs_that_burn" (why is there a conjunction in a tag name…) so I don't think we should make a decision just yet.  Nixinova  T  C  01:44, 31 March 2020 (UTC)

Test and add new mood algorithm for cave ambience

Hello, in java 1.16 snapshot 20w12a, new mood algorithm was added for cave ambience to make them play at better times. As I know, it works as this:

• Mood algorithm is % number (0-100%) that increases when player is underground and/or in low light level.(?)
• When it hits 100%, cave ambience plays.

Thats all info. Please someone test how it really works, i mean that first part, how depth and light affect it and then add it as upcoming part to the Ambience page. Thank you. Klusimo (talk) 09:16, 26 March 2020 (UTC)

Cleaning up the meaning of "1.16"

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

Recently on discord, 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 Blobs 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: Limit animations in infoboxes

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

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

 Strong oppose. I don't think this is constructive. What I'd rather have is something that was discussed earlier in a way to stop and control which images are shown. Hovering over the image should stop it from cycling and maybe the invsprites could be used as a way to jump to that image. Or we could have arrows that would allow users to scroll back and forth between the images. It's an issue that needs addressing, yes, but I don't like this solution at all. -PancakeIdentity (talk) 03:32, 5 April 2020 (UTC)

Arrows would probably be a better approach, but they require much more JavaScript and make it more important as opposed to the gallery solution that may work even if JS is for some reason not working. I would support arrows instead if people think the JS factor is insignificant. --AttemptToCallNil (report bug, view backtrace) 03:35, 5 April 2020 (UTC)

I'm not a web designer, but I'm not sure why it would be too big of a deal. The initial implementation would be a big hurdle but after that, it should be fine, right? Not to mention, if it automatically added the arrows if there were multiple images, we wouldn't have to go through and edit every infobox with multiple images in them. At the very least I'll say if the gallery thing does end up happening, I'd much rather it be a style guide thing than a built-into-the-template thing. -PancakeIdentity (talk) 03:42, 5 April 2020 (UTC)

The other concerns are: 1) someone may (and likely will) need to maintain it in the future, extra complexity = more difficult to maintain; 2) it's possible Fandom/Gamepedia staff restrict how JavaScript works. Currently we can apply any JS to all readers; it's likely we'll at least have our JavaScript edits reviewed for security in the future, and some features may become unavailable in addition to that. For example, Fandom does not currently support any mobile skin customization (including CSS and JS), apparently because it caused some kind of extremely negative technical consequences. It isn't impossible the new platform will retain this restriction. Though very little is actually decided yet, and staff constantly assure us the platform will be as good as possible, and way better than our worst predictions say. --AttemptToCallNil (report bug, view backtrace) 04:39, 5 April 2020 (UTC)

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

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

Proposal: replace pseudo-headings based on definition lists

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

I propose to replace them with actual headers (hidden with depth-limited tables of contents if needed) or, if impossible for some reason, with '''-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 Blobs 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 Blobs 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 Blobs 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 tink that this is more intuitive:

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. --  Lakejason0 (Talk • Contribs) 06:44, 22 April 2020 (UTC)

But it will broke entire page on mobile. --Treeislife2 (talk) 09:55, 22 April 2020 (UTC)

+ It looks like old creative inventory from Minecraft Beta 1.8.1. If small inventory OK, but if this type of inventory, then no. And entire broking page also happen. --Treeislife2 (talk) 09:58, 22 April 2020 (UTC)

Works fine with mobile on Chinese Minecraft Wiki pages. But maybe not all the mobile devices, so maybe we can just hide this thing for mobile devices if necessary. --  Lakejason0 (Talk • Contribs) 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)

Changing gallery functionality

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

On desktop, you can hold ctrl (⌘ Cmd on Mac) when clicking the image, to open in a new tab. On mobile, the image already uses its own interface, and you can tap the X in the top-right corner. The Blobs 00:31, 27 April 2020 (UTC)

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

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

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

Fake webiste found

Hi. I'm bringing to your attention this fake website http://www.finbit.org/Minecraft_Wiki/eAHLKCkpKLbS18_NzEtNLkpMK9FLT8xNLUhNyUzUS87P1feFiceHZ2ZnAgCXuxF4 which is a copy of this wiki. --Treeislife2 (talk) 20:06, 8 May 2020 (UTC)

I reported the site to staff and got a notice that the legal team will be notified. --AttemptToCallNil (report bug, view backtrace) 05:01, 9 May 2020 (UTC)

Handling of Legacy Sprites

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

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

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

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

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

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

The spritesheets are too large so I  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 neccessary 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 spritesheets 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 (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)

Terrible tutorial pages

Let's face it, the tutorial pages are incredebly 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).

 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)

Minecraft Earth and Minecraft Dungeons without "wiki"

Hi.

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

I  Support this thing. --Treeislife2 (talk) 09:56, 19 May 2020 (UTC)

They already have gotten their own namespace... FVbico (talk) 09:59, 19 May 2020 (UTC)

I said Projects 😃 (Minecraft Wiki:Projects/Minecraft Dungeons Wiki, Minecraft Wiki:Projects/Minecraft Earth Wiki moving to Minecraft Wiki:Projects/Minecraft Dungeons, Minecraft Wiki:Projects/Minecraft Earth) --Treeislife2 (talk) 19:10, 19 May 2020 (UTC)

All pages will move the the corresponding namespace; the project pages will be moved out, except the main page, which can probably just be archived instead. FVbico (talk) 19:39, 19 May 2020 (UTC)

Got it. --Minecraft loot (talk) 05:13, 20 May 2020 (UTC)

Done. --Minecraft loot (talk) 05:23, 20 May 2020 (UTC)

The projects aren't finished yet though and archiving a project is not done by clearing the page. The projects shouldn't be archived until they are actually finished. At least the Minecraft Dungeons project is still missing a bunch of pages and both projects need better template support (because namespace) and be reflected on the actual Main Page / get their own main pages.   MarkusRost (talk) 11:36, 20 May 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. -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 discrepencies, 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)

 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 [ ] 23:40, 15 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)

Check all planks and slabs in recipes!

To actually make the whole "Matching/Any Planks" things make sense for the new 1.16 Nether Planks, I have changed Module:Inventory slot/Aliases to reflect the new crafting categories. The new behavior is:

• Matching Planks: Returns both Overworld and Nether variants, the ones you can make wooden tools out of.
• Matching Overworld Planks: Returns only Overworld Planks, the ones you can make boats out of.
• Matching Nether Planks: Returns only Nether Planks, the ones you can't burn.

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

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

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

Dark hydra design in the English Minecraft wiki

Hi folks,

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

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

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

Brewing, smelting, grinding, looming, smithing, stonecutting 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)

Minecraft dungeons is out, but on the latest news it is not there!!! I cannot edit it so I'm hoping someone who reads this can.

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

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

I've added it to the recent news section. The play it section is still WIP on the editcopy so I haven't added that. In the future put this in Talk:Minecraft Wiki, not here.  Nixinova   T   C   00:20, 27 May 2020 (UTC)

Instagram

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

• Why "Instagram"??

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

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

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

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

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

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

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

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

I think that if we are interested in building a non-editor community, Instagram could be a good way to develop that. Otherwise, I'm not sure I see much use for it. No major opposition from me, but I am skeptical that it'd be worth the effort required.

I also think it's worth thinking about this long term. If we start and later abandon the Instagram page, it could very well create a negative impression about the wiki. I know from personal experience that forgotten social media pages can lower interest in a brand/product as it shows a lack of commitment and such. If we did this, we'd have to be in it for the long haul I think.-PancakeIdentity (talk) 07:09, 27 May 2020 (UTC)

The Villager Trading page eliminated the 'Globe Charge' for the Java edition Cartographer - it looks like a mistake

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

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

Refer here:

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

This is backed up elsewhere:

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

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

--

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

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

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

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

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

Bug report

Is this the correct place for bug reports?

1. I'm assuming there was a recent software change. The vector skin is now completely broken.
2. The search suggestions render above the 'User' popup-hover-menu in the top-right.
3. The CodeEditor's syntax highlighting seemingly cannot be enabled for Wikitext.
4. The 'Select files' button in the editing toolbar is inconsistent with the other buttons: wrong colour, and wrong hover effect.

MMK21^ⓉⒸ 12:40, 2 June 2020 (UTC)

Try contacting Game widow. The Blobs 18:53, 2 June 2020 (UTC)

1. I'm not sure what's completely broken? It works fine for me, and given the absence of other reports, the issue may be on your side.
2. Cannot reproduce; see point 1.
3. This is not enabled by default. I don't think it was ever enabled for MCW. However, this feature may be requested.
4. Can reproduce. However, it's a rather minor issue, so may be fixed if someone has the time and wants to help. But it's not a priority.

Are you sure there aren't some custom CSS rules or browser extensions (ad blocker) interfering? Try using a private tab or disabling some extensions briefly. --AttemptToCallNil (report bug, view backtrace) 19:28, 2 June 2020 (UTC)

Can reproduce #1 in a vanilla firefox browser (logged-out): https://cdn.discordapp.com/attachments/569603162739179522/717613049338527844/unknown.png MMK21^ⓉⒸ 05:48, 3 June 2020 (UTC)

Looks like some CSS isn't loading. I tried using a private window, but it loaded for me... --AttemptToCallNil (report bug, view backtrace) 08:34, 3 June 2020 (UTC)

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)

Remove the exclusive template for Minecraft Earth and Dungeons

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

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

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

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

English wiki forum and English wiki server

Hi folks,

I had recently these two ideas:

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

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

Atten007 (talk) 18:08, 12 June 2020 (UTC)

Not sure about that Xobor thing, it throws a security warning when I visit it.

I've been thinking about having a place to talk that is certainly not controlled by Fandom Inc. (The Fandom/Gamepedia server is partnered with Discord, and staff are known to interact with Discord T&S team members, so there are questions as to how far can Fandom staff affect communities on Discord the platform.) But I'm not sure there's actual need or possibility to do it.

There is a Fandom/Gamepedia Minecraft Server with a whitelist. Staff and some global groups can get in, Gamepedia MCW (incl. non-English) admins can get in too. Any editors can also get in, but must be vouched for by a member of some of the former groups. Not sure there's need for a server specifically for the English wiki. --AttemptToCallNil (report bug, view backtrace) 18:49, 12 June 2020 (UTC)

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

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

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

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

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

Deletion of several Tutorials pages

Hello everyone,

I'd like to know if you think these sub-pages of Tutorials should be deleted :

• Tutorials/Airlock : almost completely pointless, the history is mildly active, but nobody has edited this page regularly for years
• Tutorials/Desert shelter : completely pointless, too much specific, almost untouched since its creation
• Tutorials/Pig parking lot : completely pointless, and nobody edited this page for a full year
• Tutorials/How to find caves : information is also in Tutorials/Exploring caverns

Speaking for myself, I  Support these three deletions. Sagessylu (discuss | edits) 12:39, 15 June 2020 (UTC)

 Strong Oppose for removing Tutorials/Airlock,  Support Tutorials/Desert shelter if merged with Tutorials/Shelter types and  Strong Support for removing Tutorials/Pig parking lot --Treeislife2 (talk) 10:32, 17 June 2020 (UTC)

Ok, thanks! Just wondering, why exactly do you oppose for Tutorials/Airlock? Sagessylu (discuss | edits) 17:17, 17 June 2020 (UTC)

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

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

Tagged "Pig parking lot" for deletion, I will do so with "Desert shelter" at some point, when I'll merge it with "Shelter types". I won't do anything with "Airlock" except maybe work on it to make it focus less on those sand staircase things and more on techniques like using doors, because it's quite misleading right now. Sagessylu (discuss | edits) 10:17, 6 July 2020 (UTC)

I agree that the "Pig parking lot" tutorial is useless. I mean, why to build a complicated parking mechanism when you can just use leash and a fence? 193.210.234.8 11:13, 12 July 2020 (UTC)

I also want Tutorials/How to find caves to be deleted, since a section of Tutorials/Exploring caverns provides the same information. Fadyblok240 (talk) 00:13, 14 July 2020 (UTC)

That's right, I added it to the list. Sagessylu (discuss | edits) 15:42, 20 July 2020 (UTC)

Since Tutorials/Redstone machines duplicates the scope of Tutorials/Mechanisms, the former should be deleted, following the movement or deletion of contraptions on a case-by-case basis. –Preceding unsigned comment was added by Fadyblok240 (talk • contribs) at 13:51, 23 July 2020 (UTC). Please sign your posts with ~~~~

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 avaible). 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 formating). --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 uncollapsed 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 uncollapsed by default, and done properly. Sagessylu (discuss | edits) 15:39, 25 June 2020 (UTC)

Old posts

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

223.74.60.202 21:43, 21 June 2020 (UTC)

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

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

Removing videos at the bottoms of pages

At the bottoms of some pages, there are videos talking about the page, which I think should be removed:

• They're usually outdated, with notes above the video saying so.
• In my opinion they don't really explain anything the page doesn't already.
• Many newer pages don't have videos, and might not ever get them, causing inconsistency.

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

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

RfC: appoint a new bureaucrat

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Possible candidates?

I thought I'd go ahead and open up this sub topic. If we add a new bureaucrat, which seems to be where the above discussion is heading, who should it be? AFAIK, standard practice is to choose from current admins (correct me if I'm wrong).

I mentioned my stance above; any of the current admins seem good but one who covers Mad's inactive times would be better probably. If we narrow it down to just a couple and/or a specific user is "nominated", I may give my specific feedback regarding those/that user(s). -PancakeIdentity (talk) 09:31, 8 July 2020 (UTC)

Nixinova. There are many reasons but lets start simple

1. He is an admin (obviously)
2. He has been contuibuting to this wiki for many years and has been an admin for more than a year.
3. He's number 2 in the minecraft wiki, only behind some weird person who does like random edits.
4. He's been playing the game since 1.4.2
5. He owns all the versions of minecraft (including earth and dungeons) except education and discontinued versions
6. Very Knowlegable in minecraft
7. he's never shown any inactivity from the time he regestered his current account
8. so that is why i think he should be bureaucrat.

The Bumblebee 00:47, 15 July 2020 (UTC)

LOLCAT item names

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

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

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

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

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

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

PRO

Since when was i PRO rank here?

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

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

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

Dear "YourName"

Thanks for being an active editor...

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

Latin Minecraft-Wiki

Hi Folks,

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

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

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

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

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

• the Greek translation (13,000,000 native speakers) doesn't even have its main page entirely translated, and if you take a look at some random pages, they are all in English;
• the Turkish translation (75,000,000 native speakers) has redlinks everywhere and looks stuck to the 1.14.4 version on the main page
• the Swedish translation project (10,000,000 native speakers), created in 2011, has 13 translated pages.

So, simply, NO. Sagessylu (discuss | edits) 10:34, 12 July 2020 (UTC)

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

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

Minecraft Update Pictures

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

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

Removal of the Java Edition part on snapshots and Bedrock part for beta.

In the snapshots and betas, the title includes the edition's name (e.g. java edition 20w28a and bedrock edition beta 1.16.20.50). This isn't needed as there are only snapshots in Java and betas in Bedrock. Also, most of the links to the page are just the snapshot and beta part (20w28a and beta 1.16.20.50). The wiki should remove the Java and Bedrock part and just have the name of the snapshot or beta-like the development versions on the left side and the history section on pages. --Minecraft loot (talk) 01:15, 13 July 2020 (UTC)

We had a massive discussion about this last year. It would be incredibly confusing to have to guess what version you're clicking on, and that's hardly future proof, so it's better to just be explicit whenever possible.  Nixinova   T   C   01:26, 13 July 2020 (UTC)

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

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

Translation Wiki

Hi folks,

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

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

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

The Bumblebee 21:53, 16 July 2020 (UTC)

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

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

Add 'See Also' Sections to Pages

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

We actually already do that, see here for more details on what should be included there.--Madminecrafter12 ^{(Talk to me | View what I've done)} 14:00, 17 July 2020 (UTC)

We usually use the {{see also}} template at the top of a page. For example, the Waterlogging page links to Snowlogging. The Blobs 17:36, 19 July 2020 (UTC)

gamepedia migration

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

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

Wait whats the ucp? The Bumblebee 16:05, 20 July 2020 (UTC)

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

oh ok thx The Bumblebee 16:24, 20 July 2020 (UTC)

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

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

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

oh thank you for the info! The Bumblebee 18:57, 20 July 2020 (UTC)

Account weirdness

so i was logged in before the migration, and that account had more than 500 edits. There was no one on fandom with the same username. I was logged out like expected but when i tried to log in using twitch, it failed. 173.56.56.228 13:03, 25 July 2020 (UTC)

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

@ instead of § for specific destinations in a page.

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

Why? I don't feel super strongly, but I think § looks better and I don't see a real reason to change it, so  Oppose for now. -PancakeIdentity (talk) 08:33, 27 July 2020 (UTC)

 Oppose, it's not a sigma, it's a section sign. Is @ ever used for this purpose? --AttemptToCallNil (report bug, view backtrace) 08:34, 27 July 2020 (UTC)

 Oppose @ is mostly used for pinging others, and I don't see why we should change the section sign.--skylord_wars (talk) 10:46, 27 July 2020 (UTC)