Talk: Community portal/Archive 23

Creating empty/contentless pages

Please stop creating new pages that are functionally empty (e.g. they only contain maintenance tags such as {{Stub}} or text such as "Foobar is a block.") Such pages are useless to readers; because links to these pages become blue, readers are misled into thinking there is useful content on these pages. This practice is especially useless if you create a page in this manner and then immediately turn around and edit the page with useful content. If this continues, lI'm going to start handing out blocks over it. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 14:26, 18 April 2018 (UTC)

Yes! Several chemistry-related pages were created in this way, which was bothersome. Others (the 4 utility blocks) were created with useful text, except it was copied directly from the education edition website, which is also not wanted. - Princess Nightmoon (TalkContributions) 15:17, 18 April 2018 (UTC)

I've also noticed this for snapshot pages. For example, there will be a tweet that "a snapshot may come out later today," and somebody will create that as soon as the tweet is posted, with the only content being "Dinnerbone tweeted that a snapshot will come out today." I understand that it's exciting when this happens, but there really is no reason to rush. I have complete trust that editors will create the snapshot page within 5 seconds of its release (I mean, literately).-- Madminecrafter12^{Talk to me} 15:22, 18 April 2018 (UTC)

Yeah, this is a problem I've noticed happening for a while. The creation of contentless stubs for the various Classic versions is what finally spurred me to comment on it, though. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 15:24, 18 April 2018 (UTC)

I'd say there are two cases here. One would be creating the articles, and marking them all as {{In use}} so that two people don't work on making it at the same time. In my opinion, that's fine (though the template should probably be used for that case). Another would be just creating an article where the subject doesn't even exist yet (e.g. future snapshots) and the article couldn't be written. That's a case where I would say it's a problem. --Pokechu22 (talk) 16:16, 18 April 2018 (UTC)

If someone wants to work on an article like that, they need to do it in their userspace and then move it to the mainspace when it's ready to go. Trying to prevent duplication of effort is not a valid reason to create empty/contentless pages. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 23:26, 18 April 2018 (UTC)

MinecraftPhotos4U, please read this section, and note that in the future, reverting edits that change empty/contentless pages to redirects will result in a block. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 23:26, 18 April 2018 (UTC)

After checking those edits, I was mistaken about what you did. However, in the future if you properly create a page from an edit revert, please replace or delete the edit summary before saving so your edit isn't listed as a revert in the page history. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 23:32, 18 April 2018 (UTC)

Play dashtm, please read this section. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 22:31, 23 April 2018 (UTC)

So, what is the community consensus here? Should we not create snapshot pages until they have been released unless there is significant coverage over the features that will be added in a source? Jjlrjjlr created 18w19a before it was released, and MinecraftPhotos4U created 18w19b, as it's expected to be released tomorrow (both of these users did it out of good faith). Whatever decision we make should probably be mentioned in the style guide. I personally like the idea of not creating any unreleased snapshot pages unless several of their features are mentioned in a source (kind of like how it currently is with version releases), but I'm open to anything. What do the rest of you think?-- Madminecrafter12^{Talk to me} 00:45, 9 May 2018 (UTC)

This isn't about creating pages for announced versions before their release (which is fine), it's about creating empty or contentless (e.g. the only content is something like {{stub}}) pages. As long as something useful can be (and is) said in the article, it can (and should) be created. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 19:49, 16 May 2018 (UTC)

So if I understand correctly, it's fine to create (snapshot) pages (before they are released yet), if it is done with useful content in the first edit. So if you'd be filling in more content later, hold off clicking the submit button before you do. Fair enough, right? – Jack McKalling [ ] 19:58, 16 May 2018 (UTC)

Yes, that's it exactly. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 20:00, 16 May 2018 (UTC)

Well, we could enforce this with a message (box) in the editintro, add a formal note to the already mentioned style guide, or a step further, insert a minimum data requirement to the editor (there must be some mechanic for something like that somewhere). Because I'm sure people new to this discussion are probably not going to read this before they make the same mistake others have already. These are just the tools I can think of to help, do we need any of that? – Jack McKalling [ ] 20:07, 16 May 2018 (UTC)

Adding a note to the style guide (or some other place where it's clear this is a wiki guideline/policy) would be ideal. An abuse filter rule can be created to catch some cases of this as well, but I don't think this problem is widespread enough to justify that (though if someone who knows their way around writing abuse filter rules wants to write one, I'd have no problem adding it; email it to me in that case). Adding an editnotice wouldn't be appropriate for this, because page creations are a very low proportion of edits, and AFAIK there's no real way to selectively display an editnotice specifically on page creation. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 20:16, 16 May 2018 (UTC)

Regarding the editnotice, wouldn't it work to just put {{#ifexist:{{FULLPAGENAME}}|| page creation notice }} in it? Interested to know if it would. And if that doesn't work, you could also try checking a variable inserted by Mediawiki:Newarticletext. The parser function failed for me, but I can't truly test it in system messages like that. So all right, lets focus on the style guide then. What about adding another phrase to Notability.General.1, so it would read for instance "Articles must contain enough information to warrant a full page. If they do not have enough content, they should be merged with other similar articles. Creating an empty page to add content to it later, is not allowed." Any thoughts? – Jack McKalling [ ] 20:50, 16 May 2018 (UTC)

 Unnecessary There is a separate message that occurs when creating a page. I do not know the name, but it currently starts with “You have followed a link to a page that does not exist yet”. Additionally, the message would be useful for all namespaces except user. Therefore, we should use {{#ifeq:{{NAMESPACE}}|user||[message box]}}. It would generalize the message to an indication that placeholder pages should only be created in the userspace. The Blobs 23:21, 16 May 2018 (UTC)

System message newarticletext controls this message, so creating such a notice is possible. Not sure how useful the abuse filter would be in this case: many placeholder pages are created with infoboxes, navboxes, etc., so filtering on page length wouldn't necessarily work. A filter to prevent creating any page less than 16 bytes might stop some blank or nearly-blank pages while still allowing redirects, but could be bypassed with an empty section header and a navbox. -- Orthotope^talk 03:17, 17 May 2018 (UTC)

Of course we could just use newarticletext, I had already linked to it above, but this system message is NOT visible during preview. Does that matter here? So no adjusting the abuse filter. Also agreed the message box could be shown on more namespaces than just the mainspace. And as an example implementation of the message box, would this suffice?

I just used the same sentence as I suggested for the style guide. – Jack McKalling [ ] 08:54, 24 May 2018 (UTC)

Next time, if you are writing something that is a stub and/or not completed yet, press the "Save draft" button instead of the "Save changes" button. You can come back to work by accessing the Special:Drafts page. Leduyquang753 (talk) 00:34, 24 June 2018 (UTC)

Update Videos (up)

Are you guys still ok with this? Hugman_76 [ ] 14:39, 22 April 2018 (UTC)

I personally am fine with it, and it seems like many other users are too. Dinoguy1000, Orthotope? Would you be okay with doing this?-- Madminecrafter12^{Talk to me} 14:51, 22 April 2018 (UTC)

I'm fine with whatever the community consensus is. (Personally, I'd rather read a well-written article than watch a video, but that's mostly because I can read a lot faster than most people talk.) However, as Dinoguy repeatedly mentioned, we need a list of Mojang/developer channels to add to the video policy before this can be implemented. -- Orthotope^talk 16:43, 22 April 2018 (UTC)

Currently, there are only Help:Official sources#Video hosting services.The only YouTube channel there is TeamMojang. We should start making a section about official YouTube accounts other than Mojang's.--Skylord wars (talk) 01:06, 23 April 2018 (UTC)

I've saw that slicelime was added, could we start now? Or do we need another seperate page Orthotope? Hugman_76 [ ] 18:54, 23 April 2018 (UTC)

The help page is probably the ideal location for the list to go, and the video policy should be updated to point to it instead of maintaining a separate list. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 22:03, 23 April 2018 (UTC)

Alright, can we start now Dinoguy1000, Orthotope, Skylord wars, Madminecrafter12? Hugman_76 [ ] 15:10, 30 April 2018 (UTC)

Works for me, especially because it's now been added to the Help:Official sources page. However, should we update the video policy page as well before we do this?-- Madminecrafter12^{Talk to me} 15:22, 30 April 2018 (UTC)

The Minecraft Wiki:Wiki rules/Video policy can be easily changed, as it's copied from Terraria wiki. Minecraft Wiki can set up their own rules. The video policy should be updated. Skylord wars (talk) 15:33, 30 April 2018 (UTC)

I don't know how to do it, can someone do it? Hugman_76 [ ] 21:38, 1 May 2018 (UTC)

Only admins can edit the page, and none of the admins you've pinged have replied yet. I guess we can wait a week or so, and then I'll try contacting one of the active admins directly.-- Madminecrafter12^{Talk to me} 21:43, 1 May 2018 (UTC)

I've made the change, though I welcome suggestions for improvements to the text there (not just my text, but any of the text on the page, most of which I didn't look very closely at while editing). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:35, 2 May 2018 (UTC)

So, may we start adding update videos by slicedlime? Dinoguy1000?-- Madminecrafter12^{Talk to me} 02:39, 6 May 2018 (UTC)

I think so, I'm going to start, a template is available here. Hugman_76 [ ] 17:22, 9 May 2018 (UTC)

 Question So to clarify, it is ok to start adding slicedlime videos to update pages now? jjlr (talk) 05:49, 10 May 2018 (UTC)

Yes! Make sure to all follow the same template (which can be found on 'Category:Update_videos' too) to not be confused. Hugman_76 [ ] 08:38, 10 May 2018 (UTC)

You can't use subpage transclusion as the snapshot pages are transcluded on the development versions subpages, which points the video transclusion to a subpage of that page, which obviously doesn't exist. –Majr ᐸ Talk
Contribs 10:17, 10 May 2018 (UTC)

{{/Update_Video}}

doesn't work, but

{{:{{subst:PAGENAME}}/Update_Video}}

fixes the issue. Applied fix to existing pages and altered the instructions on the category page. - Princess Nightmoon (TalkContributions) 12:58, 10 May 2018 (UTC)

@Princessnightmoon: That's strange how it doesn't work for you. It should work, and it does work just fine for me. So when you access this revision of 18w16a, the video does not show up? (That revision is before you added the extra :18w16a) Oh wait, I'm sorry, never mind - it's for the development versions that is doesn't show up, I should have read Majr's comment more thoroughly.-- Madminecrafter12^{Talk to me} 13:06, 10 May 2018 (UTC)

Bedrock Beta versions

So, ever since the 1.2.13 betas, the version numbers have gotten pretty weird, and at the top of the weirdness is the recent Beta 1.5.0.0, the ninth beta version leading up to full version 1.4. Attempted breakdown as follows (numbers in brackets are full version numbers):

Full Version	Beta Builds	Update Aquatic
1.2.13 (1.2.13.54)	1.2.13.5	N/A
	1.2.13.6	N/A
	1.2.13.8	Build 1
	1.2.13.10	Build 2
	1.2.13.11	Build 3
	1.2.13.12	Build 4
1.2.14 (iOS)	1.2.14.2	Build 5
	1.2.14.3	Build 6
1.2.15 (iOS) (1.2.15.01)	N/A	N/A
1.2.16 (iOS) (1.2.16.3) Non-iOS: 1.2.13.60	N/A	N/A
Future Versions	1.2.20.1	Build 7
	1.2.20.2	Build 8
	1.5.0.0	Build 9

Now, the article for Beta 1.5.0.0 is currently called "1.4 build 10", which is false, since it's the 9th build for 1.4 (Update Aquatic). And unlike previous numbers, it doesn't make sense for it to be "1.5 build 1", since it's not a build for 1.5. So, should it just be called "Beta 1.5.0.0"? Should the naming system be changed for the beta versions? I'm not really sure what to do here. - Princess Nightmoon (TalkContributions) 21:05, 26 April 2018 (UTC)

To be honest I have no idea what to do, I've been wondering the same thing! For 1.2.14, builds for it added update Aquatic features, but then the iOS release of it only had bug fixes. Also, the order of the builds doesn't make sense at all, and it seems like some of the Wiki, such as the bedrock Edition version template, regards all of the builds as "1.4." Anybody else have any ideas?-- Madminecrafter12^{Talk to me} 21:14, 26 April 2018 (UTC)

Yeah, out of the beta versions listed, only 1.2.13.5-6 have actually been related to the version number. 1.2.13.8 and later have all been Update Aquatic betas, with no correlation to the full versions 1.2.13 or 1.2.14 despite sharing version numbers. As briefly touched upon, naming them "Beta [number]" could be a potential solution for the 9 builds in question, but it would need consensus. - Princess Nightmoon (TalkContributions) 21:33, 26 April 2018 (UTC)

Looks like it's better if we named the version articles like "Beta [version number]". I'd consider "Update Aquatic Build [N]", but build numbers seem unreliable, judging by the 9/10 confusion, and this naming method will fail if the builds for the next major update become similarly confusingly versioned before the update's name is announced. If things get worse, we may have to resort to version release dates... but then again, nothing prevents the developers from "accidentally" releasing two or more updates on the same day in an ambiguous order. --AttemptToCallNil (report bug, view backtrace) 10:33, 27 April 2018 (UTC)

My suggestion is "Bedrock Edition Beta 1.2.6" for Bedrock Edition 1.2.6 build 1. Using this way will prevent confusion and make it a lot easier. We don't need to version numbers and update names. This is to keep consistent with Java Edition's snapshots articles. The name does not have the update name. Plus, builds are names used by Android betas only, Mojang uses the term Beta instead of builds.--Skylord wars (talk) 11:33, 27 April 2018 (UTC)

This is going to be confusing with the way we've historically treated the terms alpha/beta: as being an entire set of versions that come prior to the initial 1.0 release (just look at how {{history}} is organised). You might expect that BE Alpha 1.0 precedes BE Beta 1.1, but there's actually release versions in between. If we do this, we're going to have to make sure the infobox clearly differentiates between pre-release alpha versions, and mid-release beta versions. –Majr ᐸ Talk
Contribs 11:49, 27 April 2018 (UTC)

Well, that only applies to Java. While it might be confusing, it is accurate; Bedrock Edition uses Beta versions as their equivalent of Java snapshots (as of Beta 1.2.13.8), introducing experimental features which may or may not be included in the full version. Display methods in templates could be as follows:

Infobox (Beta 1.5.0.0)
"Type" indicates that it's a beta (snapshot) version, "Beta version for" indicates which version it's a beta for.

Beta 1.5.0.0
Edition	Bedrock Edition
Release date	Xbox One, Windows 10, Android - April 25, 2018
Protocol version	Pending

History (dolphin)
For this one, "beta [version number]" is used in the same way as snapshots, being listed under the upcoming version they are a beta for.

Java Edition
November 18, 2017					Dolphins were shown in a video clip during MineCon Earth
Upcoming Java Edition
1.13 {{Extension DPL}}<ul><li>[[Bowl|Bowl]]<br/>{{Item | image = Bowl.png‎ | renewable = Yes | stackable = Yes (64) }} '''Bowls''' are containers that can hold certain [[food]]s. == Obtaining == === Crafting === {{Crafting |A2= Any Planks |C2= Any Planks |B3= Any Planks |Output= Bowl,4 |type= Material }} === Fishing === Bowls can be obtained as a "junk" item while [[fishing]]. === Eating === A bowl containing food becomes an empty bowl when the food is eaten. === Mob loot === When a [[turtle]] is killed by a [[Thunderstorm#Lightning|lightning bolt]], it drops 1 bowl.<ref name=BowlReport>{{Cite bug|MC|125562|Turtles drop bowls when killed by lightning|date=February 16, 2018}}</ref><ref>{{Cite bug|MCPE|57038| Turtles killed by lightning drop Bowls.|date=November 17, 2019}}</ref> == Usage == === Crafting ingredient === {{crafting usage}} === Mooshrooms === {{control|use|text=Using}} a bowl on a [[mooshroom]] turns the bowl into [[mushroom stew]] or [[suspicious stew]]. The stew can then be consumed immediately and the process repeated, making this an excellent way to quickly restore depleted [[hunger]] and [[saturation]] with almost no cost or effort. === Fuel === Bowls can be used as a fuel in [[furnace]]s, smelting 0.5 items per bowl {{in|je}}, and 1 item per bowl {{in|be}}. == Data values == === ID === {{edition|java}}: {{ID table |edition=java |showforms=y |generatetranslationkeys=y |displayname=Bowl |spritetype=item |nameid=bowl |form=item |foot=1}} {{edition|bedrock}}: {{ID table |edition=bedrock |shownumericids=y |showforms=y |notshowbeitemforms=y |generatetranslationkeys=y |displayname=Bowl |spritetype=item |nameid=bowl |id=321 |form=item |foot=1}} == History == {{History|java indev}} {{History||0.31|snap=20100130|[[File:Bowl JE1 BE1.png|32px]] Added bowls. |Bowls are used to craft [[mushroom soup]].}} {{History|java}} {{History||1.0.0|snap=Beta 1.9 Prerelease|Added [[mooshroom]]s, which can be {{control|use|text=milked}} with a bowl.}} {{History||1.2.4|snap=release|[[Spruce planks]], [[birch planks]], and [[jungle planks]] can now be used to craft bowls.}} {{History||1.7.2|snap=13w36a|Bowls can now be obtained as one of the "junk" [[item]]s by [[fishing]].}} {{History|||snap=1.7.1|[[Acacia planks]] and [[dark oak planks]] can now be used to craft bowls.}} {{History||1.8|snap=14w27a|Bowls are now used to craft [[rabbit stew]].}} {{History||1.9|snap=15w31a|Bowls are now used to craft [[beetroot soup]].}} {{History||1.11|snap=16w33a|Bowls can now be used to fuel [[furnace]]s.}} {{History||1.13|snap=17w47a|Prior to [[1.13/Flattening|''The Flattening'']], this [[item]]'s numeral ID was 281.}} {{History|||snap=18w07a|[[Turtles]] drop 0 to 1 bowls if killed by [[lightning]].<ref name=BowlReport/>}} {{History||1.14|snap=18w43a|[[File:Bowl JE2 BE2.png|32px]] The texture of bowls has now been changed. |Bowls are now used to craft [[suspicious stew]].}} {{History||1.16|snap=20w06a|[[Crimson planks]] and [[warped planks]] can now be used to craft bowls.}} {{History||1.19|snap=22w11a|[[Mangrove planks]] can now be used to craft bowls.}} {{History|pocket alpha}} {{History||v0.2.0|[[File:Bowl JE1 BE1.png|32px]] Added bowls. They are currently unobtainable and serve no purpose.}} {{History||v0.3.0|Bowls are now [[craft]]able. They still serve no purpose.}} {{History||v0.4.0|Bowls are now used to craft [[mushroom stew]].}} {{History||v0.5.0|Bowls now appear in the [[nether reactor]].}} {{History||v0.8.0|snap=build 2|Bowls are now used to craft [[beetroot soup]].}} {{History|||snap=build 7|Bowls can now be used as fuel in a [[furnace]].}} {{History||v0.9.0|snap=build 1|Added bowls to [[creative]] mode. |[[Mooshroom]]s can now be "milked" to obtain [[mushroom stew]].}} {{History||v0.12.1|snap=build 1|Bowls are no longer available from the [[nether reactor]].}} {{History||v0.13.0|snap=build 1|Bowls are now used to craft [[rabbit stew]].}} {{History|bedrock}} {{History||1.10.0|snap=beta 1.10.0.3|[[File:Bowl JE2 BE2.png|32px]] The texture of bowls has now been changed.}} {{History||1.13.0|snap=beta 1.13.0.9|Bowls can now be used to craft [[suspicious stew]].}} {{History|console}} {{History||xbox=TU1|xbone=CU1|ps=1.0|wiiu=Patch 1|switch=1.0.1|[[File:Bowl JE1 BE1.png|32px]] Added bowls.}} {{History||xbox=TU9|Bowls now stack to 64.}} {{History||xbox=none|xbone=none|ps=1.90|wiiu=none|switch=none|[[File:Bowl JE2 BE2.png|32px]] The texture of bowls has now been changed.}} {{History|new 3ds}} {{History||0.1.0|[[File:Bowl JE1 BE1.png|32px]] Added bowls.}} {{History|foot}} == Issues == {{issue list}} == Trivia == * {{in|be}}, bowls are actually more fuel efficient than [[stick]]s. If 6 wood planks are crafted into 8 bowls, 8 items can be [[smelt]]ed; but if those are crafted into 12 sticks, only 6 items can be smelted. This can be useful when the player only has access to Nether wood types, which cannot be used as fuel. == See also == * [[Mushrooms]] == References == {{reflist}} == External Links == * {{Mcnet|taking-inventory--bowl|Taking Inventory: Bowl|April 25, 2019}} {{Items}} [[Category:Renewable resources]] [[cs:Miska]] [[de:Schüssel]] [[es:Cuenco]] [[fr:Bol]] [[hu:Tál]] [[it:Ciotola]] [[ja:ボウル]] [[ko:그릇]] [[nl:Kom]] [[pl:Miska]] [[pt:Tigela]] [[ru:Миска]] [[th:ชาม]] [[uk:Миска]] [[zh:碗]]</li><li>[[Name Tag|Name Tag]]<br/>{{about|the item that gives names to mobs|the nameplate above a player's head|Player#Username}} {{Item | image = Name Tag.png | renewable = Yes | stackable = Yes (64) }} A '''name tag''' is an [[item]] used to name [[mob]]s in the world and prevent them from despawning naturally. == Obtaining == === Chest loot === {{LootChestItem|name-tag}} === Fishing === Name tags can be caught from [[fishing]] as part of the treasure category with a {{frac|1|6}} chance after the 5% chance of being a treasure catch. The chance of catching treasure increases with the [[Luck of the Sea]] enchantment. === Trading === Master-level librarian [[villagers]] offer to sell a name tag for 20 [[emerald]]s as one of their available trades. == Usage == To use a name tag, it must first be renamed with an [[anvil]], costing 1 [[experience]] level. If it is not renamed, it has no effect when used on a mob. After the name tag is renamed, the player can {{control|use}} it on a mob to give it the name given to the name tag from the anvil. Mobs and name tags can be renamed any number of times. Name tags with the same name are stackable. Once a mob is named, it keeps its name, and the name tag is consumed. When a mob is named, it is excluded from the mob cap count. Effects on various mobs: * A named [[silverfish]] that goes into a block appears to lose its name because it is replaced by a newly generated unnamed silverfish when the block is broken. * A baby (animal or villager) keeps its name when becoming an adult. ** A named [[villager]] keeps its name when transformed into a [[Zombie Villager|zombie villager]]. ** A named zombie villager keeps its name when cured. * [[Wandering Trader|Wandering trader]]s still despawn even if they are named, or in a [[minecart]] or [[boat]]. * A named [[wither]]'s boss bar displays its name instead of "Wither". * Naming an [[ender dragon]] with commands also displays the name in the boss bar. === Limitations === Any mob can be named except for the [[ender dragon]] and [[player]]s. A name tag can rename an [[armor stand]], though it does not show the nameplate above its head until <code>CustomNameVisible:1b</code> is set as an extra step. {{control|Using|use}} a name tag on a villager renames the villager instead of opening the trading interface. A saddled pig is renamed instead of being ridden. Using a name tag on any other mob that can be interacted with performs the {{control|use}} action instead of being named. These mobs can be renamed if the player uses the name tag while crouching or standing in a [[nether portal]] because the portal suppresses the {{control|use}} action. Once a name tag is used on a mob, it is impossible to remove the name of that mob without the use of commands or external modifications. === Behavior === Renamed mobs have their name displayed over their head in the same fashion as a mob named through a renamed [[spawn egg]]. Their names can be seen only if they are aimed at from four or fewer blocks away. Mobs that are named using the name tag never despawn in the world, similar to tamed mobs.<ref>{{tweet|dinnerbone|327485109940916226}}</ref> The exceptions are [[wandering trader]]s or if the mob is hostile and the difficulty is switched to "[[Peaceful]]", causing any hostile mobs or any named hostile mobs to despawn immediately. If a renamed mob kills a player, the custom name is used in the death message in place of the mob type name. For instance, if a vindicator named "Johnny" kills a player, the death message is "Player was slain by Johnny". A renamed [[wither]] also has a renamed health bar, and the boss bar doesn't regenerate{{verify}}. === Easter eggs === * Any mob that receives the name "[[Easter eggs#Upside-down mobs|Dinnerbone]]" or "[[Easter eggs#Upside-down mobs|Grumm]]" is rendered upside down. This even includes the player in early versions of Bedrock Edition if the username is set to either of these and you are not signed into Xbox Live. * Naming a [[sheep]] "[[Easter eggs#Jeb sheep|jeb_]]" causes its wool to fade between the dye colors, producing a rainbow effect. The [[wool]] that drops when the sheep is [[shear]]ed or killed is the original color of the sheep before the sheep was named. * Naming a [[rabbit]] "[[Rabbit#Toast|Toast]]" causes it to have a special memorial skin of user xyzen420's girlfriend's [http://www.reddit.com/r/minecraftsuggestions/comments/27hjog/to_themogminer_my_bunny_is_missing_please_help_me/ missing rabbit]. * Naming a [[vindicator]] "Johnny" causes it to be aggressive and attack all [[mob]]s including the wither (except [[ghast]]s and other [[illager]]s). The hostility even extends to [[Ravager|ravagers]] in [[Java Edition|''Java Edition'']], as the "Johnny" vindicator can also attack the ravager while it's riding it. == Data values == === ID === {{edition|java}}: {{ID table |edition=java |showforms=y |generatetranslationkeys=y |displayname=Name Tag |spritetype=item |nameid=name_tag |form=item |foot=1}} {{edition|bedrock}}: {{ID table |edition=bedrock |shownumericids=y |showforms=y |notshowbeitemforms=y |generatetranslationkeys=y |displayname=Name Tag |spritetype=item |nameid=name_tag |id=548 |form=item |foot=1}} == History == {{History|java}} {{History||1.6.1|snap=13w16b|[[File:Name Tag JE1 BE1.png|32px]] Added name tags. They can now be found in [[dungeon]] [[chest]]s.}} {{History|||snap=13w25a|A [[mob]] named "Dinnerbone" or "Grumm" now renders upside down.}} {{History||1.7.2|snap=13w36a|Name tags can now rarely be acquired by [[fishing]], making them [[renewable resource|renewable]].}} {{History||1.7.4|snap=13w48b|A sheep named "jeb_" now fades between the [[dye]] colors.}} {{History||1.8|snap=14w02a|Name tags can now be [[trading|bought]] from librarian [[villager]]s, at 20–22 [[emerald]]s for 1 name tag.}} {{History|||snap=14w27a|[[Rabbit]]s have been added and naming one "Toast" gives it a special memorial skin.}} {{History||1.9|snap=15w44a|Added name tags to [[mineshaft]] [[chest]]s. |The average yield of name tags in [[dungeon]] chests has been decreased.}} {{History||1.11|snap=16w39a|Name tags can now be found in the new [[woodland mansion]] chests. |Added [[vindicator]]s, which attack almost all mobs if named "Johnny".}} {{History||1.13|snap=17w47a|Prior to [[1.13/Flattening|''The Flattening'']], this [[item]]'s numeral ID was 421.}} {{History||1.14|snap=18w43a|[[File:Name Tag JE2 BE2.png|32px]] The texture of name tags has been changed.}} {{History||1.19|snap=Deep Dark Experimental Snapshot 1|Name tags now generate in [[ancient city]] chests.}} {{History|pocket alpha}} {{History||v0.15.0|snap=build 1|[[File:Name Tag JE1 BE1.png|32px]] Added name tags, and a new "Name" Interact button. |A [[mob]] named "Dinnerbone" or "Grumm" renders upside down. |A [[sheep]] named "jeb_" fades between the [[dye]] colors. |Naming a [[rabbit]] "Toast" gives it a special memorial skin.}} {{History|pocket}} {{History||1.0.4|snap=alpha 1.0.4.0|Name tags can now be [[trading|bought]] from librarian [[villager]]s for 20-22 [[emerald]]s as their last tier trade.}} {{History||1.1.0|snap=alpha 1.1.0.0|Naming a [[vindicator]] "Johnny" now makes it hostile to any [[mob]], except other [[illager]]s. |Name tags can now be found in [[woodland mansion]]s.}} {{History|bedrock}} {{History||1.4.0|snap=beta 1.2.14.2|Name tags can now be found in buried treasure [[chest]]s.}} {{History||1.10.0|snap=beta 1.10.0.3|[[File:Name Tag JE2 BE2.png|32px]] The texture of name tags has been changed.}} {{History||1.11.0|snap=beta 1.11.0.4|Name tags [[trading|sold]] by librarian [[villager]]s now cost 20 [[emerald]]s.}} {{History|console}} {{History||xbox=TU19|xbone=CU7|ps=1.12|wiiu=Patch 1|[[File:Name Tag JE1 BE1.png|32px]] Added name tags.}} {{History|PS4}} {{History||1.90|[[File:Name Tag JE2 BE2.png|32px]] The texture of name tags has been changed.}} {{History|3ds}} {{History||0.1.0|[[File:Name Tag JE1 BE1.png|32px]] Added name tags.}} {{History|foot}} == Issues == {{issue list}} == Trivia == * Name tags were added at the request of [https://www.youtube.com/user/paulsoaresjr/ Paulsoaresjr].<ref>{{tweet|paulsoaresjr|326865482839883777}}</ref><ref>{{tweet|Dinnerbone|326812168630722561}}</ref> * A stack of up to 64 name tags can be renamed at once. The cost is 1 [[experience]] level per stack, regardless of how many name tags were stacked. * To name a [[mob]] “Name Tag” the player must give the name tag a random name, then rename it back to “Name Tag”. * A [[villager]] with a name tag turned into a [[zombie villager]] by a [[zombie]] with a name tag does not despawn, but a villager with a name tag turned into a zombie by a zombie without a name tag does despawn. * It is impossible to have a rainbow [[sheep]] upside-down, because it is impossible for it to be named “Jeb_” and “Dinnerbone” at the same time. == Gallery == <gallery> NameTag2.png|To use a name tag, the [[player]] must first rename it using an [[anvil]]. NameTag1.png|A [[wolf]] that has been renamed using a name tag. RenamedCreeper.png|A [[creeper]] renamed using the name tag. RenamedWither.png|A [[Wither Boss|wither]] renamed using a name tag. The custom name takes place of "Wither" over the [[health bar]] as well. YoYo.png|How to use "Grumm" and "Dinnerbone" name tag [[easter egg]] and [[lead]] to make another animal Yo-yo. Grumm Horse.png|A [[horse]] using the "Grumm" or "Dinnerbone" easter egg to be rendered upside-down. MineshaftNameTag.png|Name Tag found in a mineshaft chest. Pocket Edition Name Tag.jpg|First image of a name tag in bedrock edition. </gallery> == See also == * [[Spawn Egg]] == References == {{reflist}} == External Links == *[https://www.minecraft.net/en-us/article/taking-inventory--name-tag Taking Inventory: Name Tag] – Minecraft.net on March 15, 2019 {{items}} [[de:Namensschild]] [[es:Etiqueta]] [[fr:Étiquette]] [[it:Targhetta]] [[ja:名札]] [[ko:이름표]] [[nl:Naamkaartje]] [[pl:Znacznik]] [[pt:Etiqueta]] [[ru:Бирка]] [[zh:命名牌]] [[Category:Renewable resources]]</li></ul>		18w15a			Added dolphins.
Upcoming Bedrock Edition
1.4 {{Extension DPL}}<ul><li>[[Drinks|Drinks]]<br/>[[File:Drinking Steve.png|150px|right]] [[File:Drinking Alex.png|150px|right]] '''Drinks''' are a narrow class of consumable [[item]]s that can be ingested by the [[player]] in an extremely similar manner to [[food]]. However, drinks are not encountered quite as commonly as food is, and they are not nearly as integral to Survival gameplay. Drinks can generally be distinguished from food by the sounds they make upon consumption, the lack of [[particles]] they emit, and the fact that they leave an empty container item in the [[inventory]] after consumption. Drinks do not affect [[hunger]] or saturation values upon use (with the exception of [[honey bottle]]s), and do not need those values to be depleted in order to be consumed. Drinks are drunk by holding {{control|use item}} while having the drink item selected in the hotbar or in the off hand. == Drinks == {{/table}} == History == {{main|Milk#History|Potion#History|Honey Bottle#History}} {{History|java alpha}} {{History||v1.0.11|[[File:Milk Bucket JE1 BE1.png|32px]] Added milk.}} {{History|java}} {{History||1.0.0|snap=Beta 1.9 Prerelease 3|Added water bottles and potions.}} {{History||1.15|snap=19w34a|[[File:Honey Bottle JE1.png|32px]] Added honey bottles.}} {{History|pocket alpha}} {{History||v0.7.0|[[File:Milk Bucket JE1 BE1.png|32px]] Added milk buckets.}} {{History||v0.12.1|snap=build 1|Added water bottles and potions.}} {{History|bedrock}} {{History||1.14.0|snap=beta 1.14.0.1|[[File:Honey Bottle BE1.png|32px]] Added honey bottles.}} {{History|foot}} {{Items}} [[ja:飲み物]] [[pt:Bebidas]] [[Category:Food]]</li><li>[[Eye of Ender|Eye of Ender]]<br/>{{redirect|Ender Eye|the boss|Ender Dragon|item that teleports the player to where it lands|Ender Pearl}} {{ItemEntity |image=Eye of Ender.png |stackable=Yes (64) |renewable=Yes |size=Height: 0.25 Blocks<br>Width: 0.25 Blocks |networkid='''[[JE]]''': 72 }} An '''eye of ender''' is a craftable item used to locate [[stronghold]]s and activate the [[end portal]]s within them. == Obtaining == === Crafting === {{Crafting |Blaze Powder |Ender Pearl |Output=Eye of Ender |type=Miscellaneous }} == Usage == === Locating strongholds === [[File:Eye of Ender (break).gif|thumb|right|An animation of an eye of ender shattering.]] To locate [[stronghold]]s (and the [[end portal]]s they house): * Pressing {{control|use}} while holding an eye of ender causes it to fly approximately 12 blocks in the direction of the nearest stronghold, traveling through any blocks necessary, and leave a trail of purple particles, the same particle effect used for [[endermen]] and [[ender chests]]. ** The eye leads to the [[chunk]] where a spiral staircase, the first room generated in the stronghold, is located. ** The center of this entrance staircase is always exactly at the chunk coordinates 4, ~, 4, although the eye of ender leads to chunk coordinates 0, ~, 0 (the northwest corner of the chunk). * While over 12 blocks away from the northwest corner of the staircase chunk, the eye will travel upward to offer an easily-visible indication of the horizontal direction the player must travel. * When closer than 12 blocks to the northwest corner of the staircase chunk, the eye will travel downward, to indicate the player is above a stronghold and must mine downward. * After two or three seconds of travel, the eye floats in the air briefly, then either falls (becoming collectable again) or shatters in mid-air. The eye has a 20% chance of shattering (80% chance of surviving) per throw, therefore throwing it three times has approximately 50% overall chance to shatter the eye (0.8<sup>3</sup>=51.2%). * The eye of ender's flying function works only in the [[Overworld]]. It does nothing in [[the Nether]], [[the End]], [[custom dimension]]s{{verify|type=current}}, or in worlds with no strongholds. Note that the eyes may point to an incorrect location if the target chunks were generated with a different biomes map in an older version or through different generation settings.<ref>See also {{bug|MC-135996}}</ref> === Activating end portals === [[File:Active End Portal.png|thumb|right|An end portal activated with eyes of ender.]] Once an end portal is found, the eyes of ender are required to activate it. End portals require a total of 12 eyes of ender in order to activate, though each individual frame-block has a 10% chance of containing an eye of ender when generated. Eyes can be placed in empty [[End portal frame]]s by pressing {{control|use}} on them until the entire ring of 12 is filled, thereby activating the portal. Due to the fact that there is a 10% chance of each individual end portal frame having an eye in it, there is a one out of one trillion chance of every frame having an eye in it thereby activating the portal even if the player doesn't have any eyes of ender. {| class="wikitable sortable mw-collapsible" |+End Portal Pre-Filled Eyes !Eyes !0 !1 !2 !3 !4 !5-12 |- |Exactly |28% |38% |23% |9% |2% |<1% |- |Or More |100% |72% |34% |11% |3% |<1% |} === Crafting ingredient === {{crafting usage}} == Sounds == {{Edition|Java}}:<br> Eyes of ender use the Friendly Creatures sound category for entity-dependent sound events. {{Sound table |sound=Ender Eye death1.ogg |sound2=Ender Eye death2.ogg |subtitle=Eye of Ender falls <ref group=sound name=LousyEvents>{{Bug|MC-98316||Wrong subtitles caused by missing distinction}}</ref> |source=neutral |description=When an eye of ender drops or breaks |id=entity.ender_eye.death|idnote=<ref group=sound name=LousyEvents/> |translationkey=subtitles.entity.ender_eye.death|translationkeynote=<ref group=sound name=LousyEvents/> |volume=1.3 |pitch=1.0 |distance=16}} {{Sound table |sound=Ender Eye launch1.ogg |sound2=Ender Eye launch2.ogg |subtitle=Eye of Ender shoots |source=neutral |description=When an eye of ender is thrown |id=entity.ender_eye.launch |translationkey=subtitles.entity.ender_eye.launch |volume=0.5 |pitch={{frac|1|3}}-0.5 |distance=16}} {{Sound table |sound=End portal eye place1.ogg |sound2=End portal eye place2.ogg |sound3=End portal eye place3.ogg |subtitle=Eye of Ender attaches |source=block |description=When an eye of ender is placed in an end portal frame |id=block.end_portal_frame.fill |translationkey=subtitles.block.end_portal_frame.fill |volume=1.0 |pitch=1.0 |distance=16 |foot=1}} {{Edition|Bedrock}}: {{Sound table |type=bedrock |sound=Item Frame break1.ogg |sound2=Item Frame break2.ogg |sound3=Item Frame break3.ogg |source=block |description=When an eye of ender breaks <ref group=sound>{{Bug|MCPE-115646}}</ref> |id=block.itemframe.break}} {{Sound table |sound=Bow shoot.ogg |source=player |description=When an eye of ender is thrown |id=random.bow |volume=0.5 |pitch=0.33-0.5}} {{Sound table |sound=End portal eye place1.ogg |sound2=End portal eye place2.ogg |sound3=End portal eye place3.ogg |source=block |description=When an eye of ender is placed in an end portal frame |id=block.end_portal_frame.fill |volume=0.3 |pitch=0.9/1.0/1.1 |foot=1}} ==Data values== ===ID=== {{edition|java}}: {{ID table |edition=java |firstcolumnname=Item |showforms=y |generatetranslationkeys=y |displayname=Eye of Ender |spritetype=item |nameid=ender_eye |form=item |foot=1}} {{ID table |edition=java |firstcolumnname=Entity |generatetranslationkeys=y |displayname=Eye of Ender |spritetype=entity |nameid=eye_of_ender |foot=1}} {{edition|bedrock}}: {{ID table |edition=bedrock |firstcolumnname=Item |shownumericids=y |showforms=y |notshowbeitemforms=y |generatetranslationkeys=y |displayname=Eye of Ender |spritetype=item |nameid=ender_eye |id=433 |form=item |foot=1}} {{ID table |edition=bedrock |firstcolumnname=Entity |shownumericids=y |generatetranslationkeys=y |displayname=Eye of Ender |spritetype=entity |nameid=eye_of_ender_signal |id=70 |foot=1}} ===Entity data=== The purple particles left by eyes of ender have entity data that define various properties of the entity. {{el|java}}: {{main|Entity format}} {{/ED}} {{el|bedrock}}: :See [[Bedrock Edition level format/Entity format]]. ==Advancements== {{load advancements|Eye Spy}} ==Video == {{Video note|This video does not mention that eyes of ender can be used to craft [[ender chest]]s or [[end crystal]]s.}} <div style="text-align:center">{{yt|E0AhoxYLomc}}</div> ==History== {{History|java}} {{History||1.0.0|snap=Beta 1.9 Prerelease 3|[[File:Eye of Ender JE1 BE1.png|32px]] Added eyes of ender. |Eyes of ender can be used on a [[end portal frame|portal block]] to repair them, but repairing them does nothing.}} {{History|||snap=Beta 1.9 Prerelease 4|Each eye can now be placed in a [[end portal frame|portal block]] or used to hone in on a [[stronghold]]. [[Jens Bergensten|Jeb]] demonstrated the new uses for an eye in his livestream.<ref>http://www.twitch.tv/jebox/b/297000418</ref> An [[end portal]] within a stronghold could be seen in the stream with two eyes inserted into blocks. |In older worlds with chunks generated before [[Java Edition Beta 1.9 Prerelease 3|Beta 1.9 Prerelease 3]], the eyes may mislead the [[player]] to a place where there isn't a [[stronghold]] at all. This happens because the eyes lead to where a stronghold should be based on the world seed in the current version, but before Beta 1.9 Prerelease 3 strongholds generated differently based on the seed. Therefore, if the player saved the coordinates the eye traveled to in an old world and generated a new world with the same seed, the player could travel to those same coordinates and find a stronghold.}} {{History|||snap=Beta 1.9 Prerelease 6|Eyes of ender no longer render like a tool in third person.}} {{History|||snap=RC1|The throwing sound of eyes of ender has been changed.}} {{History||1.3.1|snap=12w21a|Eyes of ender can now be used to craft [[ender chest]]s. |Priest [[villager]]s would [[trading|buy]] 2–3 eyes of ender for one [[emerald]].}} {{History|||snap=12w22a|Priest villagers no longer buy eyes of ender, instead selling them for 7–10 emeralds.}} {{History||1.6.4|snap=1.6.3-pre|Eyes of ender now lead to [[stronghold]]s based on the structure data saved in the world file instead of calculating their approximate location via the [[seed (level generation)|world seed]]. Therefore, strongholds generated in old versions can still be found even if the distribution of strongholds is changed.}} {{History||1.7.2|snap=13w41a|Eyes of Ender now lead to the entrance of a stronghold instead of the portal room.}} {{History||1.8|snap=14w02a|With changes that have been made to villagers and the [[trading]] system, cleric villagers now sell eyes of ender for 7–11 [[emerald]]s, as one of their tier III trades.}} {{History||1.9|snap=15w41a|Eyes of ender are no longer [[trading|sold]] by cleric [[villager]]s.}} {{History|||snap=15w44b|An eye of ender is now used to craft an [[end crystal]].}} {{History|||snap=pre3|Eyes of ender now point to the 125 new strongholds.<ref>{{bug|MC-91173}} resolved as "Fixed"</ref>}} {{History||1.11|snap=16w32a|The [[entity]] ID has been changed from <code>EyeOfEnderSignal</code> to <code>eye_of_ender_signal</code>.}} {{History||1.12|snap=17w17a|A new ''pop'' [[sound]] has been added when a thrown eye of ender bursts.}} {{History||1.13|snap=17w47a|Prior to [[1.13/Flattening|''The Flattening'']], this [[item]]'s numeral ID was 381.}} {{History|||snap=pre5|The [[entity]] ID has been changed to <code>eye_of_ender</code>.}} {{History||1.14|snap=18w43a|[[File:Eye of Ender JE2 BE2.png|32px]] The texture of eyes of ender has been changed.}} {{History||1.19|snap=22w11a|Eyes of Ender now lead to the corner of the chunk (0, ~, 0) instead of the center (8-9, ~, 8-9).<ref>{{bug|MC-253394}}</ref>}} {{History|pocket}} {{History||1.0.0|snap=alpha 0.17.0.1|[[File:Eye of Ender JE1 BE1.png|32px]] Added eyes of ender.}} {{History|bedrock}} {{History||1.10.0|snap=beta 1.10.0.3|[[File:Eye of Ender JE2 BE2.png|32px]] The texture of eyes of ender has been changed.}} {{History||1.16.0|snap=beta 1.15.0.51|The [[particles]] of eyes of ender have been changed to match {{el|je}}.}} {{History|console}} {{History||xbox=TU7|xbone=CU1|ps=1.0|wiiu=Patch 1|[[File:Eye of Ender JE1 BE1.png|32px]] Added eyes of ender.}} {{History||xbox=none|xbone=none|ps=1.90|wiiu=none|switch=none|[[File:Eye of Ender JE2 BE2.png|32px]] The texture of eyes of ender has been changed.}} {{History|new 3ds}} {{History||1.7.10|[[File:Eye of Ender JE1 BE1.png|32px]] Added eyes of ender.}} {{History|foot}} === Historical images === <gallery> File:Held_Eye_of_Ender.png|The eye of ender used to appear large in third-person view. </gallery> ==Issues== {{issue list}} ==Trivia == *When thrown in third-person view, the eyes of ender fly out from the player's feet instead of their hand. *Before [[Java Edition 1.9]], eyes of ender can be purchased from cleric villagers, which means players can find a [[stronghold]] and go to [[the End]] without accessing [[the Nether]] at all. *{{IN|bedrock}} if the player travels beyond a certain radius (roughly 740,000 blocks), eyes of ender always point to a stronghold near spawn, even though strongholds continue to generate past this limit. If one travels to this limit, they can see eyes of ender suddenly switching direction. A similar phenomenon occurs with the {{cmd|locate}} command. ==Gallery== ===Screenshots=== <gallery> Stronghold Portal Room.png|An end portal frame containing a few eyes of ender. EnderChestexample.png|An [[ender chest]] depicting an eye of ender on the front. </gallery> ===In other media=== <gallery> File:Eye of Ender JINX.jpg|Official T-shirt artwork "Eye of Ender" sold by JINX. File:Happy Halloween Eye.jpg|A Halloween T-Shirt design featuring an eye of ender. </gallery> ==External links== *[http://www.strongholdfinder.com/ A super-easy stronghold triangulation tool] *[http://jsfiddle.net/42EDX/40/ JSFiddle Eye of Ender triangulator - can guess the location of other 2 strongholds in the first ring] *[https://ens-gijs.github.io/minecraft-stronghold-locator/ Minecraft Stronghold Locator Eye of Ender throw plotting visualizer - zoomable to show all possible stronghold rings] *[https://github.com/winny-/stronghold Python Eye of Ender throw plotting tool] *[http://www.purplefrog.com/~thoth/MinecraftStronghold/stronghold.html HTML Eye of Ender throw plotting visualizer (not updated after 1.9 stronghold placement changes)] *[http://chunkbase.com/apps/stronghold-finder Chunk Base Stronghold Finder (seed-based)] *[https://github.com/toolbox4minecraft/amidst/releases Amidst - File-based world visualizer] *[http://minecraft.tournier.org/StrongholdLocator/ Find strongholds by analyzing stronghold.dat file] == References== {{reflist}} {{Items}} {{entities}} [[cs:Endové oko]] [[de:Enderauge]] [[es:Ojo de ender]] [[fr:Œil de l'Ender]] [[hu:Végzet szeme]] [[ja:エンダーアイ]] [[ko:엔더의 눈]] [[nl:Enderoog]] [[pl:Oko Endera]] [[pt:Olho de ender]] [[ru:Око Края]] [[th:ดวงตาแห่งเอนเดอร์]] [[uk:Око Краю]] [[zh:末影之眼]]</li></ul>		beta 1.2.20.1			Added dolphins.
		beta 1.2.20.2			Dolphin model has been updated.
					Dolphins now have sounds.
		beta 1.5.0.0			Now lead players to shipwrecks and underwater ruins.

- Princess Nightmoon (TalkContributions) 13:19, 27 April 2018 (UTC)

A better way is to write the version just like in-game. We don't need beta prefixes. Beta 1.5.0.0 will be just called 1.5.0.0. This can prevent confusion. Skylord wars (talk) 06:57, 28 April 2018 (UTC)

An example.

Infobox (1.5.0.0)
"Type" indicates that it's a beta (snapshot) version, "Beta for" indicates which version it's a beta for.

1.5.0.0
Edition	Bedrock Edition
Release date	Xbox One, Windows 10, Android - April 25, 2018
Protocol version	Pending

I'm sure most readers can determine this is a Beta version page.Skylord wars (talk) 07:01, 28 April 2018 (UTC)

Are we going to start a renaming project?--Skylord wars (talk) 01:32, 2 May 2018 (UTC)

I don't think a renaming project would be necessary - I certainly wouldn't mind moving all of the builds to their beta titles and fixing the article's information. I would like the opinions of other editors before doing this though, as I'm not sure if we've come to a consensus yet. This will be a pretty drastic change to the wiki, so we need to make sure that the community overall is OK with doing this, so that we can avoid a mass page-move revert. Another thing to keep in mind is all of the templates and links that will need to be updated after we've done this.-- Madminecrafter12^{Talk to me} 01:36, 2 May 2018 (UTC)

I guess we don't need to move all of it, but only updates after 1.0. Because the in-game version started using this format after 1.0. Before 1.0, Pocket Edition still uses build numbers in-game. This is the same with Beta 1.9 Prerelease and 1.9-pre1, we need to follow the in-game number. I have created a page User:Skylord wars/Bedrock Beta.--Skylord wars (talk) 01:46, 3 May 2018 (UTC)

I'm all for using in-game names as much as possible. Making up our own terms isn't helpful to reducing confusion. –Majr ᐸ Talk
Contribs 05:28, 5 May 2018 (UTC)

How about fitting the Japanese page that separates the template before and after the 1.2 release that became Bedrock Edition?--Mikanzukituyu02 (talk) 15:08, 6 May 2018 (UTC)

If you use Changelog in game as information source, 1.2.20.1 is build 8, 1.2.20.2 is build 9, 1.5.0.0 is build 10, 1.5.0.1 is build 11.--Mikanzukituyu02 (talk) 15:20, 6 May 2018 (UTC)

Can confirm the above as I’ve seen a screenshot of it that said “Build 11” on it. So referring to these as builds 9, 10, 11, etc. is fine. --Marioprotvi (talk) 13:10, 9 May 2018 (UTC)

Revisting this because yesterday on the MC Monday stream the devs announced that 1.4 would be coming very soon and said conduits would be in the second part of UA, which is 1.5. This actually makes sense because Beta 1.5.0.0 may actually the first build for 1.5 (despite just being bug fixes) and 1.5.0.1 is build 2 since that added conduits. Also, 1.2.20 may end up being similar to 1.2.14 where the betas share the same version number but the actual update contains none of the things in the beta. The current betas that are considered part of Update Aquatic (up to the last 1.2.20.x beta) would be part of 1.4, since there was no beta labeled 1.4.0.x. --Marioprotvi (talk) 16:13, 15 May 2018 (UTC)

Another thing I thought we could do is rename the articles to something like Bedrock Edition Update Aquatic build 1 on the Bedrock Edition 1.2.13 build 3 page (this would make it somewhat easier to distinct it from the other To keep the other versions mentioned as well, the lead would be something like this:

Update Aquatic build 1, also known as 1.2.13 build 3, 1.4 build 1 or beta 1.2.13.8 is a build released on March 16, 2018 that added some of the Update Aquatic features through Experimental Gameplay.

I’m not entirely sure how this would work but I’ll explain it more in detail soon. --Marioprotvi (talk) 00:45, 16 May 2018 (UTC)

Dinoguy1000 undid nearly every single edit I did to try and fix this problem and he claims “no source was given”. We need to settle this right now (pinging KnightMiner, Skylord wars, Majr and any others i couldn’t immediately think of) as Bedrock Edition 1.4 build 11 is mislabeled - there are no conduits in the full 1.4 release (I checked, not added even in EG) but this is a 1.5 feature that is in an article under 1.4 which is factually incorrect. Someone needs to email the development team itself to see if they can provide better information to fix this. --Marioprotvi (talk) 19:28, 16 May 2018 (UTC)

As I explained on your talk page, the names of version articles should reflect those versions' in-game names (see also MinecraftPhotos4U's massive cleanup and correction campaign with early Minecraft versions, which featured a lot of renaming for that purpose). If you can demonstrate that a given build is named in-game how you renamed its article, then the rename is fine and can be redone. Otherwise, if you can demonstrate the name was used in an official source, it should be noted in the article as an alternative name. Beyond that, if there is incorrect information in the articles, it should be corrected (for most of them, if anything is required, this probably just means clarifying what version the build is actually for). This does not mean, though, that articles should be "corrected" because a given feature in the build isn't included in the release version the build is named for (that comes down to the versioning for BE being messed up in the first place, and is not our place to try to fix, though we should explain it for readers). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 19:56, 16 May 2018 (UTC)

Now that I think about it, the way the betas were named post-1.0 actually seems like a plausible idea (like what Skylord wars suggested) since they are the actual numbers in-game. --Marioprotvi (talk) 20:01, 16 May 2018 (UTC)

I've created two template mockups for Template:Bedrock Edition versions so we can vote which one is more suiting.

Mock-up #1

Mock-up #2

Personally I'd be willing to go with the second one since thats what its referred to in-game, although the alpha/beta name can be template-only and the pages without the name - e.g "beta 1.2.13.8" would link to Bedrock Edition 1.2.13.8. This creates problems with 1.0 and 1.1 as their respective builds were labeled "alpha v1.x.x.x" during gameplay but it changed to "beta v1.x.x.x" from 1.2 onwards. If such a case rises we can just name it Bedrock Edition alpha 1.1.0.0 with alpha being all lowercase to be different from the Alpha phase of development (0.1-0.16). Same would go for beta. --Marioprotvi (talk) 22:34, 16 May 2018 (UTC)

We need to do something about 1.4, it's currently claiming that beta versions for 1.2.13, 1.2.14, and the seemingly non-existent 1.2.20 belong to it, but then the page's themselves refer to the parent version of the same name. So which is it? It looks more like those versions are entirely separate from 1.4, but re-implemented features from it in a "pseudo beta" behind the experimental gameplay setting. –Majr ᐸ Talk
Contribs 06:07, 18 May 2018 (UTC)

Deletion requests for mod pages

Several IPs (I'm pretty sure they're the same person though, as their IPs are very similar and always have a similar edit summary) are going to mod pages for mods that only work in outdated versions, and requesting that they be deleted. I'm not familiar with mods and how they should be incorporated into the wiki, which is why I'm asking this question to the community. If a mod does not work in the current version, should it be deleted? Like I said, I'm not too familiar with the subject, so I haven't been adding any deletion templates myself, but if the answer is "No, just because the mod doesn't work in the current version doesn't mean the mod page should be deleted," then I will start reverting the edits from the IP(s) adding {{delete}}.-- Madminecrafter12^{Talk to me} 14:18, 4 May 2018 (UTC)

Trivially, this is not enough reasoning. No mod would work with the ultra-new, two-hour-old JE release, and this is not valid basis to nuke every mod page there is.

However, mod pages in general seem to be largely abandoned. Some of them are almost contentless. I think we should change the topic of the conversation to the more general one of mod article policy on this wiki. --AttemptToCallNil (report bug, view backtrace) 14:27, 4 May 2018 (UTC)

I do agree that we should discuss the mod policy on the wiki. However, for short term purposes, should I let the IP(s) add deletion templates to every single mod page there is that does not work in the current version (which is pretty much what they're doing now), or revert the edits?-- Madminecrafter12^{Talk to me} 14:52, 4 May 2018 (UTC)

I'm not the final authority, but I'd just check, and if both the mod is available for download, and the required MC version is listed in the official launcher, I'd revert; if not, I'd replace the deletion reason with "no longer available/usable". --AttemptToCallNil (report bug, view backtrace) 15:47, 4 May 2018 (UTC)

We also need to make the same decision about custom servers.

I'm totally happy to get rid of all the mods and move them to ftb:. It's better set up to work with mods, whereas ours are just tacked on the side with vanilla taking the main space. I think it's a lot simpler to have this wiki focus on vanilla, and FTB and individual wikis focus on mods.

@Xbony2: What's FTB's policy on abandoned mods and ones for outdated versions of Minecraft, such as what's currently inhabiting Category:Pending deletion? –Majr ᐸ Talk
Contribs 05:20, 5 May 2018 (UTC)

I believe the question of mods has come up on Slack in the past, though I couldn't say what (if any) result came of it; personally I'd be in favor of Majr's suggestion to move all mod content to FTB and/or individual wikis. Doing this would also let us simplify several templates that have for years had to include support for mods (IIRC it would mostly be the inventory-related templates that are affected).

I added a comma to your comment to clarify your meaning, Majr, feel free to remove it if I got it wrong or you don't want it there.

「ディノ奴千？！」^{? · ☎ Dinoguy1000} 08:12, 5 May 2018 (UTC)

What would you have other language wikis do with their mod articles? The Russian wiki has a substantial portion of users contributing mainly to mod articles. --AttemptToCallNil (report bug, view backtrace) 09:23, 5 May 2018 (UTC)

That would be up to each wiki to decide for themselves; the English wiki shouldn't presume to dictate how the other-language wikis have to operate. If any of them want to go the suggested route here, though, the obvious option would be checking if there's an FTB/individual wiki in that language, and if not, seeing about having one set up (assuming the FTB/individual wiki isn't currently operated as a multilingual wiki). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 09:32, 5 May 2018 (UTC)

En's mod articles being mostly garbage and unmaintained doesn't affect other languages, so I don't see how us getting rid of them entirely does either. –Majr ᐸ Talk
Contribs 09:58, 5 May 2018 (UTC)

1. English wiki deletes mod articles.
2. English wiki removes mod support from templates/modules.
3. A non-English wiki (Wiki X) decided to keep their mod articles and use the original template/module versions.
4. Affected templates/modules are updated on the English wiki in order to introduce functionality needed on all language wikis. The update requires nontrivial adaptation (i. e. beyond copying and string translation) in order to make it work with the original, mod-supporting templates/modules. As a result, a major portion of mod templates/modules on Wiki X now requires substantially more effort to update.

I don't think this is an improbable scenario. --AttemptToCallNil (report bug, view backtrace) 10:11, 5 May 2018 (UTC)

That's fair, in which case I would use separate templates for mods. If we were keeping mods, that's what I'd want to do anyway, as supporting mods makes some things difficult to do (like getting rid of the legacy grid images). –Majr ᐸ Talk
Contribs 12:05, 5 May 2018 (UTC)

I'm not exactly sure what "separate templates for mods" means. Something like a Slot which only supports vanilla and ModSlot which also supports mods? And then Crafting for vanilla recipes, and ModCrafting for recipes from mods, plus similarly separated template pairs for all other interfaces? --AttemptToCallNil (report bug, view backtrace) 13:04, 5 May 2018 (UTC)

If the features mods need diverges from the features vanilla needs enough, it would be easier yes. If possible, it should be designed so that the mod version can just implement the extra features and hook in to the vanilla version for output. But if it's simple to include, we don't necessarily need to remove mod support entirely. –Majr ᐸ Talk
Contribs 13:34, 5 May 2018 (UTC)

Vanilla supports mod content via namespaces (vanilla uses minecraft:, other mods are assigned other namespaces). This behavior should probably be in all of the templates, especially if Mojang does end up introducing content in other namespaces. I don't know enough about how the templates work to actually say how feasible this is though. (I've been adding namespaces to things when I see it, though a lot of pages still are missing them) --Pokechu22 (talk) 16:26, 5 May 2018 (UTC)

oh god, I have been pinged for a bunch of stuff I haven't seen. Please poke me on Slack if you need my attention here; echo notifications are totally broken. Sorry that this is late. We accept and would be happy to accept the move of any/all mod content to the FTB Wiki, and we have no restrictions on mods being abandon or old or whatever. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 13:02, 13 May 2018 (UTC)

Create redirects

I guess yet again, I have to discuss with the community about the creation of these redirects per MinecraftPhoto4U's move summary. The redirects I want to create are Version history/Infdev, Version history/Indev, Version history/Classic, and Version history/Pre-classic. The reason is, A a ton of pages link to these that have not been fixed, B they are all very likely search terms, and C no other versions have development stages with these titles, so there's no reason not to have these redirects. Also, I'm not sure why MinecraftPhotos4U moved them to Java Edition Version history/[Development stages], as no pages would link to them and would never need to, AND it's useless for searching, as the first letter of any word is not case-sensitive in the search box.

Also, please don't think I'm trying to be rude or anything, but MinecraftPhotos4U, I'm really not a fan of how you're moving a ton of pages without leaving a redirect, breaking a lot of links, removing search options, AND all of the moves are without discussion, could be controversial, and many times (such as this time), just really don't make any sense - and then you say that we must discuss before recreating the redirects. I'm fine with you doing this if the community agrees with this, but for me it kind of seems annoying. I really hope you don't take any offense to this - you're a great editor and you've done some great things on the Minecraft Wiki. We're all just trying to make the Minecraft Wiki a better place, and I just thought I would bring this up. Once again, please don't take this as rude or offensive, as I do not mean for it to be taken that way at all.-- Madminecrafter12^{Talk to me} 22:39, 5 May 2018 (UTC)

About the redirects, most of them are fixes. See Pre-classic, Classic, Indev, and Infdev. Most search engines have fixed their links. Plus, it seems strange to let Alpha and Beta be in "Java Edition version history", while others are in "Version history". Thus, I don't see a reason to make these redirects--Skylord wars (talk) 06:40, 6 May 2018 (UTC)

It is useful to have these and they existed for ages and are still linked to by a lot of pages. What's wrong with having them? – Nixinova 06:53, 6 May 2018 (UTC)

You don't because there's no reason to be moving these redirects in the first place. Additional redirects can be created where needed, and unused and worthless redirects can be deleted, but moving them usually doesn't make sense. Since they were warned to stop moving pages, but continued, they've been blocked for a few days. –Majr ᐸ Talk
Contribs 07:28, 6 May 2018 (UTC)

Hostile Mobs not spawning in singleplayer survival.

I've started a singleplayer survival world, but I've had this problem that hostile mobs rarely spawn, only spwaners work, traps that include them spawning randomly in low light platforms seem to not be working. I've tried everything;

• lighting up caves (which are almost empty, no mobs in there, as if I was in peaceful mode)
• afk 24+ blocks away for longer than 1 hour (only 2 creepers spawned, figured that when I found 4 gunpowder transported in the chest by hoppers at the bottom of the trap)

If there's anything I can do please let me know. I've seen other vanilla players in youtube, they get massive quantities of spawns, but I don't get any. Screenshots included.–Preceding unsigned comment was added by EternalAssassin (talk • contribs) at 19:00, May 6, 2018 (UTC). Please sign your posts with ~~~~

You may need to post in in the forum. Try turn your render distance to a higher level, it may work.--Skylord wars (talk) 11:19, 6 May 2018 (UTC)

Texture Update sprites

So when the texture update is released, will these old textures in the {{InvSprite}} stay? Or are they going to be replaced with the new ones? I propose to move the old sprite to a separate template where it will eventually be used in the history section. – ItsPlantseed ⟨₰|₢⟩ 06:16, 9 May 2018 (UTC)

@ItsPlantseed: So something like moving InvSprite to InvSpriteOld or InvSpritePre(release date here), then updating InvSprite with the new textures? jjlr (talk) 06:20, 9 May 2018 (UTC)

Yes, but I'm not sure if that's necessary though. The file has reached 1MB and I don't know if it will affect performance issues. – ItsPlantseed ⟨₰|₢⟩ 06:50, 9 May 2018 (UTC)

Performance isn't really a concern with sprites, they're meant to have lots of images in (I'd actually be more worried about the size of the documentation page). However in this case, since it's changing pretty much everything I think it would be good to split off now, just to make editing easier (smaller page/image to upload reduces edit time), and also we should probably do this for blocks and items too. Then we just need to decide if we want to make it totally historical stuff (so whenever a texture changes we move the old image to the historical invsprite), or if it should contain all textures beginning from the texture update.

I'll create the base for the modules now so anyone can start getting the new textures uploaded. –Majr ᐸ Talk
Contribs 07:56, 10 May 2018 (UTC)

Nice, I'll start adding texture for the items now. Also I have a question, are those "TextureUpdate" suffix temporary? We seem somewhat familiar with the current sprite title. – ItsPlantseed ⟨₰|₢⟩ 10:36, 10 May 2018 (UTC)

Of course, the current templates/modules will be moved elsewhere once the update comes out (the name of which we need to decide on), then the new ones moved over the redirects.

Also I noticed you mentioned having an issue with using find in the browser creating duplicates? Did you mean you used some sort of find/replace thing to change names rather than editing them manualy? If that's the case then I think I can fix that. –Majr ᐸ Talk
Contribs 10:47, 10 May 2018 (UTC)

About that, I didn't use CTRL + F to replace (well since I can't), I used the key to find the name instead of scrolling. When I search E.g 'blue', the highlighted word will be considered as a duplicate, so I can't save it until I change all the misinterpreted words into something different. It seems like it only occurs on Edge, but I'm not sure for other browser. – ItsPlantseed ⟨₰|₢⟩ 11:23, 10 May 2018 (UTC)

Ah that wasn't the bug I was thinking of then. The issue is that edge sends a blur event to elements when it moves the find highlight off of them, regardless of if it was focused (and it doesn't send a focus event on the element which it moved the highlight to), which causes the script to think the original value is undefined (because there was no focus event to set the original name), which causes the script to "change" the current name to exactly the same as it already was making it think it's a duplicate. Was easily fixed though. –Majr ᐸ Talk
Contribs 12:10, 10 May 2018 (UTC)

@Majr: Also, how did you manage to make semi-transparent grid images while retaining its original color transparency? I had this problem while adding the Hardened Glass. – ItsPlantseed ⟨₰|₢⟩ 07:46, 11 May 2018 (UTC)

Well it was quite awhile ago, but I seem to recall using a feature in gimp to remove the background. I would assume it's possible in other editors. –Majr ᐸ Talk
Contribs 03:21, 13 May 2018 (UTC)

To remove the background in gimp it's: "Fuzzy Select" or "select by color" to select just the background, then "color to alpha". This way only the background is selected and the rest of the image remains untouched, also only editors that can handle alpha (transparency) can be used to remove the background, and beyond that only a few file formats can store images with alpha, for example PNG. jjlr (talk) 23:53, 16 May 2018 (UTC)

Thanks. Even though the RGB values are slightly off, it's fair enough. – ItsPlantseed ⟨₰|₢⟩ 03:41, 17 May 2018 (UTC)

 Question How are the sprite sheets currently generated? By hand or with a script? jjlr (talk) 04:57, 17 May 2018 (UTC)

Its done using JavaScript, but the code is integrated into the wiki. Just head to any sprite page and click the edit sprite tab. –KnightMiner · (t) 16:18, 17 May 2018 (UTC)

@KnightMiner: Thank you. So i can just call the sprite editor from a sandbox and create a sprite sheet directly that way? Also i'm assuming the sprites are just block renders, correct? jjlr (talk) 02:29, 19 May 2018 (UTC)

The sprite editor is for editing the sheets after the fact, since you are just using the old version of the current textures just copy InvSprite to start for the textures. –KnightMiner · (t) 04:40, 19 May 2018 (UTC)

KnightMiner but in theory would starting with a blank image work? jjlr (talk) 04:59, 19 May 2018 (UTC)

Template:InvSpriteTextureUpdate is exactly that. I could copy the names over too, but they're not all necessarily relevant to the texture update version (like historical sprites), so I just left it to start from scratch. The inv sprites are just screenshots from the inventory, not renders. –Majr ᐸ Talk
Contribs 07:47, 21 May 2018 (UTC)

Reference template with archive support

What is everyones opinion on a reference template that allows you to specify both the original link to a page but also an archive.org link for it? Something similar to wikipedia's archiveurl option for it's citation template. jjlr (talk) 11:05, 9 May 2018 (UTC)

Could be useful, but I don't think we want to specify archive links for absolutely every reference. --AttemptToCallNil (report bug, view backtrace) 11:24, 9 May 2018 (UTC)

I know that, it would be optional, so if you don't specify an archive link it will treat it as a normal reference. jjlr (talk) 11:27, 9 May 2018 (UTC)

 Support--Skylord wars (talk) 12:46, 9 May 2018 (UTC)

 Question Where on the page would this template be used? Would it also have deadurl= and archivedate= parameters? – Auldrick (talk · contribs) 17:33, 9 May 2018 (UTC)

 Answer I was thinking it could be used in place of the ref tag, so it would be used anywhere the ref tag could be used. Also it could have archivedate and maybe a urldead parameter that accepts a binary value (0 for false;1 for true), when true it could maybe state in the reflist that the original link is dead and to use the archive link, or maybe it could automatically redirect the reference to the archive link, otherwise when false it would just do nothing. This is currently more a concept than a working idea, and i would need some help getting a working prototype. jjlr (talk) 00:24, 10 May 2018 (UTC)

I've added an |archive-url= parameter to {{link}} (which only shows if |dead-url= is set). – Nixinova 04:18, 10 May 2018 (UTC)

That looks really good to me, except I wonder: What's the rationale behind displaying the dead URL and following it with the archive URL? Wouldn't it be better to display the original link but link it to the archive site, and insert "(archived)" without a link? That would keep users from trying to follow the dead link first. – Auldrick (talk · contribs) 15:20, 10 May 2018 (UTC)

 Agree That would make more sense, especially since the archive link is only if the original is dead. Although i would make a slight change to your idea, rather than displaying "archived" at the end i would do something more like this:

   Archived page(original) – Example site, archived day month, year

jjlr (talk) 22:56, 10 May 2018 (UTC)

I just don't agree with intentionally displaying a broken link when you have one that works. As a link it's useless. As a record of the original source it's useful for historical reasons, but not for validating the citation, and the archive page serves both purposes so it's not needed. Besides, it will still be in the template call when you're editing, assuming nobody would bother to delete it. Anyway, here's a comparison of the proposed expansions, as I understand the preceding discussion:

Target page status	Proposed by	Template expansion	Link(s) point to
alive		"Everything Aquatic!" .	target
dead, archived	Nixinova	"Everything Aquatic!" (Archive).	dead target, archived target
	Jjlr	"Everything Aquatic!" Archived page (original)	archived target, dead target
	Auldrick	"Everything Aquatic!" (archived)	archived target
dead, not archived		"Everything Aquatic!" .	dead target

– Auldrick (talk · contribs) 05:25, 11 May 2018 (UTC)

I've edited it to replace |url= with |archive-url= if the latter is set. – Nixinova 19:45, 11 May 2018 (UTC)

 Question I've been trying to use {{link}} for awhile now and it doesn't seem to produce a reference entry, if it doesn't work like a reference how is it suppose to be used? jjlr (talk) 08:17, 19 May 2018 (UTC)

Sounds parameter in BlockTileEntity template

When trying to add the new audio for the conduit and beacon to their relative infoboxes i noticed the BlockTileEntity template didn't have a sound parameter, would it be possible to add one since there are quite a few tile entities that produce sound. jjlr (talk) 05:44, 10 May 2018 (UTC)

 Done by Majr.-- Madminecrafter12^{Talk to me} 00:13, 11 May 2018 (UTC)

A bug in the Bug template

I've recently edited the 1.13 page on the Hungarian wiki, and found out that links to Mojang bug pages at references don't work. Instead they try to link to wiki pages like MCbug:122563. I've checked the template and it's the same as the one here. What could be the problem and how could it be fixed? david92003 (talk) 16:52, 10 May 2018 (UTC)

You need to go to hu:Speciális:Wikiközi hivatkozások and add some interwiki prefixes from Special:Interwiki. These prefixes may be used by the template (space-separated): apibug mcapibug mcbug mccebug mclbug mcpebug pebug. --AttemptToCallNil (report bug, view backtrace) 17:07, 10 May 2018 (UTC)

Thank you! david92003 (talk) 17:19, 10 May 2018 (UTC)

Audio from mp3 to ogg

Would anyone have any objection to me reuploading current mp3 files in ogg format, ogg has better compression while often providing better audio quality, and is completely open source. jjlr (talk) 01:21, 11 May 2018 (UTC)

It should be noted that IE can't play ogg. –Majr ᐸ Talk
Contribs 01:34, 11 May 2018 (UTC)

Although development for IE has been discontinued, and it is increasingly being replaced by other browsers. jjlr (talk) 01:56, 11 May 2018 (UTC)

Discontinued development doesn't mean it's not being used. Also Edge can't play ogg either. – Auldrick (talk · contribs) 05:36, 11 May 2018 (UTC)

You can technically open .ogg files in Microsoft Edge. You need to install this pack to open. It is free by the way. Skylord wars (talk) 08:04, 11 May 2018 (UTC)

Since that's installed by default (as least on the April 2018 update), it may as well be considered that Edge can play ogg. –Majr ᐸ Talk
Contribs 08:24, 11 May 2018 (UTC)

 Opinion IE has been discontinued and every other browser has support for vorbis encoded audio (webm and ogg), since IE is no longer being developed and support for it will eventually run out i don't believe it should be considered. Ogg is a much better format for audio in web browsers and has many advantages compared to mp3. If we are considering IE though then what about the other audio files on the wiki that are already in ogg format, would we reupload them in mp3 specifically for IE users? jjlr (talk) 09:48, 11 May 2018 (UTC)

IE is officially discontinued since the release of Windows 10 Edition. I dont think we need to reupload. For IE users, they should take some time to see this article. Skylord wars (talk) 04:13, 12 May 2018 (UTC)

 Oppose What about ios users?, we cant play ogg--TheCreeperStrikes (talk) 03:38, 13 May 2018 (UTC)

File:Ground_impact1.ogg

why is nothing being done about it?--TheCreeperStrikes (talk) 06:29, 12 May 2018 (UTC)

Education Edition Infdev and other backlog oddities

No, really.

The reason behind this, as well as way too many other Special:WantedPages entries, is that Template:Version nav checks the existence of articles on similarly named versions of other editions by calling #ifexist, which creates a backlink even if the target page is never supposed to exist.

Pretty much the only solution is to code the corresponding infobox row value manually. Manual substitution of already automatically inserted links shouldn't be too much of a problem. --AttemptToCallNil (report bug, view backtrace) 13:02, 13 May 2018 (UTC)

The same also goes for Bedrock Edition Infdev. See here. Skylord wars (talk) 00:51, 16 May 2018 (UTC)

Turtle shell documented on Armor page, and has its own page?

Is the Turtle Shell being documented on the Armor page, but also having its own page intentional? -EatingSilencerforBreakfast (talk) 23:39, 17 May 2018 (UTC)

Hello? Is anyone there? -EatingSilencerforBreakfast (talk) 00:32, 19 May 2018 (UTC)

I believe it is intentional. Because turtle shells can be worn as armor, but are also very different from all other armor making a separate page good for explain turtle shells in particular. jjlr (talk) 02:16, 19 May 2018 (UTC)

The helmet, chestplate, leggings and boots pages have their own pages but are also a part of the armor page. There is an unfinished discussion on whether to merge them. I would support merging these pages, as they are wearable, protective items that have a material associated with them (e.g., ‘’iron’’ helmet), and various enchantments that can be applied. Turtle shells are different because they are the only “armor” crafted using scutes, they provide water breathing as well as protection, they are not enchantable, and they can also be used for brewing. However, there is a section of the armor page that links to other wearable items, such as pumpkins and elytra. I would support mentioning turtle shells here and otherwise make turtle shells a separate page. The Blobs 14:15, 19 May 2018 (UTC)

 Info Actually turtle shells can be enchanted with an anvil in survival mode. jjlr (talk) 00:31, 20 May 2018 (UTC)

Jjlrjjlr, the turtle shell page does not mention enchantments. Could you please list the enchantments available on a turtle shell? The Blobs 02:59, 20 May 2018 (UTC)

 Done I added the enchantment section to the Turtle Shell page. jjlr (talk) 02:54, 30 May 2018 (UTC)

Minecraft Wiki (EN) Discord?

Crraftt has already created a Discord server for this wiki, but there's a problem.

This is our situation:

1. We have a Discord server intended for wiki users and just interested community members.
2. It's not prominently linked anywhere (such as on the community portal).
3. There has been no discussion behind its creation.
4. It has been created by a non-administrator.

• A server not prominently linked will miss its intended audience.
• A server prominently linked is implied to be endorsed by site administrators.
• A server for a site not administrated by that site's administration team, but endorsed by them, is weird at best and problematic at worst.

I think there's no point in a permanently unofficial and unrecognized Minecraft Wiki Discord server, and that we should only request the server to be taken down as a last resort.

Decisions need to be made on the following points:

1. Does the wiki need a Discord server?
2. If it does, can it be, after some reconfiguration, the server created by Crraftt?

I propose the following:

• In this discussion topic, the community decides on the points 1) and 2) mentioned above.
  • If the decision is against 1) (i. e. a Discord server is not needed), a further decision will need to be made on what to do with the existing one. Note: @Crraftt: please don't act rashly if the discussion starts to go against having a server, it would be better if you waited for the resolution before e. g. taking the server down.
  • If the decision is for 1), but against 2), a further decision will need to be made on the procedure of the new server's creation and deprecation/decommissioning of the existing one.
  • If the decision is for 1) and 2), Crraftt is asked to reconfigure the server as per the discussion's resolution (likely including, but not limited to, transfer of the "Server Owner" status to a confirmed wiki administrator), and the server is advertised as per the discussion's resolution (e. g. sitenotice, community portal, dedicated page like MCW:IRC, etc.)

I favor the points 1) and 2) mentioned above. --AttemptToCallNil (report bug, view backtrace) 17:37, 20 May 2018 (UTC)

While I'm not necessarily an active member of en wiki, I moderate a Discord server for other MCWiki project. I feel like a Discord server is beneficial to our (much smaller) community. It's a place where we often have a possibility to talk about edits to members who made them directly, definitely easier than discussion pages. With our current setup (recent changes feed, IRC bridge, some bots) it's also pretty neat place to hang out and banter or monitor changes. I think if properly moderated (with moderators spread around the globe) the server would be beneficial for this community as well. However, one of my fears when I created the server for project I'm contributing to was that it would distribute the discussions between the wiki and Discord, which is not what I want in a open project, chats on the Discord are closed only to server members. I think this is a really important matter that should be discussed further. Answering to two questions:

1. I think it would be beneficial for the wiki to have a Discord server

2. I'd feel safer if the server was in hands of administration member or at least more active/experienced editor, I don't mean any offence to Crraftt, I'm pretty sure their intentions are good and all they want is to make the wiki better, they seem very passionate about how they could help, but still. If Crraftt proves to be a good person to lead the server however, I have no issue with their server being the one for this community. Frisk (Talk page) 18:12, 20 May 2018 (UTC)

Perhaps I should have been more clear, but Discord has a concept of "Server Owner". Whoever created the server is initially designated such. If this person decides so, they can transfer this status to another user of the same server. A server owner has total control of the server and cannot be restricted from anything.

Given Crraftt's reaction in Slack, I don't think he would be unwilling to transfer the "server owner" status to a wiki admin. Thus, he wouldn't need to lead the server. --AttemptToCallNil (report bug, view backtrace) 18:22, 20 May 2018 (UTC)

I'm well aware of how ownerships work on the Discord, but considering the fact Crraftt didn't say anything about transferring the ownership I assumed it wouldn't happen. Frisk (Talk page) 18:39, 20 May 2018 (UTC)

 Support I feel a discord server for the wiki would be very useful, i understand there is a slack server but it seems to be more difficult to use than discord. Not to mention more people use discord than slack, which would allow more people to get involved in discussions. But i also feel the discord server should be created by a wiki admin, and should have a set of rules setup specifically for it as it would be difficult to apply wiki rules to a discord server. jjlr (talk) 01:15, 24 May 2018 (UTC)

I agree. - Erufailon4 (talk · contribs) 06:53, 24 May 2018 (UTC)

Why is the invite not working? - MinecraftPhotos4U (talk) 14:22, 24 May 2018 (UTC)

@MinecraftPhotos4U: What happens when you click it?-- Madminecrafter12^{Talk to me} 14:24, 24 May 2018 (UTC)

The original one may have expired. Here's a new one, it shouldn't expire. --AttemptToCallNil (report bug, view backtrace) 14:26, 24 May 2018 (UTC)

 Question So where does this currently stand, has a decision been made regarding this topic? jjlr (talk) 22:55, 27 May 2018 (UTC)

Yeah, the Discord server is already up and running with roles, channels, bots etc. A lot of wiki staff is there as well (currently 45 members overall). It's supposed to be more "public" soon. You can join to it using the link AttemptToCallNil posted above. Frisk (Talk page) 23:10, 27 May 2018 (UTC)

New snapshot pages and their related article reference

Every snapshot comes with a related article on the main website, and we create a new page for each. But each additional snapshot of the same week that is released, does not actually create a new article, but instead the previous is updated. However, the problem there is that Mojang apparently doesn't update the link to those articles consistently. Sometimes the article of an additional snapshot keeps the link of the previous, and sometimes the link gets updated to the name of the new snapshot, but not even consistently during the same week. For example, the articles for snapshots 10a, 10b, 10c and 10d all are linked by 10a, but 20a, 20b and 20c are all linked by 20b.

I just updated all snapshot articles of 1.13 to test and fix them (some were dead already). At the same time I took the opportunity to replace references to {{article}} with {{snap}}. The snap template exists specifically for these links, an alternative to the article one, so I think we should always use that instead of article. The only visual difference is that it does not include quotes around the link.

So I would like to ask everyone to from now on use {{snap}} for consistency, and secondly, to always be aware that the article link does not always include the name of the particular snapshot you're referring to. So always update the links to all same-week-snapshot articles, in case a new snapshot comes out and Mojang decided to change the existing article link. Thanks :) Lastly, do we need to update all older snapshot pages with this template as well? – Jack McKalling [ ] 16:56, 23 May 2018 (UTC)

I have updated the template to include quotes, and as I am the creator of the template, I have been updating the latest snapshots to incldue {{snap}} and hoped that other users would catch on. – Nixinova 05:24, 24 May 2018 (UTC)

@Nixinova: To clarify, where on the page would {{snap}} be placed? jjlr (talk) 05:42, 24 May 2018 (UTC)

The template specifies the link to the Minecraft.net snapshot article, and it goes into the reference just after the snapshot name of the first sentence on the page. Like this: '''18w21a'''<ref>{{snap|18w21a|May 23, 2018}}</ref> is the thirty-eighth snapshot released for [[1.13]]. The first argument is the name of the snapshot to link to, and it may be different than the one that the page is about. – Jack McKalling [ ] 07:31, 24 May 2018 (UTC)

Simplified version guides

For about a week now i've been working on a simplified 1.13 guide, i designed it to allow players to get a general overview of the additions and changes of 1.13, without being overwhelmed by the technical information on the 1.13 page. I think it is finally ready to let people see it, and i would appreciate opinions and suggestion from everyone, but keep in mind it is still a work in progress. The page is currently located Here. jjlr (talk) 07:14, 24 May 2018 (UTC)

 Info The guide for 1.13 should be done within the next week now, so do we know yet where it will go? I still think a tutorial page would be fine. jjlr (talk) 23:09, 30 May 2018 (UTC)

I definitely like the idea of it, and your guide certainly seems more appealing to readers than just a bunch of text, like how the normal version pages are. I'm not so sure about what it should be moved to - a tutorial page seems reasonable to me, but I would like to hear the opinions of other users. If you're planning on making version guides from 1.0.0 - to present, though, that's quite a lot - it may be worth it to even create a new root page name for version guides exclusively; e.g. Version guides/1.0.0, Version guides/1.8.7, Version guides/1.12.2, etc. For now, though, it may be better to just create this as a "Tutorials" sub page.-- Madminecrafter12^{Talk to me} 23:14, 30 May 2018 (UTC)

Would it be fine to link to the guides from the main {{Java Edition versions}} template even if they were tutorials? I think that would be cool. – Sealbudsman talk | contribs 23:40, 30 May 2018 (UTC)

I definitely like the idea of that. It would be kind of crammed and a bit much to condense in a small space, but I don't think it would be too bad, especially because we're not doing it for snapshots.-- Madminecrafter12^{Talk to me} 23:43, 30 May 2018 (UTC)

I also like the idea of that, but I think it would only make sense on doing it for "full" releases -- not e.g. ones like 1.7.5 or such that don't have a lot of changes (the main article for it is definitely enough for those). Perhaps they should go under the version subtitle ("Update Aquatic", "World of Color Update", etc) in the template? For minor updates that still added content such as 1.11.1 I'm not entirely sure how that would work, though (perhaps just a subsection on the main guide?). --Pokechu22 (talk) 02:33, 31 May 2018 (UTC)

 Support as a subpage of the major version update page, like Update Aquatic, not 1.13. Because the scope of the version update page includes all releases of that major version, which the guides are also if I understand correctly. And for instance 1.13 is just one release, just like 1.13.x. I find this hard to explain, but to show what I mean, it could be added to the template like this:

1.5 Redstone Update (Guide)

– Jack McKalling [ ] 08:55, 31 May 2018‎ (UTC)

That's actually an even better idea in my opinion. I definitely like that. And I do think the minor updates should be mentioned somewhere - and having them as a subsection of the main guide makes the most sense to me.-- Madminecrafter12^{Talk to me} 12:07, 31 May 2018 (UTC)

I also forgot to mention that if the guides become a subpage of the major update page like I showed above, the main page should also offer a link to its guide somehow, on-page. – Jack McKalling [ ] 12:20, 31 May 2018 (UTC)

Madminecrafter12 for admin?

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

The result of the discussion was promote Madminecrafter12 and AttemptToCallNil.

---

Proposed both on Discord and on Slack. In the last weeks, a significant part of vandalism and spam has been handled by global administrators, and it has been suggested new local administrators should be promoted.

In specific, Madminecrafter12 was the candidate with the most support. I suggest the proposal is further discussed here, and everyone who's voiced their opinion outside the wiki re-post it in this topic.

I offer strong support for the idea to promote new administrators (or at least one), as well as weak support for the idea to promote Madminecrafter12 in particular. --AttemptToCallNil (report bug, view backtrace) 14:14, 24 May 2018 (UTC)

I appreciate you taking the time to post this. I'm also going to ping many of the people who were active in this matter outside of Slack so that they know this is going on: ReedemtheD3ad, Sealbudsman, Frisk and Pcj-- Madminecrafter12^{Talk to me} 14:28, 24 May 2018 (UTC)

I have reasons to believe Madminecrafter12 is the right user to acquire administrator status. With his experience on this and other wikis, good history of contributions and good communication with rest of the community he has enough of qualities to properly administrate the wiki. With Gamepedia staff admitting Minecraft Wiki needs more administration, I think adding new administrator is a responsible, if not necessary thing to do. I hope the current administration agrees. Frisk (Talk page) 14:52, 24 May 2018 (UTC)

MCW needs more active admins. GRASP and global admins shouldn't have to step in as often as they do (almost daily), especially for as large and active a wiki as MCW. Whether or not that should be Madminecrafter is up to you guys. --Pcj (talk) 15:46, 24 May 2018 (UTC)

Agreed on the new admin need, uncertain about Madminecrafter12. He's made a lot of useful and good quality contributions, but I'm not sure about his administrative decision making. I haven't seen much of that to be able to judge it. How are new admins brought up to speed with admin policies and procedures, and would they get training, supervision or some other form of guidance on how to deal with their new abilities and responsibilities? Just casually concerned and caucious, not trying to be a downvoter. – Jack McKalling [ ] 16:06, 24 May 2018 (UTC)

To be honest, most of what I know about admin tools is from watching how many experienced admins handle situations many times. There are several guides for admins on the Gamepedia Help wiki, and there are many more on Wikipedia, and I have read the ones that I think are the most important. However, I've found that just watching how admins handle situations (especially when comparing them to how I would handle them), is the most helpful to me. Also, I do think it might be worth noting that I'm admin on two other wikis, one of them being a Gamepedia wiki. I don't think admins necessarily get any specific training or anything, but I do think the community and bureaucrats prefer to promote admins who are familiar with how admin tools work and when to use them.-- Madminecrafter12^{Talk to me} 16:29, 24 May 2018 (UTC)

Also forgot to mention I'm interested in the prior Slack discussion, but I fear I can't get access to it on this machine. Last time I joined a team on slack, the platform rendered disabled due to lack of support in my browser. I'm really hating my old machine here. – Jack McKalling [ ] 16:12, 24 May 2018 (UTC)

(edit conflict) Echoing the general opinion. Also, Madminecrafter12’s promotion would introduce “new blood” into the wiki’s administration — the last newly appointed admin, KnightMiner, has actually deserved his new status (in my opinion) for many years. — BabylonAS (talk | ru.Wiki Admin) 16:15, 24 May 2018 (UTC)

That was one of the things I thought the community may not be supportive of - the fact that I've not been registered for a long time like many admins are. I definitely have learned a lot in the time that I have been involved with wikis, though. And I agree that KnightMiner should have been appointed admin a long time ago - it seemed like the community was fully supported of him in early-mid 2015, but he didn't become an admin till late 2017 somehow.-- Madminecrafter12^{Talk to me} 16:40, 24 May 2018 (UTC)

 Strong Support - The user have made many constructive edits, even creating the templates {{speedy delete}} and {{welcome-vandal}} templates, both are good, the most useful template was the speedy delete template. I Strongly support that the user could become admin, but should be here for at least 1-2 months more. Psl85 ^Chat! 16:31, 24 May 2018 (UTC)

HEKP0H of the Russian Wiki was promoted to admin just two months and ten days after registration on October 2010, but he apparently came from Wikipedia or some other wiki. The candidate is known to be a Wiki Guardian for a different Gamepedia project. — BabylonAS (talk | ru.Wiki Admin) 16:45, 24 May 2018 (UTC)

Correction: HEKP0H is one of the founders of the Russian wiki. --AttemptToCallNil (report bug, view backtrace) 16:50, 24 May 2018 (UTC)

 Strong Support also - I would be extremely comfortable with no reservations with Madminecrafter as an admin. The way he comports himself as an editor interacting with his fellow editors, old and new, and with anons, is exemplary in my opinion, and is an example worth following. He displays a self awareness of how new he is, comparative to others who have taken the role, and I believe he fully appreciates that there is much to learn -- and he certainly cares to do so, and to do things well. If he will accept the keys to do some of the things that need done around here, I fully trust him to have them. – Sealbudsman talk | contribs 19:12, 24 May 2018 (UTC)

There really is no negative consequence to making Madminecrafter12 an Administrator in my opinion. He is very active in the Slack community, already a Wiki Guardian on another wiki, and has demonstrated good hard work and determination. He is well respected and trusted by many. All good qualities for an Administrator. – ReedemtheD3ad! (talk) 17:35, 25 May 2018 (UTC)

 Support --Pokechu22 (talk) 22:14, 25 May 2018 (UTC)

 Support as well. -Sonicwave ^(talk) 22:22, 25 May 2018 (UTC)

Shameless self-promotion

Just wondering, what is the general opinion of the community on me becoming an administrator here? Because I am active, in a different time zone from many other administrators, already have administration experience...

I think I am capable of being at least a basic anti-vandal/spammer who monitors the Recent Changes several times every day. Any opinions? --AttemptToCallNil (report bug, view backtrace) 20:19, 24 May 2018 (UTC)

 Supportive. – Sealbudsman talk | contribs 21:29, 24 May 2018 (UTC)

 Supportive Frisk (Talk page) 21:52, 24 May 2018 (UTC)

 Support. It certainly can't hurt to have an extra admin, especially if they're known to use the tools properly. I do think that it would be nice to promote another admin besides you as well - whether or not that would be me is for the community to decide. But if you and one other user become an admin, I don't think we'll be needing another admin for a while - unless an admin suddenly decides to leave MCW indefinitely.-- Madminecrafter12^{Talk to me} 22:22, 24 May 2018 (UTC)

 Support jjlr (talk) 23:58, 24 May 2018 (UTC)

 Support The wiki currently only has 13 admins exclusing bots and Abuse Filter. I suggest adding more 3 admins in total. skylord_wars (talk) 01:24, 25 May 2018 (UTC)

 Support -Erufailon4 (talk · contribs) 06:52, 25 May 2018 (UTC)

I also support AttemptToCallNil for Administrator. They also have been active in the Slack community, have demonstrated good hard work and determination, and are respected and trusted. – ReedemtheD3ad! (talk) 17:35, 25 May 2018 (UTC)

 Support, good experience with AttemptToCallNil. Self-promotion looks promising, with your success here, but I admit I don't want to carry admin responsibilities myself. I fear the power. – Jack McKalling [ ] 20:38, 25 May 2018 (UTC)

 Support --Pokechu22 (talk) 22:14, 25 May 2018 (UTC)

 Support -Sonicwave ^(talk) 22:22, 25 May 2018 (UTC)

 Support – Nixinova 22:51, 25 May 2018 (UTC)

New mainterace templates?

Hello, I thinked today that we should need some mainterace templates, and modify the existing, and upload some images for those templates, and those templates can include, example: rewrite, more images, just released version or snapshht, to notice the readers that the pages need more rewrite. I can also add a navbox for the existing templates and deletion notices. A warning template for copyright violation can also be added, to use on copyright violation pages. If ok, can I begin to create those pages. Questions, ask below Psl85 ^Chat! 16:58, 24 May 2018 (UTC)

My opinions about the creation of each template:

Rewrite - In my opinion, that may not be quite necessary. You could just use {{Cleanup}} and say "This article needs to be rewritten" for the first (reason) parameter. Also, Category:Cleanup is not an extremely huge category right now, so currently I don't think it needs to be divided. As more and more features are added to Minecraft, though, this may could eventually become a useful template though.

More images - We already have that one - {{MoreImages}}. However, I do think it probably should be moved to have space in between the two words - I'm definitely going to create a redirect with the spaces though.

Just released version or snapshot - I don't really see the point of that. How would that really be useful?

Copyright vio - Could just mark those deletion. The admins aren't really that active with deleting pages requesting to be deleted anymore, but I doubt they would delete it quicker if it were separate.

I'm open to other opinions, though, and just because I may not be a fan of some of these doesn't mean you're not allowed to create them.-- Madminecrafter12^{Talk to me} 17:09, 24 May 2018 (UTC)

Oh, and another thing, I do like the images idea - I think it makes the maintenance templates a lot more visually appealing with images.-- Madminecrafter12^{Talk to me} 12:18, 25 May 2018 (UTC)

Allow editors to lock pages from ip edits for short periods of time

Would it be possible to add a way for editors to temporarily protect a page from ips making edits in order to avoid the long revision wars like on 18w21a, which ended up filling the page with obscenities that people visiting the wiki shouldn't need to see. For example have a way to protect it for one to two hours in order to give time for an admin to come and either extend the page protection, or block the ip. jjlr (talk) 23:53, 24 May 2018 (UTC)

Madminecrafter12 and KnightMiner i would like your opinions on this. jjlr (talk) 23:55, 24 May 2018 (UTC)

(edit conflict) I am not sure if we want users to abuse this. However, it may be helpful to add a “Short Protector” user group. Game widow, is this possible? The Blobs 00:00, 25 May 2018 (UTC)

Jjlrjjlr, are you saying that you think all users, or a certain group, should be able to protect pages, or are you just asking if there is a way for anybody to protect a page? If you mean the second option, then admins can semi-protect (allow only registered users) or fully-protect (allow only admins) a page. However, protection is usually (there are many exceptions though) only done when there are mutiple users vandalizing a page - otherwise, it's usually just better to block the vandal.-- Madminecrafter12^{Talk to me} 00:03, 25 May 2018 (UTC)

@Madminecrafter12: I'm suggesting allow all, or maybe a select few (but how to decide on that?), confirmed users semi-protect a page for a short period of time in order to stop the vandalism until an admin can block the ip. jjlr (talk) 00:05, 25 May 2018 (UTC)

I definitely don't think we should allow all confirmed users to protect pages (on MCW, confirmed users are the same thing as registered users). That means that you could literately just create an account, completely blank a page, and then fully-protect it so that the vandalism can only be reverted when an admin sees what happened. Creating a new user group is a better, but I'm not sure it's worth it to create a whole new user group just to protect pages. We're currently discussing a similar matter on Slack.-- Madminecrafter12^{Talk to me} 00:11, 25 May 2018 (UTC)

@Madminecrafter12: Why would it require an admin? I'm suggesting having it only semi-protect the page not fully protect it. Though i do somewhat agree that the vandal could create an account, so there would need to be a way to decide who gets to protect pages. jjlr (talk) 00:15, 25 May 2018 (UTC)

Dinoguy1000 Could we get your opinion please? jjlr (talk) 00:17, 25 May 2018 (UTC)

I don't think MediaWiki supports granting individuals such specific protecting capabilities. Its either you can protect up to your role or not, no control over specific time.

Main thing I'd be wary about giving a larger group the right to protect is people being too quick to protect pages when they get any vandalism. Mostly, if too many people get the ability, its more likely to be abused, and if too few get it that's just adding another group to ping if vandalism happens.

Best solution for this is to probably adjust the abuse filter if there are patterns that can be tracked, or to continue the other conversation on specific users to give additional rights. –KnightMiner · (t) 00:49, 25 May 2018 (UTC)

On Wikipedia, there are extended confirmed users. Can we add this new group? Additional rights can be given to these users. skylord_wars (talk) 01:02, 25 May 2018 (UTC)

As mentioned earlier, we (Gamepedia) do not distinguish between registered users and autoconfirmed users, so merely having an account is sufficient to be an autoconfirmed user. We can create a new group which is allowed to protect (or semi-protect) pages, so if that's the way you want to go we can do that but i don't see a whole lot of benefit — Game widow ^(talk) 12:58, 25 May 2018 (UTC)

As an option, there could be an adminbot responding to commands by authorized users who are not administrators. The commands could include temporary page protection and/or even short-term blocks. The bot could be linked with the Discord server. --AttemptToCallNil (report bug, view backtrace) 13:03, 25 May 2018 (UTC)

I would support this user group, as some edit wars receive many edits before an admin can semi-protect the page or block the user.

@KnightMiner: I would also support an abuse filter. Since edit wars often involve a user reverting reverts to their own edits, the filter could prevent anonymous users from posting an edit that is similar to a recently-reverted edit. The Blobs 14:21, 25 May 2018 (UTC)

@Blobs2: We were discussing this on Slack, and we definitely thought that the way to go was to make it so that if an IP edit is reverted 3 or 4 times within a certain timespan, they can't make another edit to that page for a certain amount of time. However, what we're not sure about is whether the abuse filter is able to detect that an edit has been reverted. If this does turn out to be possible, I definitely think that we should see how the AF goes before creating any kind of user group.-- Madminecrafter12^{Talk to me} 14:24, 25 May 2018 (UTC)

Just checked on the Russian wiki, abuse filters can't perform such operations on page histories. --AttemptToCallNil (report bug, view backtrace) 14:44, 25 May 2018 (UTC)

Oh, darn. :(-- Madminecrafter12^{Talk to me} 14:46, 25 May 2018 (UTC)

Mr Pie 5 told me that he had a couple ideas on how to do what I had requested for the AF detecting edit reverts, and that he would experiment with them later.-- Madminecrafter12^{Talk to me} 20:12, 25 May 2018 (UTC)

Late to the discussion, but I like the idea of a specific usergroup for dealing with spam/vandalism/edit warring etc. These tasks are not for the casual editor, as KnightMiner pointed out we need to appoint individuals who are trusted to have those abilities. I would suggest to start with the people who have already been dealing with these issues and contributed well at it. So I support a new usergroup, similar to the Autopatrol one we have, but there need to be selections and/or applications for it as well, not just on discord or slack. What is the difference between those two btw? – Jack McKalling [ ] 20:32, 25 May 2018 (UTC)

Maybe like a "verified" group? That could contain (edit: *regular*) users that have been on the wiki for over, say, one year (edit: and haven't had any trouble). – Nixinova 22:12, 25 May 2018 (UTC) ^{(Edited 03:24, 26 May 2018 (UTC))}

I definitely think that if we do decide to do something like this, admins or bureaucrats should have to approve the users - how long they've been on the wiki or how many edits they've made would not be safe enough in my opinion.-- Madminecrafter12^{Talk to me} 22:14, 25 May 2018 (UTC)

Just for reference, the Russian wiki once had a "moderator" user group which could delete, hide revisions and perform rollback. This group was disbanded when of the only two members one was demoted, and the second one was promoted to a full administrator. Even if the group suggested in this topic is formed with different permissions and generally in a different context, the group may meet the same fate.

One of the factors contributing to the demise of the Russian wiki group was probably an increase in local administrator activity. Given that there are two RfAs being discussed right now, both with positive outlook, creating an additional layer of vandalism combating may be excessive. --AttemptToCallNil (report bug, view backtrace) 22:24, 25 May 2018 (UTC)

A "Moderator" group sounds like it would work perfectly, so long as the group has the ability to semi-protect pages in the event of excessive vandalism. jjlr (talk) 00:37, 26 May 2018 (UTC)

I definitely support the idea, but there are things I want to say about this.

I recommend first seeing how both of the requests for adminship turn out before doing this. Who knows, maybe this won't be necessary if 1 or both of the candidates that are being discussed on the community portal talk page end up becoming an admin. I definitely think that we should see how that turns out before creating a whole new user group.

I would suggest having the following modifications from the user rights that the Russian wiki moderator group had. First of all, I'm not sure how necessary the delete tool would be. Right now it's not being used to revert that much vandalism, and it seems like it's one of the most sensitive admin tools, and abuse of it could lead to very drastic consequences. I definitely think that if we do decide to allow this moderator group to use this tool, that they should not have access to Special:Nuke. As for the hiding revisions, I haven't really made up my mind - other opinions and suggestions are welcome. I definitely think that rollbacking should be included.

And now for the protection part. Obviously, this is kind of the whole point of the group - otherwise it would just be a rollbacker group. Well, actually now that I think about it, that may not be so bad either... But anyways, one of the problems is, the ability to fully-protect pages as well as semi-protect pages are the same user right and listed on the same screen ([pagename]&action=protect), so I'm pretty sure there would be no way to allow moderators to only semi-protect pages (somebody please correct me if I'm wrong). If we did allow them to fully-protect pages, then it seems kind of counter-intuitive to not allow them to edit fully-protected pages, so it would probably be better to give them that right as well. I don't think that moderators should be allowed to block, though, as in my opinion, that's one of the more sensitive admin tools as well. It not only has potential to be abused, but a user may not be sure when to use it, and may block a good-faith editor unfairly.

Besides those things, this sounds like a good idea. Thanks for bringing it up, Jjlrjjlr!-- Madminecrafter12^{Talk to me} 00:56, 26 May 2018 (UTC)

If I remember correctly, you are only allowed to protect a page to a group you have access to, which is why all admins are also directors: to allow them to protect pages with director. There is a chance that feature is from an extension though, so don't quote me on that. –KnightMiner · (t) 01:09, 26 May 2018 (UTC)

@KnightMiner: Hmmm... interesting, that would definitely be nice if that is true. Are you basically saying that if, e.g. all registered users could protect pages, they could only semi-protect pages but not fully-protect pages, because they wouldn't be able to edit fully-protected pages? Also, would it work vice versa, e.g. if the same case were true, registered users wouldn't be able to downgrade a fully-protected page to semi-?-- Madminecrafter12^{Talk to me} 01:20, 26 May 2018 (UTC)

I'm pretty sure that would work, if not I'm sure another wiki has made an extension granting that ability by now. So if going that route we would give them the ability to semi-protect for short times, and maybe an new protection level for the new "editors" and admins for the case of edit wars (if the edit war involves editors of course, not stopping after the protection would be grounds for possible loss of the additional editor rights). –KnightMiner · (t) 18:31, 26 May 2018 (UTC)

 I do somewhat disagree with Nixinova's idea of it being time based, i.e. one year, because i feel time is a very unequal measure. Someone who has been here a year is not necessarily more qualified than someone who has been here six months. It should be entirely based on the individual, regardless of time. So perhaps change it to a certain number of edits, combined with how extensive those edits were? jjlr (talk) 03:52, 26 May 2018 (UTC)

As I said on slack, I  Agree with having some sort of trusted group to allow additional management without increasing the attack vector that admins create. It should be the quality of the edits, not amount of time the editor has been here, that determines if they should be in the trusted group. The main thing to decide is what permissions the trusted group would get, what is actually possible to implement in MW, and who should be in the group. –Majr ᐸ Talk
Contribs 07:49, 26 May 2018 (UTC)

UESP has a Blocker group with short-term block rights only, but that's apparently a custom extension. mw:Manual:User rights suggests user rights' assignments are Boolean values (true/false) and have no parameters which can be set on a per-group basis; this page also lists no other blocking rights beyond the standard one, which apparently can't have lengths constrained server-side.

I have my doubts on "soft" enforcement of short-term administrative actions by trusted users (e. g. a blocker can issue blocks of any length an admin can, but when an admin comes, blockers' blocks are reviewed and their lengths adjusted as necessary). Judging by every comment in this thread though, people are looking for a solution built into the software.

But there's also my idea of an adminbot issuing short-term protections/blocks based on authorized users' commands. It hasn't received any comments, should I consider it rejected? --AttemptToCallNil (report bug, view backtrace) 08:56, 26 May 2018 (UTC)

I would avoid an admin bot unless the software entirely prevents what we want, they tend to feel a bit clumsy and are one extra thing to learn. It would be a lot easier on the editors to just add a new user group. –KnightMiner · (t) 18:31, 26 May 2018 (UTC)

 Question So has a decision been made about this yet? jjlr (talk) 09:18, 9 June 2018 (UTC)

Use of upcoming and only templates

What is the best parameter to use for the {{upcoming}} or {{only}} templates, or a combination of them, for when a feature has been released for Bedrock Edition but only appears in snapshots for Java Edition, and does not appear in LCE at all? This is kind of the case right now for quite a few features currently.-- Madminecrafter12^{Talk to me} 20:10, 25 May 2018 (UTC)

I would suggest: {{only|bedrock|java}}{{upcoming|ver=1.13}} which is ‌‌

A digression: lately I've toyed with the idea of a single template that accomplished something like: -- but A) it becomes one of those difficult-to-translate templates, and B) the combinations are many and varied, and I couldn't think of easy to use parameters for all cases. – Sealbudsman talk | contribs 20:39, 25 May 2018 (UTC)

Ok, thanks! The second one would definitely be ideal, but you're right - with all the possible combinations and variations, I'm not sure how practical it would be. I'll do the first one, though. :)-- Madminecrafter12^{Talk to me} 21:22, 25 May 2018 (UTC)

Proposal: Classification of edits in others' user pages

Discussed on the Discord server. Requested post.

Proposed classification follows ("host" is the user whose userspace is edited, "actor" is the one who edits; definitions used for convenience):

---

Minor edit

a minor correction unrelated to technical maintenance (spelling, grammar, etc.) Allowed unless either prohibited by host, or for actor.

Major edit

addition of content or non-maintenance formatting changes. May be explicitly allowed on draft pages by host, prohibited otherwise.

Maintenance edit

correction of problems which negatively affect site functioning, e. g. which cause the page to appear in any automatically filled list or category such as "pages with script errors". Allowed unless prohibited for actor. Host cannot restrict, reverting is considered disruptive editing.

Reversion of disruptive edits

same rules as for performing maintenance edits.

Administrative actions

an action performed as a reaction to violations of site rules. Such actions by non-admins can be overruled by admins. If the actor is an admin, the action cannot be reverted without prior admin noticeboard discussion.

---

Reasons for writing the proposal: it clarifies a major point not explicitly listed anywhere. Additional issues arise from the unclear status of maintenance editing of others' user pages. --AttemptToCallNil (report bug, view backtrace) 17:00, 27 May 2018 (UTC)

I agree that maintenance edits, reversion of disruptive edits, and administrative actions are fine - for obviously reasons. I also definitely think that major edits should be prohibited. However, I also support that minor edits should not be made either unless the owner has given permission to make minor edits. This hasn't been a problem lately, but if we advertise that one may make minor edits to other people's user pages, I don't think that would be good. I mean, it's somebody's user page for a reason, and if they don't mind theirs being edited, they can say so. Also, I could see minor edits having a gray area as to what is considered minor and what major.-- Madminecrafter12^{Talk to me} 17:07, 27 May 2018 (UTC)

Agreeing with concerns. Version 2:

---

Maintenance edit

correction of problems which negatively affect site functioning, e. g. which cause the page to appear in any automatically filled list or category such as "pages with script errors". Allowed unless prohibited for actor. Host cannot restrict, reverting is considered disruptive editing.

Reversion of disruptive edits

same rules as for performing maintenance edits.

Administrative actions

an action performed as a reaction to violations of site rules. Such actions by non-admins can be overruled by admins. If the actor is an admin, the action cannot be reverted without prior admin noticeboard discussion.

Content edit

any other form of edit. Acceptable only if allowed for actor and by host.

---

--AttemptToCallNil (report bug, view backtrace) 17:14, 27 May 2018 (UTC)

I assume this has something to do with a proposed guideline? Because to my knowledge there is currently no official prohibition in this wiki against editing user pages other than the suggestion in MediaWiki:Editnotice-2. So where is this guideline being discussed on the wiki? (Please don't tell me to go read the Discord. Any discussion on Discord is preliminary and unofficial, not a substitute for talk page discussion.) – Auldrick (talk · contribs) 17:07, 9 June 2018 (UTC)

There is only a suggestion, and that is the problem. In addition, there is general, often unwarranted hostility against any modification of others' user pages. If there were to be a guideline (and one is being proposed), people could refer to it when editing others' user pages or discussing such actions. Currently, the only relevant provisions are either nowhere explicitly stated or too general. --AttemptToCallNil (report bug, view backtrace) 17:49, 9 June 2018 (UTC)

I'm all for using Discord to discuss ideas one-on-one or with a few, but I'm strongly opposed to using it for consensus building. I think reaching a consensus on Discord would tend to make those involved feel a sense of being finished and would subtly discourage them from considering objections raised later on the wiki. I'm not saying that I don't trust Discord users to try and be fair in their later deliberations, I'm just worried that once a group of editors agrees on something, they'll tend to act like a bloc, and an us-versus-them mentality could ensue. That's human nature. So if you're getting ready to propose a guideline, I hope you'll bring it to the wiki soon. – Auldrick (talk · contribs) 20:35, 9 June 2018 (UTC)

In the context of this proposal, Discord hasn't been used to build a binding consensus on Minecraft Wiki policy. I am aware of your concerns and share them. I cease my maintenance of the proposal for reasons not related to this discussion. --AttemptToCallNil (report bug, view backtrace) 22:01, 9 June 2018 (UTC)

A while ago I proposed adding a page with some of our user guidelines, similarly to the talk page guidelines. It would probably be good to have something similar to list not just when you are allowed to edit user pages, but what is allowed on them in the first place. Here is the draft from back then, it basically describes what is the user space, what it is allowed to contain, then who can edit it. Its been a while since I wrote it, but for the most part everything came from common practice that I just wanted an official place to write.

As for the specific proposal, I feel it could be condensed a bit. For instance, you could cover "both administrative action" and "reversion of disruptive edits" as "users may remove content that breaks the rules". I also personally do not think major and minor edits should be separated, I do not think users should be editing other people's user pages at all for non-maintenance tasks such as typos without permission. –KnightMiner · (t) 00:00, 10 June 2018 (UTC)

That draft of yours actually looks good. Why don't we implement that, possibly with some modifications?

Speaking of which, here are my suggestions on that draft:

1. The userspace is all articles According to my knowledge, "articles" is typically reserved to refer to content namespace pages. I suggest replacing "articles" with "pages" in this sentence.
2. directly controlled by the user. That just sounds weird to me. (in Harbinger's voice) "I AM ASSUMING DIRECT CONTROL OF THIS USERSPACE." (back to normal voice) I suggest replacing this with "directly associated with a specific user" or something similar.
3. articles that would not belong in the mainspace — similar to #1, but not exactly the same, I'm not sure this should be changed.
4. If a subpage ends in .css or .js, it becomes a script. Strictly speaking, .css pages are stylesheets, not scripts. Also, the extension only affects the default content model of a page (it can be changed). On a side note, I've seen some users put all their actual main userpage content into a .css subpage, and then transclude that subpage onto the main userpage. Should we suggest that .css/.js user pages should not be used for other purposes than stylesheets and scripts respectively?
5. Fixing or updating template usage ... file usage, page links, and possibly other maintenance issues such as invalid HTML. I suggest somehow adding all this there.
6. Editing pages which the owner marked as "Anyone can edit" Suggest rephrasing as "marked as editable by other users". I see no reason any particular sentence should be mentioned (which is what the draft currently does), especially given the notice on the draft itself used different wording.
7. please provide a link to the discussion or to a difference, given that discussions may be archived?

--AttemptToCallNil (report bug, view backtrace) 06:33, 10 June 2018 (UTC)

Overall I would be in favor of implementing it if there is enough support. As for specific comments:

1. Fixed
2. Fixed
3. In this case articles makes most sense. Its for things like User:KnightMiner/1.7.banana
4. Reworded to include style sheets. I am mostly neutral on forbidding people from using .css/.js pages for transclusion. Sure, its a pretty hacky solution, but if they feel their content is safer then that is on them. I guess the only concern is it makes maintenance harder as only an administrator or the user can change anything.
5. Fixed
6. Fixed
7. The original discussion was here, though most of the discussion side railed based on a different issue at the time.

–KnightMiner · (t) 22:51, 10 June 2018 (UTC)

Minor maintenance, including as "as" looks like a mistake. Also, "minor maintenance" implies some maintenance is not minor, which sounds somewhat weird to me. What kind of maintenance would not be minor?

In point 7, I wasn't asking about a link to a previous discussion on the draft, but about the text in your draft: If this is the case, please provide a link to the discussion in the edit summary for the convenience of others. --AttemptToCallNil (report bug, view backtrace) 09:24, 11 June 2018 (UTC)

For minor maintenance, I was mainly trying to distinguish it from some general wiki maintenance tasks, such as keeping articles up to date or cleaning up grammar, both of which fall under maintenance but I don't think should be freely allowed on user pages. Its not too important to distinguish as I list allowed maintenance, but I think it makes it a bit more clear that some types of maintenance do not apply.

The main reason for the link is so people don't revert with good intentions, they can just read the article. I guess a diff is useful for historical purposes though so I added that. –KnightMiner · (t) 14:24, 11 June 2018 (UTC)

I see no further issues.  Support implementing the proposal. --AttemptToCallNil (report bug, view backtrace) 15:20, 11 June 2018 (UTC)

Well spelled-out.  Support. – Sealbudsman talk | contribs 17:50, 11 June 2018 (UTC)

Maintenance template images

Kind of revisiting the discussion Psl85 made about the new maintenance templates, but in a clearer way and this time specifically about the images. This was first discussed on Discord after the images were added to some of the maintenance templates. Basically, I see 3 options:

1. Don't have any images at all for maintenance templates. Remove the existing ones, and don't add images to any of the others.
2. Use images that are the same as Wikipedia's, or simulate something in real-life. This is kind of what we have now for some of the maintenance templates - e.g., splitting arrows for {{Split}}, broom icon for {{Cleanup}}, etc.
3. Use images that are Minecraft-related. Some proposals on Discord were grass blocks moving towards each other for {{Merge}} simulating pages merging, and a piston getting ready to push a block for {{Move}} simulating moving.

Please discuss here, and new ideas are welcome as well.-- Madminecrafter12^{Talk to me} 13:40, 30 May 2018 (UTC)

Ok, but I only want to have a image, and I use Minecraft-related images instead of uploading Wikipedia-related and using on the mainterace templates,

I would to have the "cleanup" brush remaining, and a warning icon want I to add on the {{delete}} page, but it is protected, I cannot do it, but I suggest some Minecraft-related images on some tags instead of Wikipedia's images. I would continue with some tags, but if no good exist will I place an information icon. psl85 ☎ Talk 13:48, 30 May 2018 (UTC)

Listing 3 options gives me the impression you'd like to standardize on this idea. I would object to making this a formal standard. I like having the images, but I wouldn't want to discourage anybody from creating a useful template because they don't have one and aren't good at making images. But maybe I'm reading too much into it, and you're just asking for input for a personal project you're considering. In that case, I'd be happy with either Wikipedia's image or a custom Minecraft one, so long as it suggests at a glance the purpose of the template. – Auldrick (talk · contribs) 14:14, 30 May 2018 (UTC)

I think having a consistent goal is more important than a consistent style. If we decide we want Minecraft themed templates, a new template will just need a Minecraft themed image later, not immediately. –KnightMiner · (t) 14:23, 30 May 2018 (UTC)

Oh, yes, let me explain better. In my opinion, this is not some very formal and important thing - that is, there may be some maintenance templates that won't have images soon, or possibly never, and nobody should be discouraged from creating templates if they can't find an appropriate image. I was just curious of the general opinion and what people seemed to like the best. But yeah, thanks for bringing this up.-- Madminecrafter12^{Talk to me} 14:29, 30 May 2018 (UTC)

 Agree with 3. I personally think if we are going to have any images, they should be Minecraft themed to match the wiki skin. I would rather not just copy the Wikipedia icons. –KnightMiner · (t) 14:23, 30 May 2018 (UTC)

 Support 3. I don't believe it's necessary to demand an image for every message box out there, or even to formally declare a guideline. This is just for deciding which style we'd like to be consistent with, for those that do get/have an image. And personally I'd prefer minecraft-related ones because it's more personalizing for this wiki and fits better with the skin. – Jack McKalling [ ] 14:41, 30 May 2018 (UTC)

THIS IS AN EMERGENCY SUSPENSION OF A RUNNING WIKI-BREAK.

Given the community seems to converge on option 3, I request that, if this turns out to be the case, administrator consensus overrule this decision per arguments provided below.

Beyond potential legal issues I am not qualified to and therefore shall not comment about, Option 3 introduces a precedent in which additional usage of Minecraft assets is introduced on the wiki when non-Minecraft, freely licensed materials exist, are available and carry the same meaning no less clearly while being at least as legible and possibly more technically favorable.

I insist on vetoing option 3, and furthermore, making usage of Minecraft assets banned (as in, an enforceable rule) whenever it is at all possible to use any other, freely licensed materials.

After all, there's a reason you don't just write the entire wiki in the Minecraft font. --AttemptToCallNil (report bug, view backtrace) 15:53, 30 May 2018 (UTC)

Ah-oh, surely we should not use direct minecraft graphics, even with options 3. Fully agreed on copyright issues, although I don't fully understand everything you just said. But when I'd say "minecraft-related images", I do mean related, as in newly created looking similar to the game, not actually ripping the actual graphics. – Jack McKalling [ ] 16:04, 30 May 2018 (UTC)

 Support rule 3, minecraft themed images than Wikipedia-themed images, I would rather have Minecraft themed images, but the delete trashbin can be kept on the speedy delete template. psl85 ☎ Talk 16:12, 30 May 2018 (UTC)

This wiki literally uses Minecraft assets in its logo, I think using additional Minecraft assets is acceptable based on the brand guidelines, so there is absolutely no reason to make a rule against using Minecraft assets on the Minecraft Wiki. Sure, there are non licensed materials available, but there are non Minecraft licensed assets to use for our Logo and the Wiki skin as well. I see absolutely no reason to be inconsistent just because there is a copyright that we are allowed to use. –KnightMiner · (t) 16:30, 30 May 2018 (UTC)

Then I propose we just write the entire wiki using the Minecraft font. Any objections? --AttemptToCallNil (report bug, view backtrace) 16:34, 30 May 2018 (UTC)

I don't see how that is relevant here. This discussion is about whether images should be added to maintenance templates, and if yes, whether Minecraft or Wikipedia images should be used. | violine1101^(Talk) 16:42, 30 May 2018 (UTC)

Non-Minecraft (Wikipedia) images are conventional, freely licensed, require no maintenance in case Minecraft changes, their meaning is more apparent beyond just that they're used on Wikipedia, they are likely to be more legible and less bandwidth-heavy.

Actually, I'm for version 1. No images. The text says it all. The templates are even (or could be) color-coded for convenience. This site is not for people who can't be bothered to read a couple of prominently placed short sentences. --AttemptToCallNil (report bug, view backtrace) 16:55, 30 May 2018 (UTC)

I can't find anything that says that the wiki is not allowed to use Mojang content if it could be replaced with something else. I understand your points as to why freely licensed images are better, but I still disagree - and I certainly don't think this would be considered an emergency. I also don't see how "I propose we just write the entire wiki using the Minecraft font" is an argument that supports this.-- Madminecrafter12^{Talk to me} 18:27, 30 May 2018 (UTC)

...I withdraw myself from this discussion. --AttemptToCallNil (report bug, view backtrace) 18:35, 30 May 2018 (UTC)

Minecraft Creators Summit 2018

Here is a list of everything i can find tweeted about what was discussed at the summit, feel free to edit this list as information becomes available.

• Update aquatic was meant to pre-release May 30, 2018.
• Three updates are currently planned out for minecraft, more information will be unveiled at Minecon Earth 2018.
  • At least one update is suppose to overhaul combat mechanics, another is meant change gameplay.
• Graphics settings will be changed to add "Super Fancy" above the already existing "Fancy" setting.
• The official modding API is still planned and being developed, it will supposedly be coming to bedrock edition before java..

Also thanks to JSBM for translating some of the tweets. jjlr (talk) 00:26, 31 May 2018 (UTC)

All information about the Minecraft Creator Summit 2018 can be seen in twitter. Recompiled information.

• The summit is in Stockholm, Sweden. On May 30, 2018.
• There will be a new grafics setting in Minecraft. There will be a "fancy" and "super fancy" setting.
• The combat system will get an overhaul. The combat system overhaul will not be part of Minecraft 1.14. Mojang wants to take time and really get a lot of feedback.
• Minecraft Update Aquatic was supposed to come out on May 30, 2018. It is pushed back to make sure all crucial bugs are fixed.
• After Update Aquatic Mojang has already 3 more updates fully planned out to release. More info about that at Mine on Earth later this year.
• Making mods available on Bedrock edition is one of the highest priorities the bedrock team has at the moment. It is a difficult process though, because of the huge amount of devices and systems. It will not come in the near future but it will happen.
• Java modding will always be a construct of the community and continue to exist.
• Mojang recognizes the awesome stuff the modding community has created and is actively making an effort to make modders lives easier going forward. They are working to lessen the pain that each update to the game brings.
• Hope that there won’t be any more major fundamental changes to the game that will impact modders like 1.8 did and 1.13 probably will. Modders should have an easier time going forward.
• Mojang recognize how awesome forge is and kind of want to let it be what it is. There won't be an official modding api in java.

--skylord_wars (talk) 11:43, 31 May 2018 (UTC)