This is the community's main discussion page.
Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the feedback site.
- July – Oct 2010
- Nov – Dec 2010
- Jan – Feb 2011
- Mar – Apr 2011
- May – Jun 2011
- Jul – Aug 2011
- Sep – Oct 2011
- Nov – Dec 2011
- Jan – May 2012
- Jun – Sep 2012
- Oct – Dec 2012
- Jan – Mar 2013
- Apr – Jul 2013
- Jul – Dec 2013
- Jan – Dec 2014
- Jan – Jun 2015
- Jul – Dec 2015
- Jan – Jun 2016
- Jul – Dec 2016
- Jan – Jun 2017
- Jul – Dec 2017
- Jan – Apr 2018
- May – Jun 2018
- Jul – Aug 2018
- Aug – Dec 2018
- Jan – Jun 2019
- Jul – Dec 2019
- Jan – Apr 2020
- May – Aug 2020
- Sep – Oct 2020
- Nov - Dec 2020
- Jan - Apr 2021
- May - Jun 2021
- Jul - Sep 2021
- Oct - Dec 2021
- Jan - Jun 2022
- Jul - Dec 2022
Did these versions actually exist?
Following the recent rediscovery of Alpha v1.0.2 I've been in the process of adding evidence of existence of various versions from Alpha which are no longer available in the launcher. There is currently one remaining version which I am yet to find any proof for:
- Alpha v1.0.14_01
I can't seem to find any particularly solid ground on this version's case. I've searched through various YouTube videos, but it appears to be elusive, and I'm not being too successful with finding sources on Notch's blog either. General googling also provides no relevant results, photographic or otherwise.
There's also a few versions that can be presumed to exist due to later patches, but don't have pages, and I have also had no success verifying:
Can anyone help provide proof (video, screenshot, blog post or otherwise) that any of these four versions existed? - MinecraftPhotos4U (talk) 14:35, 21 March 2018 (UTC)
- I can provide some history from the wiki
, which seems to show that it doesn't exist: a1.0.15 was added to version history in revision 13802 and included the changes given to a1.0.14_01. But it was put before multiplayer instead of after, so there were two a1.0.15 versions listed, and this was also an after-the-fact revision (dated 25 August 2010). (n.b. I bypassed the broken username in version history by just manually editing the date) - This was later converted into a table in revision 15910, and that changed the second a1.0.15 to a1.0.14 (probably by accident), so that there were two a1.0.14's listed;
this is also when it was given a release date of August 03 2010. This duplicate entry continues on for years, until the articles are split off in revision 212986. The alpha history was put here. And, it was eventually the unique _01 name in revision 370385 when Fenhl refactored the links in the article. - As one more point of evidence, check the history of Patch history. There is only Seecret Friday 7 (with the last edit on 31 July 2010) and Seecret Friday 8 on 20 August 2010. No a1.0.14_01.
And, finally, it just doesn't make sense; the changes for a1.0.14_01 include "Can enter the IP for a server other than Mojang's server", yet a1.0.15 is supposed to be the version that introduced support for multiplayer. Basically, it is pretty clear to me that this version doesn't actually exist, and all of the changes listed for it are actually part of a1.0.15. No comment for the other versions yet. --Pokechu22 (talk) 18:18, 21 March 2018 (UTC)
- Alpha v1.0.14_01 doesn't exist, the only blog post that would be fitting belongs to Alpha 1.0.15. The post is mislabeled as Alpha 1.0.14 though, but comparing the dates of the jars and the timestamps of various blog posts it becomes clear that this one is indeed for Alpha 1.0.15. – Fuzs 19:26, 21 March 2018 (UTC)
On a similar topic, it seems as though the versions 0.30_01, 0.30_02 and 0.30_03, as listed in Version history/Classic, are all misnomers/conjectural; these were all called 0.30 in the page's initial revision, and looking at the corresponding blog posts on Word of Notch showed that they also shared the 0.30 title ingame. The situation with the 0.24 versions is identical. Does this affect any other versions? - MinecraftPhotos4U (talk) 18:58, 22 March 2018 (UTC)
I appear to have found the proof that Alpha 1.0.17_01 does indeed exist, as per here: https://i.imgur.com/SAkZp.png sourced from here: https://www.reddit.com/r/Minecraft/comments/d3fmt/double_tree_what_does_this_mean/ 44trent2 (talk) 08:14, 25 April 2018 (UTC)
- added! There's one that can be crossed off of the list.
- Now that we're also keeping track of Classic versions now, here's an updated list of conjectural versions:
- Classic 0.0.10a
- Classic 0.0.13a_01
- Classic 0.0.14a_02
- Classic 0.0.14a_05
- Classic 0.0.14a_06
- Classic 0.0.19a_01
- Classic 0.0.19a_02
- Classic 0.0.19a_03
- Classic 0.0.19a_04
- Classic 0.0.19a_05
- Classic 0.0.20a_01
- Classic 0.0.22a_01
- Classic 0.0.22a_02
- Classic 0.25_01 SURVIVAL TEST
- Classic 0.25_02 SURVIVAL TEST
- Classic 0.25_03 SURVIVAL TEST
- Classic 0.25_04 SURVIVAL TEST
- Alpha v1.0.6_02
- Alpha v1.2.3_03
And the "no-proof-so-they-might-as-well-be-fakes":
- Classic 0.0.13a_02
- Classic 0.0.13a_04
- Classic 0.0.14a_01
- Classic 0.0.16a
- Alpha v1.0.17
Would this be better split off into its own project? - MinecraftPhotos4U (talk) 10:30, 25 April 2018 (UTC)
- Probably, yes. – Nixinova
05:51, 26 April 2018 (UTC)
- I'll get around to setting it up at somewhere along the lines of Minecraft Wiki:Projects/Proving missing versions sooner or later. - MinecraftPhotos4U (talk) 15:22, 5 May 2018 (UTC)
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)
- I'd say there are two cases here. One would be creating the articles, and marking them all as
- 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)
- 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 [
- 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)
- 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 [
- Yes, that's it exactly. 「ディノ奴千?!」? · ☎ Dinoguy1000 20:00, 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)
- Regarding the editnotice, wouldn't it work to just put
- 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)
- 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
- System message
newarticletextcontrols 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. -- Orthotopetalk 03:17, 17 May 2018 (UTC)
- System message
- 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)
- I just used the same sentence as I suggested for the style guide. – Jack McKalling [
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. -- Orthotopetalk 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)
- I've saw that slicelime was added, could we start now? Or do we need another seperate page Orthotope? Hugman_76 [
- Currently, there are only Help:Official sources#Video hosting services.
- 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. -- Orthotopetalk 16:43, 22 April 2018 (UTC)
- Alright, can we start now Dinoguy1000, Orthotope, Skylord wars, Madminecrafter12? Hugman_76 [
] 15:10, 30 April 2018 (UTC)
- Alright, can we start now Dinoguy1000, Orthotope, Skylord wars, Madminecrafter12? Hugman_76 [
- 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)
- 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
- 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)
- I don't know how to do it, can someone do it? Hugman_76 [
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)
- So, may we start adding update videos by slicedlime? Dinoguy1000?-- Madminecrafter12
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)
{{/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)
- 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
- 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.
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.
| release | |||||
|---|---|---|---|---|---|
| November 18, 2017 | Dolphins were shown in a video clip during MineCon Earth | ||||
| upcoming | |||||
1.13{{Extension DPL}}<ul><li>[[Powder Snow Bucket|Powder Snow Bucket]]<br/>{{Item
| title = Powder Snow Bucket
| image = Powder Snow Bucket.png
| renewable = Yes
| stackable = No
}}
A '''powder snow bucket''' is a [[bucket]] with [[powder snow]] inside.
== Obtaining ==
A powder snow bucket can be obtained by {{ctrl|using}} an [[empty bucket]] on a [[powder snow block]] or [[powder snow cauldron]].
== Usage ==
Pressing {{control|use}} while holding a powder snow bucket places a [[powder snow]] block. {{IN|Java}}, powder snow may also be placed inside empty [[cauldron]]s, creating powder snow cauldrons.
[[Dispenser]]s can also create and place powder snow buckets. However, they cannot do so with [[cauldron]]s. You can also use it to cushion falls in the [[nether]] by placing it below you when falling.
== Sounds ==
{{el|je}}:
{{Sound table
|sound=Empty powder snow bucket1.ogg
|sound2=Empty powder snow bucket2.ogg
|subtitle=Bucket empties
|source=block
|description=When a powder snow bucket is placed
|id=item.bucket.empty_powder_snow
|translationkey=subtitles.item.bucket.empty
|volume=1.0
|pitch=''varies'' <ref group=sound>Each sound event can be 1.0, 0.95, or 1.1</ref>
|distance=16}}
{{Sound table
|sound=Fill powder snow bucket1.ogg
|sound2=Fill powder snow bucket2.ogg
|subtitle=Bucket fills
|source=player
|description=When a bucket is filled with powder snow
|id=item.bucket.fill_powder_snow
|translationkey=subtitles.item.bucket.fill
|volume=1.0
|pitch=''varies'' <ref group=sound>Each sound event can be 1.0, 0.9, or 1.1</ref>
|distance=16}}
{{Sound table
|sound=Powder Snow break1.ogg
|sound2=Powder Snow break2.ogg
|sound3=Powder Snow break3.ogg
|sound4=Powder Snow break4.ogg
|sound5=Powder Snow break5.ogg
|sound6=Powder Snow break6.ogg
|sound7=Powder Snow break7.ogg
|subtitle=Block broken
|source=block
|description=When a bucket is filled with powder snow
|id=block.powder_snow.break
|translationkey=subtitles.block.generic.break
|volume=1.0
|pitch=0.8
|distance=16
|foot=1}}
{{el|be}}:
{{Sound table
|type=bedrock
|sound=Fill powder snow bucket1.ogg
|sound2=Fill powder snow bucket2.ogg
|source=player
|description=When a bucket is filled with powder snow
|id=bucket.fill_powder_snow
|volume=1.0
|pitch=1.0}}
{{Sound table
|sound=Empty powder snow bucket1.ogg
|sound2=Empty powder snow bucket2.ogg
|source=block
|description=When a powder snow bucket is placed
|id=bucket.empty_powder_snow
|volume=1.0
|pitch=1.0
|foot=1}}
== Data values ==
=== ID ===
{{edition|java}}:
{{ID table
|edition=java
|showforms=y
|generatetranslationkeys=y
|displayname=Powder Snow Bucket
|spritetype=item
|nameid=powder_snow_bucket
|form=item
|foot=1}}
{{edition|bedrock}}:
{{ID table
|edition=bedrock
|shownumericids=y
|showforms=y
|showaliasids=y
|notshowbeitemforms=y
|generatetranslationkeys=y
|displayname=Powder Snow Bucket
|spritetype=item
|nameid=powder_snow_bucket
|aliasid=bucket / 11
|form=item
|id=368
|foot=1}}
== History ==
{{History|java}}
{{History||1.17|snap=20w46a|[[File:Powder Snow Bucket JE1 BE1.png|32px]] Added powder snow buckets.}}
{{History|bedrock}}
{{History||Caves & Cliffs<br>(experimental)|link=Bedrock Edition 1.17.0|snap=beta 1.16.210.53|[[File:Powder Snow Bucket JE1 BE1.png|32px]] Added powder snow buckets.
|The powder snow bucket replaced the powder snow block in the creative inventory.}}
{{History||1.17.0|snap=beta 1.17.0.50|Powder snow bucket are now available without enabling [[Experimental Gameplay]].}}
{{h|foot}}
== Issues ==
{{Issue list}}
==Gallery==
<gallery>
Cozy Cabin Powder Snow Bucket 1.jpg|Teaser image with a barely visible powder snow bucket.
Cozy Cabin Powder Snow Bucket 2.jpg|Teaser image with a barely visible powder snow bucket.
Cozy Cabin Powder Snow Bucket 3.jpg|Teaser image with a barely visible powder snow bucket.
</gallery>
{{Items}}
[[Category:Renewable resources]]
[[Category:Tools]]
[[de:Pulverschneeeimer]]
[[es:Cubo con nieve polvo]]
[[fr:Seau de neige poudreuse]]
[[it:Secchio di neve polverosa]]
[[ja:粉雪入りバケツ]]
[[pl:Wiadro sypkiego śniegu]]
[[pt:Balde de neve fofa]]
[[ru:Ведро с рыхлым снегом]]
[[zh:细雪桶]]</li><li>[[Pickaxe|Pickaxe]]<br/>{{Dungeons hatnote|type=weapon}}
{{Redirect|Diamond Pickaxe|the ''Minecraft Dungeons'' weapon|MCD:Diamond Pickaxe}}
{{Redirect|Pick|the block|Sea Pickle|the control|Controls#Pick Block|the joke block|Pickaxe Block}}
{{Item
| image = <gallery>
Wooden Pickaxe.png | Wooden
Stone Pickaxe.png | Stone
Iron Pickaxe.png | Iron
Golden Pickaxe.png | Golden
Diamond Pickaxe.png | Diamond
Netherite Pickaxe.png | Netherite
</gallery>
|rarity = Common
|renewable =
* '''Netherite''': No
* '''Others''': Yes
|durability =
Java Edition:
* Wood: 59
* Stone: 131
* Iron: 250
* Golden: 32
* Diamond: 1,561
* Netherite: 2,031
Bedrock Edition:
* Wood: 60
* Stone: 132
* Iron: 251
* Golden: 33
* Diamond: 1,562
* Netherite: 2,032
| stackable = No
}}
A '''pickaxe''' is a [[tools|tool]] required to mine [[ore]]s, [[rock|rocks]], rock-based blocks and metal-based [[block]]s quickly and obtain them as items. A pickaxe mines faster and can obtain more block types as items depending on the material it is made from.
== Obtaining ==
=== Crafting ===
Pickaxes are crafted using 2 [[stick]]s and 3 identical units of tool material.
{{crafting |showdescription=1 |showname=0 |head=1
|name=[[Pickaxe]]
|A1={Any Planks}; Iron Ingot; Gold Ingot; Diamond
|B1={Any Planks}; Iron Ingot; Gold Ingot; Diamond
|C1={Any Planks}; Iron Ingot; Gold Ingot; Diamond
|B2=Stick
|B3=Stick
|Output=Wooden Pickaxe; Iron Pickaxe; Golden Pickaxe; Diamond Pickaxe
|type=Tool
}}
{{Crafting
|name=[[Stone Pickaxe]]
|A1=Any stone-tier block |B1=Any stone-tier block |C1=Any stone-tier block
|B2=Stick
|B3=Stick
|Output=Stone Pickaxe
|description=Can use cobblestone and its other variants interchangeably.
|type=Tool
}}
{{crafting |foot=1 |ignoreusage=1
|name=[[Pickaxe]]
|ingredients=Matching Damaged [[Pickaxe]]s
|Damaged Wooden Pickaxe; Damaged Stone Pickaxe; Damaged Iron Pickaxe; Damaged Golden Pickaxe; Damaged Diamond Pickaxe; Damaged Netherite Pickaxe
|Damaged Wooden Pickaxe; Damaged Stone Pickaxe; Damaged Iron Pickaxe; Damaged Golden Pickaxe; Damaged Diamond Pickaxe; Damaged Netherite Pickaxe
|Output=Wooden Pickaxe; Stone Pickaxe; Iron Pickaxe; Golden Pickaxe; Diamond Pickaxe; Netherite Pickaxe
|description=The durability of the two pickaxes is added together, plus an extra 5% of the tool type's total durability.
|type=Tool
}}
=== Upgrading ===
{{Smithing
|head=1
|Netherite Upgrade
|Diamond Pickaxe
|Netherite Ingot
|Netherite Pickaxe
|tail=1
}}
=== Repairing ===
==== Grinding ====
{{grinding
|showdescription=1
|ingredients=Matching Damaged [[Pickaxe]]s
|Damaged Wooden Pickaxe; Damaged Stone Pickaxe; Damaged Iron Pickaxe; Damaged Golden Pickaxe; Damaged Diamond Pickaxe; Damaged Netherite Pickaxe
|Damaged Wooden Pickaxe; Damaged Stone Pickaxe; Damaged Iron Pickaxe; Damaged Golden Pickaxe; Damaged Diamond Pickaxe; Damaged Netherite Pickaxe
|Wooden Pickaxe; Stone Pickaxe; Iron Pickaxe; Golden Pickaxe; Diamond Pickaxe; Netherite Pickaxe
|description=The durability of the two pickaxes is added together, plus an extra 5% durability.
}}
==== Unit repair ====
{{main|Anvil mechanics#Unit repair}}
Pickaxes can be repaired in an [[anvil]] by adding units of the [[tiers|tier's]] repair material, with each repair material restoring 25% of the pickaxe's maximum durability, rounded down.
=== Natural generation ===
{{LootChestItem|wooden-pickaxe,stone-pickaxe,iron-pickaxe,level-enchanted-iron-pickaxe,random-enchanted-golden-pickaxe,level-enchanted-diamond-pickaxe,random-enchanted-diamond-pickaxe,damaged-random-enchanted-diamond-pickaxe}}
=== Trading ===
{{IN|bedrock}}, novice-level toolsmith [[Villager|villagers]] have a 25% chance to sell stone pickaxes for one [[emerald]], Journeyman-level toolsmith villagers have a 25% chance to sell enchanted iron pickaxes for 3 emeralds, and master-level toolsmith villagers always sell enchanted diamond pickaxes for 13 emeralds.
{{IN|java}}, novice-level toolsmith villagers have a 40% chance to sell a stone pickaxe for one emerald, journeyman-level toolsmith villagers have a 40% chance to sell an enchanted iron pickaxe for 7–22 emeralds, and a master-level toolsmith always sells an enchanted diamond pickaxe for 18–35 emeralds.
The enchantments are the same as the ones obtained from an [[enchantment table]] at levels 5–19.
=== Villager gifts ===
{{IN|JE}}, toolsmith [[villager]]s throw stone pickaxes at players under the [[Hero of the Village]] effect.
=== Mob loot ===
{{IN|BE}}, [[pillager]]s and [[vindicator]]s have a chance of dropping a damaged iron pickaxe when killed during a [[raid]]. The pickaxe has a 50% chance of being enchanted with random enchantment(s).
== Usage ==
=== Mining ===
A pickaxe is used to break stone and metal-based materials faster. Breaking a block with a pickaxe consumes one use (one durability point). No durability is consumed for blocks that break instantly. Pickaxes have different amounts of uses based on the type:
* Wooden: 60
* Stone: 132
* Iron: 251
* Golden: 33
* Diamond: 1562
* Netherite: 2032
Different qualities of pickaxe are required to successfully harvest certain ores and blocks. For example, while [[stone]] can be mined with any pickaxe, [[gold ore]] must be mined with an [[iron]], [[diamond]], or [[netherite]] pickaxe, or else the player harvests no ore. Different pickaxes also mine many materials at different speeds:
==== Speed ====
The following table shows the time it takes to break each type of block.
* A <span style="background-color:#FFC7CE;color:#9C0006;">red</span> background indicates that the block cannot be harvested with that type of pickaxe.
* A <span style="background-color:#FFFFDD;color:#8A7600;">yellow</span> background indicates that the block cannot be harvested with that type of pickaxe, but still drops something.
* A <span style="background-color:#C6EFCE;color:#006100;">green</span> background indicates that the block can be harvested with that type of pickaxe.
<!-- Table is sorted by hardness (mining time with diamond shows well), then by name -->
{|class="wikitable collapsible collapsed" data-description="Mining time by block" style="background-color: transparent;"
! Times to break blocks by pickaxe
|-
|
{{breaking row|sort=1|simple=1|Obsidian|Diamond}}
{{breaking row|Crying Obsidian|Diamond}}
{{breaking row|Respawn Anchor|Diamond}}
{{breaking row|Block of Netherite|Diamond}}
{{breaking row|Ancient Debris|Diamond}}
{{breaking row|Ender Chest|Wood}}
{{breaking row|Anvil|Wood}}
{{breaking row|Bell|Wood}}
{{breaking row|Block of Coal|Wood}}
{{breaking row|Block of Diamond|Iron}}
{{breaking row|Block of Emerald|Iron}}
{{breaking row|Block of Iron|Stone}}
{{breaking row|Block of Raw Copper|Stone}}
{{breaking row|Block of Raw Gold|Iron}}
{{breaking row|Block of Raw Iron|Stone}}
{{breaking row|Block of Redstone|Wood}}
{{breaking row|Chain|Wood}}
{{breaking row|Enchantment Table|Wood}}
{{breaking row|Iron Bars|Wood}}
{{breaking row|Iron Door|Wood|item=1|link=Door}}
{{breaking row|Iron Trapdoor|Wood|link=Trapdoor}}
{{breaking row|Monster Spawner|Wood}}
{{breaking row|Deepslate Coal Ore|Wood}}
{{breaking row|Deepslate Copper Ore|Wood}}
{{breaking row|Deepslate Diamond Ore|Wood}}
{{breaking row|Deepslate Emerald Ore|Wood}}
{{breaking row|Deepslate Gold Ore|Wood}}
{{breaking row|Deepslate Iron Ore|Wood}}
{{breaking row|Deepslate Lapis Lazuli Ore|Wood}}
{{breaking row|Deepslate Redstone Ore|Wood}}
{{breaking row|Blast furnace|Wood}}
{{breaking row|Cobbled Deepslate|Wood}}
{{breaking row|Chiseled Deepslate|Wood}}
{{breaking row|Deepslate Bricks|Wood}}
{{breaking row|Deepslate Tiles|Wood}}
{{breaking row|Polished Deepslate|Wood}}
{{breaking row|Dispenser|Wood}}
{{breaking row|Dropper|Wood}}
{{breaking row|Furnace|Wood}}
{{breaking row|Lantern|wood}}
{{breaking row|Lodestone|Wood}}
{{breaking row|Smoker|Wood}}
{{breaking row|Stonecutter|Wood}}
{{breaking row|Conduit}}
{{breaking row|Block of Gold|Iron}}
{{breaking row|Block of Lapis Lazuli|Stone}}
{{breaking row|Coal Ore|Wood}}
{{breaking row|Copper Ore|Wood}}
{{breaking row|Copper Blocks|Wood}}
{{breaking row|Cut Copper|Wood}}
{{breaking row|Cut Copper Slab|Wood}}
{{breaking row|Cut Copper Stairs|Wood}}
{{breaking row|Deepslate|Wood}}
{{breaking row|Dragon Egg
|note=<ref group="note">The dragon egg can be mined directly only when there aren't any air blocks available for it to teleport to. However, the dragon egg can be collected by other means.</ref>}}
{{breaking row|Diamond Ore|Iron}}
{{breaking row|Emerald Ore|Iron}}
{{breaking row|End Stone|Wood}}
{{breaking row|Gold Ore|Iron}}
{{breaking row|Hopper|Wood}}
{{breaking row|Iron Ore|Stone}}
{{breaking row|Lightning Rod|Wood}}
{{breaking row|Lapis Lazuli Ore|Stone}}
{{breaking row|Nether Quartz Ore|Wood}}
{{breaking row|Nether Gold Ore|Wood}}
{{breaking row|Observer|Wood}}
{{breaking row|Redstone Ore|Iron}}
{{breaking row|Blue Ice|drop=0}}
{{breaking row|Compound Creator|Wood|drop=1|note=<ref group="note" name="Chemtable">Chemistry tables are slow to break by hand, similar to blocks that require a pickaxe to mine. However, they still drop as items.</ref>}}
{{breaking row|Heat Block|Wood}}
{{breaking row|Grindstone|Wood}}
{{breaking row|Bone Block|Wood}}
{{breaking row|Brick Stairs|Wood|link=Stairs}}
{{breaking row|Bricks|Wood}}
{{breaking row|Cauldron|Wood}}
{{breaking row|Cobblestone|Wood}}
{{breaking row|link=Stairs|Cobblestone Stairs|Wood}}
{{breaking row|Cobblestone Wall|Wood}}
{{breaking row|Mossy Cobblestone|Wood}}
{{breaking row|Nether Bricks|Wood}}
{{breaking row|Nether Brick Fence|Wood}}
{{breaking row|link=Stairs|Nether Brick Stairs|Wood}}
{{breaking row|Red Nether Bricks|Wood}}
{{breaking row|Polished Blackstone|Wood}}
{{breaking row|link=Slab|Stone Slabs|sprite=all-slabs|Wood}}
{{breaking row|Smooth Stone|Wood}}
{{breaking row|Shulker Box}}
{{breaking row|Concrete|Wood}}
{{breaking row|Andesite|Wood}}
{{breaking row|Dark Prismarine|Wood}}
{{breaking row|Diorite|Wood}}
{{breaking row|Dripstone Block|Wood}}
{{breaking row|Granite|Wood}}
{{breaking row|Mud Bricks|Wood}}
{{breaking row|Pointed Dripstone}}
{{breaking row|Prismarine|Wood}}
{{breaking row|Prismarine Bricks|Wood}}
{{breaking row|Purpur block|Wood}}
{{breaking row|Purpur pillar|Wood}}
{{breaking row|Stone|Wood}}
{{breaking row|Stone Bricks|Wood}}
{{breaking row|Tuff|Wood}}
{{breaking row|link=Stairs|Stone Brick Stairs|Wood}}
{{breaking row|Amethyst Bud|drop=0}}
{{breaking row|Amethyst Cluster|drop=0}}
{{breaking row|Blackstone|Wood}}
{{breaking row|Block of Amethyst|Wood}}
{{breaking row|Budding Amethyst|drop=0}}
{{breaking row|Chiseled Polished Blackstone|Wood}}
{{breaking row|Polished Blackstone Bricks|Wood}}
{{breaking row|Gilded Blackstone|Wood}}
{{breaking row|Glazed Terracotta|Wood}}
{{breaking row|Terracotta|Wood}}
{{breaking row|Basalt|Wood}}
{{breaking row|Smooth Basalt|Wood}}
{{breaking row|Polished Basalt|Wood}}
{{breaking row|Packed Mud}}
{{breaking row|Block of Quartz|Wood}}
{{breaking row|Quartz Stairs|Wood|link=Stairs}}
{{breaking row|Red Sandstone|Wood}}
{{breaking row|Red Sandstone Stairs|Wood|link=stairs}}
{{breaking row|Sandstone|Wood}}
{{breaking row|Sandstone Stairs|Wood|link=stairs}}
{{breaking row|Calcite|Wood}}
{{breaking row|Rail}}
{{breaking row|Brewing Stand|Wood}}
{{breaking row|Stone Button|any}}
{{breaking row|Ice|drop=0}}
{{breaking row|Magma Block|Wood}}
{{breaking row|Packed Ice|drop=0}}
{{breaking row|Frosted Ice|drop=0}}
{{breaking row|Stone Pressure Plate|Wood}}
{{breaking row|Netherrack|Wood}}
{{breaking row|sprite=crimson-nylium|Nylium|Wood|foot=1}}
|}
=== Weapon ===
Hitting a mob with a pickaxe is a stronger attack than using fists. Pickaxes lose 2 durability when used as a weapon.
==== Java Edition ====
Pickaxes have an attack speed modifier of −2.8, meaning they take about 0.83 seconds to [[Damage#Attack cooldown|recover]]. All pickaxes have an attack speed of 1.2 hits per second. They deal different damage based on the type:
{|class="wikitable" style="text-align:center" data-description="Attack damage"
! Pickaxe type
! Attack damage
! Damage per<br> second (DPS)
|-
|{{ItemLink|Wooden Pickaxe}} ||rowspan=2 |{{hp|2}} ||rowspan=2 |2.4
|-
|{{ItemLink|Golden Pickaxe}}
|-
|{{ItemLink|Stone Pickaxe}} ||{{hp|3}} ||3.6
|-
|{{ItemLink|Iron Pickaxe}} ||{{hp|4}} ||4.8
|-
|{{ItemLink|Diamond Pickaxe}} ||{{hp|5}} ||6
|-
|{{ItemLink|Netherite Pickaxe}} ||{{hp|6}} ||7.2
|}
==== Bedrock Edition ====
{{IN|bedrock}}, pickaxes always attack instantly and do the following damage:
{|class="wikitable" style="text-align:center" data-description="Attack damage"
! Pickaxe type
! Attack damage
|-
|{{ItemLink|Wooden Pickaxe}}<br />{{ItemLink|Golden Pickaxe}} ||{{hp|3}}
|-
|{{ItemLink|Stone Pickaxe}} ||{{hp|4}}
|-
|{{ItemLink|Iron Pickaxe}} ||{{hp|5}}
|-
|{{ItemLink|Diamond Pickaxe}} ||{{hp|6}}
|-
|{{ItemLink|Netherite Pickaxe}} ||{{hp|7}}
|}
=== Enchantments ===
A pickaxe can receive the following [[enchantment]]s:
{|class="wikitable col-2-center col-3-right"
|+
!Name
!Max Level
![[Enchanting|Method]]
|-
|[[Efficiency]]
|V
|{{Inventory slot|Enchanting Table}}{{Inventory slot|Anvil}}
|-
|[[Fortune]]<ref group=note name=note1>Fortune and Silk Touch are mutually exclusive.</ref>
|III
|{{Inventory slot|Enchanting Table}}{{Inventory slot|Anvil}}
|-
|[[Silk Touch]]<ref group=note name=note1/>
|I
|{{Inventory slot|Enchanting Table}}{{Inventory slot|Anvil}}
|-
|[[Unbreaking]]
|III
|{{Inventory slot|Enchanting Table}}{{Inventory slot|Anvil}}
|-
|[[Mending]]
|I
|{{Inventory slot|Anvil}}
|-
|[[Curse of Vanishing]]
|I
|{{Inventory slot|Anvil}}
|}
{{Notelist}}
=== Fuel ===
Wooden pickaxes can be used as a fuel in [[furnace]]s, smelting 1 item per wooden pickaxe.
=== Smelting ingredient ===
{{Smelting|showname=1|Iron Pickaxe;Golden Pickaxe|Iron Nugget;Gold Nugget|0,1}}
===Piglins===
{{EntityLink|Piglin|Piglins}} are attracted to golden pickaxes and run toward any golden pickaxes on the ground, and inspect it for 6 to 8 seconds before putting it in their inventory.
== Sounds ==
{{edition|java}}:
{{Sound table
|sound=Random break.ogg
|subtitle=Item breaks
|source=player
|description=When a pickaxe's durability is exhausted
|id=entity.item.break
|translationkey=subtitles.entity.item.break
|volume=0.8
|pitch=0.8-1.2
|distance=16
|foot=1}}
{{edition|bedrock}}:
{{Sound table
|type=bedrock
|sound=Random break.ogg
|source=player
|description=When a shovel's durability is exhausted
|id=random.break
|volume=1.0
|pitch=0.9
|foot=1}}
== Data values ==
=== ID ===
{{edition|java}}:
{{ID table
|edition=java
|showforms=y
|generatetranslationkeys=y
|displayname=Wooden Pickaxe
|spritetype=item
|nameid=wooden_pickaxe
|form=item}}
{{ID table
|displayname=Stone Pickaxe
|spritetype=item
|nameid=stone_pickaxe
|form=item}}
{{ID table
|displayname=Iron Pickaxe
|spritetype=item
|nameid=iron_pickaxe
|form=item}}
{{ID table
|displayname=Diamond Pickaxe
|spritetype=item
|nameid=diamond_pickaxe
|form=item}}
{{ID table
|displayname=Golden Pickaxe
|spritetype=item
|nameid=golden_pickaxe
|form=item}}
{{ID table
|displayname=Netherite Pickaxe
|spritetype=item
|nameid=netherite_pickaxe
|form=item
|foot=1}}
{{edition|bedrock}}:
{{ID table
|edition=bedrock
|shownumericids=y
|showforms=y
|notshowbeitemforms=y
|generatetranslationkeys=y
|displayname=Wooden Pickaxe
|spritetype=item
|nameid=wooden_pickaxe
|id=310
|form=item}}
{{ID table
|displayname=Stone Pickaxe
|spritetype=item
|nameid=stone_pickaxe
|id=314
|form=item}}
{{ID table
|displayname=Iron Pickaxe
|spritetype=item
|nameid=iron_pickaxe
|id=297
|form=item}}
{{ID table
|displayname=Diamond Pickaxe
|spritetype=item
|nameid=diamond_pickaxe
|id=318
|form=item}}
{{ID table
|displayname=Golden Pickaxe
|spritetype=item
|nameid=golden_pickaxe
|id=324
|form=item}}
{{ID table
|displayname=Netherite Pickaxe
|spritetype=item
|nameid=netherite_pickaxe
|id=606
|form=item
|foot=1}}
== Achievements ==
{{Load achievements|Time to mine!;Getting an Upgrade;MOAR Tools ;Oooh, shiny!}}
== Advancements ==
{{load advancements|Getting an Upgrade;Isn't It Iron Pick;Stone Age;Oh Shiny}}
== Video ==
{{yt|G_HTViy2JTo}}
== History ==
{{History|java indev}}
{{History||0.31|snap=20100110|[[File:Iron Pickaxe JE1.png|32px]] Added iron pickaxes.
|A pickaxe is used to gather [[stone]] materials 400% faster than by hand.
|When starting in a new world, the [[player]] is given one of each [[tool]].}}
{{History|||snap=20100124|A complete tool set is no longer given to the player on starting a new world. Instead, there are multiple [[chest]]s in the later called "[[Indev House]]" containing a stack of most accessible [[blocks]]/[[items]] including [[tools]].}}
{{History|||snap=20100128|[[File:Wooden Pickaxe JE1 BE1.png|32px]] [[File:Stone Pickaxe JE1 BE1.png|32px]] [[File:Diamond Pickaxe JE1 BE1.png|32px]] Tools now have tiers. Wooden, stone, and diamond pickaxes have been added.|[[File:Iron Pickaxe JE2 BE1.png|32px]] The texture of iron pickaxes has been changed.
|A pickaxe held by the [[player]] is now rendered to appear more 3D.|They cannot be crafted yet, but have been added to the item chest in the Indev house.}}
{{History|||snap=20100129|Wood, stone, iron, and diamond pickaxes can now be [[craft]]ed.}}
{{History|||snap=20100130|[[File:Golden Pickaxe JE1.png|32px]] Pickaxes can now be made out of [[gold]].}}
{{History|||snap=20100201-1|Tools, including pickaxes, now take [[damage]] when being used. |Better tools, including pickaxes, now last longer.}}
{{History|||snap=20100201-2|Better pickaxes are now required to mine harder materials.}}
{{History||20100206|[[File:Golden Pickaxe JE2 BE1.png|32px]] The texture of golden pickaxes has been changed.}}
{{History|java beta}}
{{History||1.2|Before, the pickaxe had much less [[item durability|durability]] (usually half as much).
|Gold pickaxes now [[breaking|mine]] certain materials much faster.}}
{{History||1.8|snap=Pre-release|Iron pickaxes are now found in the new [[stronghold]] storeroom [[chest]]s, and in the new [[mineshaft]] chests.}}
{{History|java}}
{{History||1.0.0|snap=Beta 1.9 Prerelease 3|Iron pickaxes can now be found in the new [[stronghold]] altar [[chest]]s.}}
{{History|||snap=RC1|Pickaxes and other [[tool]]s now make a [[sound]] when they break.}}
{{History||1.1|snap=12w01a|Iron pickaxes are now found in the new [[village]] blacksmith chests.}}
{{History||1.2.4|snap=release|[[Spruce planks]], [[birch planks]], and [[jungle planks]] can now be used to craft wooden pickaxes.}}
{{History||1.3.1|snap=12w16a|Wooden and stone pickaxes are now found in the new [[bonus chest]]s.}}
{{History|||snap=12w18a|Wooden pickaxes can now be used as fuel in a [[furnace]].}}
{{History|||snap=12w21a|Blacksmith [[villager]]s now [[trading|sell]] 1 diamond pickaxe for 10–11 [[emerald]]s, and 1 iron pickaxe for 7–8 emeralds.}}
{{History||1.6.1|snap=13w21a|Instead of replacing the barehanded [[damage]] ({{hp|1}}), pickaxes now add their damage onto the barehanded damage, which results in all pickaxes doing {{hp|1}} more damage than before.}}
{{History||1.7.2|snap=1.7.1|[[Acacia planks]] and [[dark oak planks]] can now be used to craft wooden pickaxes.}}
{{History||1.8|snap=14w02a|Tool smith villagers now [[trading|sell]] 1 [[enchanting|enchanted]] diamond pickaxe for 12–15 emeralds, and 1 enchanted iron pickaxe for 9–11 emeralds.
|Unenchanted pickaxes are no longer sold by [[villager]]s.}}
{{History||1.9|snap=15w31a|Enchanted iron and diamond pickaxes can now be found in the [[end ship]] [[chest]]s in [[end city|end cities]].}}
{{History|||snap=15w34a|Pickaxes now use the "attack strength" combat mechanic meter. The time it takes for the meter to fill up for a pickaxe is 0.8 seconds.}}
{{History|||snap=15w34c|Pickaxes now do less [[damage]], but recover quicker.}}
{{History|||snap=15w35a|Pickaxes now recover more slowly.}}
{{History|||snap=15w44a|The average yield of wood and stone pickaxes in [[bonus chest]]s has been decreased.
|The average yield of iron pickaxes in [[mineshaft]] [[chest]]s has been increased.}}
{{History||1.11.1|snap=16w50a|Golden and iron pickaxes can now be [[smelting|smelted]] down into one of their respective [[nugget]]s.}}
{{History||1.13|snap=17w47a|Prior to [[1.13/Flattening|''The Flattening'']], these [[item]]s' numeral IDs were 270, 274, 257, 278 and 285.}}
{{History||1.14|snap=18w43a|[[File:Wooden Pickaxe JE2 BE2.png|32px]] [[File:Stone Pickaxe JE2 BE2.png|32px]] [[File:Iron Pickaxe JE3 BE2.png|32px]] [[File:Golden Pickaxe JE3 BE2.png|32px]] [[File:Diamond Pickaxe JE2 BE2.png|32px]] The textures of all pickaxes have been changed.}}
{{History|||snap=18w50a|Iron pickaxes can now be found in chests in [[village]] toolsmith houses.}}
{{History|||snap=19w11a|Toolsmith [[villager]]s now [[trading|sell]] stone pickaxes.}}
{{History|||snap=19w13a|Toolsmith villagers now give stone pickaxes to players under the [[Hero of the Village]] effect.}}
{{History||1.16|snap=20w06a|[[File:Netherite Pickaxe JE1.png|32px]] Added netherite pickaxes.
|Netherite pickaxes are obtained by combining one diamond pickaxe and one netherite ingot in a crafting table.
|[[Crimson planks]] and [[warped planks]] can now be used to craft wooden pickaxes.}}
{{History|||snap=20w09a|[[File:Wooden Pickaxe JE3 BE3.png|32px]] [[File:Golden Pickaxe JE4 BE3.png|32px]] [[File:Diamond Pickaxe JE3 BE3.png|32px]] [[File:Netherite Pickaxe JE2 BE1.png|32px]] The textures of wooden, golden, diamond, and netherite pickaxes have been changed.}}
{{History|||snap=20w10a|[[File:Netherite Pickaxe JE3.png|32px]] Changed a pixel of the texture of netherite pickaxes.
|Netherite pickaxes can no longer be crafted.
|Netherite pickaxes are now obtained by combining one diamond pickaxe and one netherite ingot in a smithing table.}}
{{History|||snap=20w15a|Stone pickaxes can now be crafted using [[blackstone]].}}
{{History|||snap=20w16a|Golden pickaxes now generate randomly enchanted in [[ruined portal]] chests.}}
{{History||1.16.2|snap=20w30a|Randomly enchanted diamond pickaxes can now be found in [[bastion remnant]] chests.}}
{{History||1.17|snap=21w08a|Stone pickaxe can now be crafted using [[cobbled deepslate]].}}
{{History||1.19|snap=22w11a|[[Mangrove planks]] can now be used to craft wooden pickaxes.}}
{{History||1.20<br>(Experimental)|link=1.19.4|snap=23w04a|Upgrading diamond pickaxes to netherite pickaxes now requires the netherite upgrade [[smithing template]].}}
{{History|upcoming java}}
{{History||Villager Trade Rebalance<br>(Experimental)|link=Java Edition 1.20.2|snap=23w31a|[[Wandering trader]]s now have a chance to sell an enchanted iron pickaxe.}}
{{History||Combat Tests|snap=1.14.3 - Combat Test|The attack speed for all pickaxes has been increased to 2.5.
|The [[damage]] for all pickaxes has been increased by {{hp|1}}.}}
{{History|pocket alpha}}
{{History||v0.2.0|[[File:Stone Pickaxe JE1 BE1.png|32px]] Added stone pickaxes.}}
{{History||v0.3.0|[[File:Wooden Pickaxe JE1 BE1.png|32px]] Added wooden pickaxes.
|Survival players no longer start out with an infinite durability stone pickaxe in the inventory.}}
{{History||v0.3.2|[[File:Iron Pickaxe JE2 BE1.png|32px]] [[File:Golden Pickaxe JE2 BE1.png|32px]] [[File:Diamond Pickaxe JE1 BE1.png|32px]] Added iron, gold, and diamond pickaxes.}}
{{History||v0.4.0|Removed stone pickaxes from the creative inventory.}}
{{History||v0.11.0|snap=build 11|All pickaxes are now available in the [[creative]] inventory.}}
{{History|||snap=build 12|All pickaxes have been removed from creative.}}
{{History|||snap=build 13|Pickaxes have been re-added to creative mode.}}
{{History||v0.14.0|snap=build 1|Iron pickaxes can now be found inside [[minecart with chest]]s in [[mineshaft]]s.}}
{{History|pocket}}
{{History||1.0.0|snap=alpha 0.17.0.1|[[Enchanting|Enchanted]] iron pickaxes and enchanted diamond pickaxes can now be found in [[end city|end cities]].}}
{{History||1.0.4|snap=alpha 1.0.4.0|Toolsmith [[villager]]s now [[trading|sell]] enchanted diamond pickaxes for 12-15 emeralds as their last tier trades and enchanted iron pickaxes for 9-11 [[emerald]]s as their second tier trades.}}
{{History||1.1.0|snap=alpha 1.1.0.0|Iron and golden pickaxes are now [[smelting|smeltable]].}}
{{History|bedrock}}
{{History||1.2.0|snap=beta 1.2.0.2|Wooden and stone pickaxes can now be found inside [[bonus chest]]s.}}
{{History||1.10.0|snap=beta 1.10.0.3|Iron pickaxes can now be found in [[plains]] [[village]] weaponsmith houses.
|[[File:Wooden Pickaxe JE2 BE2.png|32px]] [[File:Stone Pickaxe JE2 BE2.png|32px]] [[File:Iron Pickaxe JE3 BE2.png|32px]] [[File:Golden Pickaxe JE3 BE2.png|32px]] [[File:Diamond Pickaxe JE2 BE2.png|32px]] The textures of all pickaxes have been changed.}}
{{History||1.11.0|snap=beta 1.11.0.1|Iron pickaxes can now be found in [[village]] toolsmiths [[chest]]s and in [[savanna]], [[taiga]], [[snowy taiga]] and [[desert]] village weaponsmith chests.}}
{{History|||snap=beta 1.11.0.4|[[Trading]] has been changed, toolsmith [[villager]]s now have a 25% chance to [[trading|sell]] an [[enchanting|enchanted]] iron pickaxe for 3 [[emerald]]s as part of their third tier trades, and an enchanted diamond pickaxe now costs 13 emeralds.
|Stone pickaxes can now be bought from toolsmith villagers.}}
{{History||1.16.0|snap=beta 1.16.0.51|[[File:Netherite Pickaxe JE2 BE1.png|32px]] Added netherite pickaxes.|Netherite pickaxes are obtained by combining one diamond pickaxe and one netherite ingot in a crafting table.
|[[File:Wooden Pickaxe JE3 BE3.png|32px]] [[File:Golden Pickaxe JE4 BE3.png|32px]] [[File:Diamond Pickaxe JE3 BE3.png|32px]] The textures of wooden, golden, and diamond pickaxes have been changed.}}
{{History|||snap=beta 1.16.0.57|Netherite pickaxes can no longer be crafted.
|Netherite pickaxes are now obtained by combining one diamond pickaxe and one netherite ingot in a smithing table.
|Stone pickaxes can now be crafted using [[blackstone]].
|Golden pickaxes now generate randomly enchanted in [[ruined portal]] chests.
|Netherite pickaxe now generate randomly enchanted in [[bastion remnant]] chest.}}
{{History||1.17.10|snap=beta 1.17.10.20|[[File:Netherite Pickaxe JE3.png|32px]] Changed a pixel of the texture of netherite pickaxes to match ''Java Edition''.}}
{{History|console}}
{{History||xbox=TU1|xbone=CU1|ps=1.0|wiiu=Patch 1|[[File:Wooden Pickaxe JE1 BE1.png|32px]] [[File:Stone Pickaxe JE1 BE1.png|32px]] [[File:Iron Pickaxe JE2 BE1.png|32px]] [[File:Golden Pickaxe JE2 BE1.png|32px]] [[File:Diamond Pickaxe JE1 BE1.png|32px]] Added pickaxes (all five types).}}
{{History||xbox=TU53|xbone=CU43|ps=1.49|wiiu=Patch 23|switch=1.0.3|Iron and golden pickaxes are now [[smelting|smeltable]].}}
{{History|Ps4}}
{{History||1.90|[[File:Wooden Pickaxe JE2 BE2.png|32px]] [[File:Stone Pickaxe JE2 BE2.png|32px]] [[File:Iron Pickaxe JE3 BE2.png|32px]] [[File:Golden Pickaxe JE3 BE2.png|32px]] [[File:Diamond Pickaxe JE2 BE2.png|32px]] The textures of all pickaxes have been changed.}}
{{History|New Nintendo 3DS Edition}}
{{History||0.1.0|[[File:Wooden Pickaxe JE1 BE1.png|32px]] [[File:Stone Pickaxe JE1 BE1.png|32px]] [[File:Iron Pickaxe JE2 BE1.png|32px]] [[File:Golden Pickaxe JE2 BE1.png|32px]] [[File:Diamond Pickaxe JE1 BE1.png|32px]] Added pickaxes.}}
{{History|foot}}
== Issues ==
{{issue list}}
== Trivia ==
*The golden pickaxe is the only pickaxe that is unable to harvest the material it is made from.
*The pickaxe is the only block-breaking tool without a {{control|use}} (right-click) function.
=== Publicity ===
*Plastic diamond pickaxes are official ''[[Minecraft]]'' merchandise.<ref>https://shop.minecraft.net/products/minecraft-pickaxe?_pos=3&_psq=pickaxe&_ss=e&_v=1.0</ref>
*In the game [[wikipedia:Naughty Bear: Panic in Paradise|''Naughty Bear: Panic in Paradise'']], the player can buy a diamond pickaxe which, according to the game, is made by "Kick it up a Notch Pickaxes", referring to [[Notch]].
*In mobile game ''[https://play.google.com/store/apps/details?id=br.com.tapps.vloggergoviral Vlogger Go Viral]'' clicker game, after buying the figurine shelf, there is a model of a diamond pickaxe stuck to a [[grass block]].
*In the game [[wikipedia:The Elder Scrolls V: Skyrim|''The Elder Scrolls V: Skyrim'']], the player can find a pickaxe called the "Notched Pickaxe", evidently an [[easter egg]].
*In the game [[wikipedia:Offensive Combat|''Offensive Combat'']], a stone pickaxe can be used as a melee weapon with the name of "The Notch Carver".
*In the game [[wikipedia:The Binding of Isaac (video game)|''The Binding of Isaac'']], an obtainable item named "Notched Axe", also with a drawn 8-bit look, can be used to destroy rocks. The Notched Axe also makes a return in the game's remake, [[wikipedia:The Binding of Isaac: Rebirth|''The Binding of Isaac: Rebirth'']].
*In the game [[wikipedia:Borderlands 2|''Borderlands 2'']], the player can find a secret area hidden away by blocks resembling Minecraft [[dirt]], also once inside the player can fight Creeper and the Mother Creeper to get rare Minecraft-related skins.
*In the game [[wikipedia:Octodad: Dadliest Catch|''Octodad: Dadliest Catch'']], the supermarket level has a "Mintcraft" display, an obvious parody of Minecraft, even including toy pickaxes and a creeper head.
*In the game [[wikipedia:Transformice|''Transformice'']], a diamond pickaxe can be found in the shop.
== Gallery ==
<gallery>
File:Pickaxe in Mineshaft Chest.png|A naturally generated pickaxe.
Live in Your World JINX.jpg|Official T-shirt artwork "Live in Your World" featuring an iron pickaxe made by [https://www.jinx.com JINX].
Pickaxe JINX.jpg|Official T-shirt artwork of a pickaxe made by JINX.
Stone Pickaxe SDGP.png|Stone pickaxe in the [[Super Duper Graphics Pack]].
Iron Pickaxe SDGP.png|Iron pickaxe in the [[Super Duper Graphics Pack]].
</gallery>
=== Enchanted pickaxes ===
<gallery>
Enchanted Wooden Pickaxe.gif
Enchanted Stone Pickaxe.gif
Enchanted Iron Pickaxe.gif
Enchanted Golden Pickaxe.gif
Enchanted Diamond Pickaxe.gif
Enchanted Netherite Pickaxe.gif
</gallery>
== References ==
{{reflist}}
== External Links ==
*[https://www.minecraft.net/en-us/article/taking-inventory-pickaxe Taking Inventory: Pickaxe] – Minecraft.net on May 10, 2018
{{items}}
[[Category:Combat]]
[[cs:Krumpáč]]
[[de:Spitzhacke]]
[[es:Pico]]
[[fr:Pioche]]
[[hu:Csákány]]
[[it:Piccone]]
[[ja:ツルハシ]]
[[ko:곡괭이]]
[[nl:Houweel]]
[[pl:Kilof]]
[[pt:Picareta]]
[[ru:Кирка]]
[[th:อีเต้อ]]
[[uk:Кайло]]
[[zh:镐]]</li></ul> | 18w15a | Added dolphins. | |||
| Upcoming Bedrock Edition | |||||
1.4{{Extension DPL}}<ul><li>[[Cooked Cod|Cooked Cod]]<br/>{{redirect|Cooked Fish|cooked salmon|Cooked Salmon}}
{{Item
| title = Cooked Cod
| image = Cooked Cod.png
| renewable = Yes
| heals = {{hunger|5}}
| stackable = Yes (64)
}}
'''Cooked cod''' is a food item obtained by cooking [[raw cod]].
== Obtaining ==
=== Mob loot ===
====Cod====
[[Cod]] always drops 1 [[Raw Cod|raw cod]] when killed, unaffected by Looting.<ref>{{bug|MC-212795||Salmon & Fish mobs are not affected by Looting}}</ref> If it is killed while on [[fire]], it drops 1 cooked cod instead.
====Dolphins ====
When killed, [[Dolphin|dolphins]] drop 0–1 raw cod. The maximum amount is increased by 1 per level of [[Looting]], for a maximum of 0-4 with Looting III. If killed while on fire, they drop cooked cod instead.
====Guardians and elder guardians====
[[Guardian]]s and [[elder guardian]]s have a 40% and 50% chance, respectively, to drop raw cod when killed. {{IN|java}}, cooked cod is dropped if a guardian is on fire when killed.
Guardians and elder guardians also drop a 2.5% chance to drop a random fish, with 60% of them being raw cod, which drops as cooked if the guardian was on fire. The chance of getting the fish drop is increased by 1% per level with [[Looting]] (for a maximum of 5.5% with Looting III), but the type of fish is not affected.
====Polar bears====
[[Polar bear]]s have a 75% chance of dropping 0–2 raw cod when killed. The maximum amount can be increased by 1 per level of Looting, for a maximum of 0-5 with Looting III. If killed while on fire, they drop cooked cod instead.
===Chest loot===
{{LootChestItem|cooked-cod}}
===Cooking===
Cooked cod can be obtained by cooking [[raw cod]] in a [[furnace]], [[smoker]], or [[campfire]].
{{smelting|Raw Cod|Cooked Cod|0,35}}
===Trading===
Novice-level Fisherman [[Villager|villagers]] have a 50% chance to sell 6 cooked cod for 6 raw cod and 1 [[emerald]].
== Usage ==
=== Food ===
To eat cooked cod, press and hold {{control|use}} while it is selected in the hotbar. Eating one restores {{hunger|5}} [[hunger]] and 6 hunger [[Hunger#Mechanics|saturation]].
=== Wolves ===
{{IN|Bedrock}}, cooked cod can be used to feed a wolf not at full health, healing by {{hp|5|mob=1}}. However, unlike other wolf food, cooked cod cannot be used to speed up the growth of baby wolves nor used to breed them.
==Sounds==
{{Sound table/Entity/Food}}
== Data values ==
=== ID ===
{{edition|java}}:
{{ID table
|edition=java
|showitemtags=y
|showforms=y
|generatetranslationkeys=y
|displayname=Cooked Cod
|spritetype=item
|nameid=cooked_cod
|itemtags=fishes
|form=item
|foot=1}}
{{edition|bedrock}}:
{{ID table
|edition=bedrock
|shownumericids=y
|showforms=y
|showaliasids=y
|notshowbeitemforms=y
|generatetranslationkeys=y
|displayname=Cooked Cod
|spritetype=item
|nameid=cooked_cod
|aliasid=cooked_fish
|id=268
|form=item
|translationkey=item.cooked_fish.name
|foot=1}}
== Achievements ==
{{load achievements|Delicious Fish}}
== Advancements ==
{{load advancements|Husbandry;A Balanced Diet}}
== Video ==
<div style="text-align:center">{{yt|nPl0HUGPMcA}}</div>
== History ==
{{History|java alpha}}
{{History||v1.2.0|snap=<nowiki>?|slink=:Category:Information needed requiring unarchived version|[[File:Cooked Cod JE1 BE1.png|32px]] Added cooked fish, which restores {{hp|5}}.}}
{{History|java beta}}
{{History||1.5|Cooking fish now gives the '''Delicious Fish''' [[achievement]].}}
{{History||1.8|snap=Pre-release|Cooked fish is now stackable to 64.
|Cooked fish now fills {{hunger|5}} instead of {{hp|5}}.}}
{{History|java}}
{{History||1.3.1|snap=12w21a|Farmer [[villager]]s now [[trading|buy]] 9–12 cooked fish for 1 [[emerald]].}}
{{History||1.8|snap=14w02a|[[Trading]] has been changed: fisherman [[villager]]s now [[trading|sell]] 6 cooked fish for 1 [[emerald]] plus 6 [[raw cod|raw fish]].
|Farmer villagers no longer buy cooked fish.}}
{{History|||snap=14w04a|The name of cooked fish has been corrected from <code>cooked_fished</code> to <code>cooked_fish</code>.}}
{{History|||snap=14w25a|Cooked fish are now obtainable rare [[drops]] from [[guardian]]s and [[elder guardians]].}}
{{History||1.13|snap=17w47a|The different data values for the <code>cooked_fish</code> IDs have been split up into their own IDs.
|"Cooked Fish" have been renamed to "Cooked Cod".
|Prior to [[1.13/Flattening|''The Flattening'']], these [[item]]s' numeral ID were 349 and 350.}}
{{History|||snap=18w08b|[[Cod]], and other [[fish]], have been added as [[mob]]s, which [[drops|drop]] their cooked [[item]] form when killed with [[fire]].
|[[File:Cooked Cod JE2 BE2.png|32px]] The texture of cooked cod has been changed.}}
{{History|||snap=18w10a|Cooked cod now generates in [[buried treasure]] [[chest]]s.}}
{{History||1.14|snap=18w43a|[[File:Cooked Cod JE3.png|32px]] The texture of cooked cod has been changed.}}
{{History|||snap=18w47b|[[File:Cooked Cod JE4 BE3.png|32px]] The texture of cooked cod has been changed, once again to match {{el|be}}.}}
{{History|pocket alpha}}
{{History||v0.11.0|snap=build 1|[[File:Cooked Cod JE1 BE1.png|32px]] Added cooked fish.}}
{{History||v0.12.1|snap=build 1|Cooked fish now restores [[hunger]] instead of [[health]].}}
{{History||v0.16.0|snap=build 1|Cooked fish is now [[drops|dropped]] by [[guardian]]s and [[elder guardian]]s.}}
{{History|pocket}}
{{History||1.0.4|snap=alpha 1.0.4.0|Fisherman [[villager]]s now [[trading|sell]] 6 cooked fish for 1 [[emerald]] plus 6 [[raw cod|raw fish]].}}
{{History|bedrock}}
{{History||1.4.0|snap=beta 1.2.14.2|[[Cod]] and other [[fish]] have been added as [[mob]]s, which [[drops|drop]] their cooked [[item]] form when killed with [[fire]].
|[[File:Cooked Cod JE2 BE2.png|32px]] The texture of cooked fish has been changed.}}
{{History||1.5.0|snap=beta 1.5.0.4|[[File:Cooked Cod JE4 BE3.png|32px]] The texture of cooked fish has been changed.}}
{{History||1.7.0|snap=beta 1.7.0.2|"Cooked Fish" has been renamed to "Cooked Cod".}}
{{History||1.11.0|snap=beta 1.11.0.4|Fisherman [[villager]]s now have a 50% chance to [[trading|sell]] 6 cooked cod for 6 [[raw cod]] and 1 [[emerald]].}}
{{History||1.16.100|snap=beta 1.16.100.52|Cod now drop their cooked cod when killed with fire.}}
{{History|console}}
{{History||xbox=TU1|xbone=CU1|ps=1.0|wiiu=Patch 1|[[File:Cooked Cod JE1 BE1.png|32px]] Added cooked fish.}}
{{History||xbox=TU5|Cooked fish is now stackable to 64.
|Cooked fish now fills [[hunger]] instead of [[health]].}}
{{History||xbox=TU69|ps=1.76|wiiu=Patch 38|"Cooked Fish" has been renamed to "Cooked Cod".
|[[File:Cooked Cod JE2 BE2.png|32px]] The texture of cooked cod has been changed.}}
{{History|new 3ds}}
{{History||0.1.0|[[File:Cooked Cod JE1 BE1.png|32px]] Added cooked fish.}}
{{History|foot}}
== Issues ==
{{Issue list}}
{{Items}}
[[Category:Food]]
[[Category:Renewable resources]]
[[de:Gebratener Kabeljau]]
[[es:Bacalao cocinado]]
[[ko:익힌 대구]]
[[pt:Bacalhau assado]]
[[ru:Жареная треска]]
[[th:Cod (ไอเทม)]]
[[zh:熟鳕鱼]]</li><li>[[Ankle Monitor|Ankle Monitor]]<br/>{{Joke feature}}
{{Item
| title = Ankle Monitor
| image = Ankle Monitor.png
| renewable = No
| stackable = Yes (64)
}}
The '''Ankle monitor''' was a joke foot item.
== Usage ==
Ankle monitors were equipped in the boots slot. In survival mode, when equipped, it could not be taken off. However, players in Creative mode are unaffected.
When equipped, the player would be afflicted with {{EffectLink|Slowness}} I.
During the night, being a certain number of blocks from the world spawn, above a certain minimum,{{checkthecode|how much?}} would prompt the following message in chat: "CURFEW WARNING! You are violating your house arrest! Get back by [distance] meters!"
If in [[the Nether]] or [[the End]], a different set of messages would be cycled through which can be seen in the section below.
=== Nether and End messages ===
* CURFEW WARNING! You are violating your house arrest! Uuuh... where are you anyway?
* CURFEW WARNING! Hello, are you there?
* CURFEW WARNING! I'm sure you have important things to do, but you need to go back!
* CURFEW WARNING! We're lonely back home!
* CURFEW WARNING! By "we" I mean I. I'm lonely.
* CURFEW WARNING! Ok enough games... GET BACK RIGHT NOW!
* CURFEW WARNING! LAST WARNING!
* CURFEW WARNING! LASTEST WARNING (really now)
* CURFEW WARNING! ...
* CURFEW WARNING! So... Where are you?
* CURFEW WARNING! Having a good day?
* CURFEW WARNING! Did you see that monster over there?
* CURFEW WARNING! Give it a whack, if you would be so kind.
* CURFEW WARNING! Teheee...
* CURFEW WARNING! Ok, enough of this!
* CURFEW WARNING! Last straw!
* CURFEW WARNING! Now you die.
* CURFEW WARNING! Boom!
* CURFEW WARNING! Hehe, fun right?
* CURFEW WARNING! Ok, you will not hear anything more from me now!
* CURFEW WARNING! You'll be as lonely as I am.
* CURFEW WARNING! How does that feel?
* CURFEW WARNING! I know, I'll wipe my memory. That way, I can start over!
* CURFEW WARNING! *bzzzzttt*
== Sounds ==
{{Sound table
|sound=Robot1arm1.ogg
|sound2=Robot1arm2.ogg
|sound3=Robot1arm3.ogg
|sound4=Robot1arm4.ogg
|source=dependent
|subtitle=''None''
|description=When a notification is displayed
|id=item.ankle_monitor.warning
|translationkey=''None''
|volume=1.0
|pitch=1.0
|distance=16
|foot=1}}
== Data values ==
=== ID ===
{{ID table
|shownumericids=y
|showforms=y
|generatetranslationkeys=java
|displayname=Ankle Monitor
|spritetype=item
|nameid=ankle_monitor
|id=501
|form=item
|translationkey=item.ankleMonitor.name
|foot=1}}
== History ==
{{History|java}}
{{History||1.RV-Pre1|[[File:Ankle_Monitor_(item).png|32px]] [[File:Ankle Monitor.png|32px]] Added ankle monitors.}}
{{History||1.11|snap=16w39a|The inability to remove ankle monitors was somewhat implemented into the canonical game through the addition of [[Curse of Binding]].<ref>{{ytl|Vm6oplvyyh0|t=3m31s}}</ref>}}
{{History|foot}}
== Issues ==
Ankle monitors are an unsupported [[item]] due to being an [[Wikipedia:April Fools' Day|April Fools']] joke, and therefore such issues relating to them will not be fixed.
== Gallery ==
<gallery>
TechGear.png|A [[player]] wearing the gear featured in this [[wikipedia:April Fools' Day|April Fools']] joke version.
</gallery>
==References==
{{Reflist}}
{{Items}}
{{Jokes}}
[[Category:Non-renewable resources]]
[[Category:Joke items]]
[[es:Ankle monitor]]</li></ul></nowiki> | 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.
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 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
- 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)
- 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
- 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.
- 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)
- Mock-up #1
| 1.0 Ender Update |
| ||
|---|---|---|---|
| 1.1 Discovery Update |
| ||
Better Together Update |
| ||
| 1.4 Update Aquatic (Part 1) |
| ||
| 1.5 Update Aquatic (Part 2) |
| ||
| 4K Update | |||
- Mock-up #2
| 1.0 Ender Update |
| ||
|---|---|---|---|
| 1.1 Discovery Update |
| ||
Better Together Update |
| ||
| 1.4 Update Aquatic (Part 1) |
| ||
| 1.5 Update Aquatic (Part 2) |
| ||
| 4K Update | |||
- 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)
- 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
- 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)
- 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)
- English wiki deletes mod articles.
- English wiki removes mod support from templates/modules.
- A non-English wiki (Wiki X) decided to keep their mod articles and use the original template/module versions.
- 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)
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)
- Vanilla supports mod content via namespaces (vanilla uses
- 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)
- 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
- @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)
- 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)
- 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
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)
- 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=andarchivedate=parameters? – Auldrick (talk · contribs) 17:33, 9 May 2018 (UTC)- Answer I was thinking it could be used in place of the
reftag, so it would be used anywhere thereftag could be used. Also it could havearchivedateand maybe aurldeadparameter 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)
- Answer I was thinking it could be used in place of the
- 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)
- 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)
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
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)
- 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)
- 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
- 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)
- Jjlrjjlr, the turtle shell page does not mention enchantments. Could you please list the enchantments available on a turtle shell? The Blobs
- 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:
- We have a Discord server intended for wiki users and just interested community members.
- It's not prominently linked anywhere (such as on the community portal).
- There has been no discussion behind its creation.
- 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:
- Does the wiki need a Discord server?
- 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)
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)
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)
- 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:
- @Nixinova: To clarify, where on the page would
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 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
- 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)
- – Jack McKalling [
- 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)
- 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 [
- 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
Madminecrafter12 for admin?
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)
- 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
- 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)
- 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
- 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)
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 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 – 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.
- Rewrite - In my opinion, that may not be quite necessary. You could just use
- 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)
- 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
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)
- 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
- @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)
- 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
- @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)
- @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
- 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)
- Oh, darn. :(-- Madminecrafter12
- 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)
- 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
- 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))
- 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
- 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)
- 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
- 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)
- 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)
- Besides those things, this sounds like a good idea. Thanks for bringing it up, Jjlrjjlr!-- Madminecrafter12
- 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)
- @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
- 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)
- 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
- 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 [Bedrock and Java editions only][upcoming: Lua error in Module:Version_link at line 112: attempt to concatenate local 'text' (a nil value).] - A digression: lately I've toyed with the idea of a single template that accomplished something like:[Bedrock & upcoming Java Edition 1.13 only] -- 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)
- 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
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:
The userspace is all articlesAccording to my knowledge, "articles" is typically reserved to refer to content namespace pages. I suggest replacing "articles" with "pages" in this sentence.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.articles that would not belong in the mainspace— similar to #1, but not exactly the same, I'm not sure this should be changed.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?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.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.please provide a link to the discussionor 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:
- Fixed
- Fixed
- In this case articles makes most sense. Its for things like User:KnightMiner/1.7.banana
- 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.
- Fixed
- Fixed
- 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)
- Overall I would be in favor of implementing it if there is enough support. As for specific comments:
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:
- Don't have any images at all for maintenance templates. Remove the existing ones, and don't add images to any of the others.
- 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. - 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)
- 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 [
- 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 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
- ...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.[1]
- Three updates are currently planned out for minecraft, more information will be unveiled at Minecon Earth 2018.[2]
- 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.[3]
- The official modding API is still planned and being developed, it will supposedly be coming to bedrock edition before java.[4].
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)
Page locks to signal protection
This was proposed about a week ago and it only got a few responses, so I'm starting a new community portal topic. The original discussion can be seen at Template talk:Protected.
So basically, AttemptToCallNil and I came up with the idea to have locks as indicators in the top right corner of any protected page. How it would work is for each level of protection, it will show a different lock color, title, link, and category. A demonstration of this can be seen in my sandbox. The reasons I think locks should be used is because the current {{protected}} template is kind of distracting and it's not really clear where to use it. It seems to be used on only a few pages, and is kind of big, making it distracting to readers. Also, it would be confusing if it were used on templates, as readers may think that it's the actual template, rather than signifying a state that applies to the template. However, using locks instead would solve all these problems - just simply add the template to pages that are protected in any way at any level. I haven't come across any problems so far with my experimenting, although I'm sure there's something.
Anybody who wants to discuss is welcome to do so either here or at Template talk:Protected. This will be quite a big change, so it would be nice to have some feedback and opinions. =)-- Madminecrafter12
Talk to me
20:04, 2 June 2018 (UTC)
- Support - Wikipedia does the exact same thing and I don't see why we shouldn't. --Marioprotvi (talk) 20:12, 2 June 2018 (UTC)
- Well, this idea seems to be fully supported with no opposition. The question is, what do we do now? Should we wait till somebody finds a way to add the template to every page automatically, or go ahead and move it to the template namespace? (I support the second). But if we do the second, should we move it to a temporary title (such as Template:Protected 2) as a work-in-progress until we have the details worked out and possibly found an automatic way to add it? Or should we go ahead and delete the current Template:Protected (obviously removing the pages that use it as well) and move my sandbox to that title?-- Madminecrafter12
Talk to me
14:07, 7 June 2018 (UTC)
- Well, this idea seems to be fully supported with no opposition. The question is, what do we do now? Should we wait till somebody finds a way to add the template to every page automatically, or go ahead and move it to the template namespace? (I support the second). But if we do the second, should we move it to a temporary title (such as Template:Protected 2) as a work-in-progress until we have the details worked out and possibly found an automatic way to add it? Or should we go ahead and delete the current Template:Protected (obviously removing the pages that use it as well) and move my sandbox to that title?-- Madminecrafter12
- Lets figure out first how to add the template to every page automatically. If a new template is introduced before it's achieved its goal, people will start using it wrongly, introducing even more overhead work. And removing the use of the current template from pages leaves those pages (as it currently works now) without any visual clue as to the protection level. So, how can a template be transcluded automatically on a page, depending on some parser function criteria? – Jack McKalling [
] 14:20, 7 June 2018 (UTC)
- Lets figure out first how to add the template to every page automatically. If a new template is introduced before it's achieved its goal, people will start using it wrongly, introducing even more overhead work. And removing the use of the current template from pages leaves those pages (as it currently works now) without any visual clue as to the protection level. So, how can a template be transcluded automatically on a page, depending on some parser function criteria? – Jack McKalling [
- By the way, page status indicators for protection levels are already limitedly used on the Russian wiki and even referenced in the page protection guidelines. I don’t think we will ever get a working automatic protection indicator only using wikitext/template means, in my vision it necessarily needs some JavaScript code (and I’m not used to program in JS). The question says: is using JS means worth it? Administrators can “hang the locks” while changing protection levels, and a specifically designed program can place these templates en masse automatically, if run via a bot account with admin privileges. — BabylonAS (talk | ru.Wiki Admin) 14:42, 7 June 2018 (UTC)
- Agree with BabylonAS. I don't think we should be prevented from doing this just because we will need complicated JS code to add it automatically. Just noting, on Wikipedia all administrators are expected to add the locks as soon as they protect a page - though sometimes they forget. There are no bots that automatically add locks - but if a protection has expired, a bot will remove the lock from the page. However, this is solved with Category:Unprotected pages using Template:Protected, and all admins would have to do is look through that category every now and then.-- Madminecrafter12
Talk to me
14:56, 7 June 2018 (UTC)
- Agree with BabylonAS. I don't think we should be prevented from doing this just because we will need complicated JS code to add it automatically. Just noting, on Wikipedia all administrators are expected to add the locks as soon as they protect a page - though sometimes they forget. There are no bots that automatically add locks - but if a protection has expired, a bot will remove the lock from the page. However, this is solved with Category:Unprotected pages using Template:Protected, and all admins would have to do is look through that category every now and then.-- Madminecrafter12
- It does indeed require complicated JS code. The indicator element is a virtual one in wikitext, you cannot append it to an existing page with JS, it has to be processed by the wikitext parser first (or simulated as such). I'm not saying "no" to the idea, however. I'd just really like to see this thing automated when protecting pages. It removes the need for an admin to manually edit the page to reflect the new protection level (as you've mentioned already, sometimes this is forgotten). A bot helps, but are there maybe more direct ways to make it automated? Similar to how you could show a form of message box during editing for particular situations by abusing system messages. I haven't got an idea myself, as I'm not familiar enough with all the options we got. – Jack McKalling [
] 15:04, 7 June 2018 (UTC)
- It does indeed require complicated JS code. The indicator element is a virtual one in wikitext, you cannot append it to an existing page with JS, it has to be processed by the wikitext parser first (or simulated as such). I'm not saying "no" to the idea, however. I'd just really like to see this thing automated when protecting pages. It removes the need for an admin to manually edit the page to reflect the new protection level (as you've mentioned already, sometimes this is forgotten). A bot helps, but are there maybe more direct ways to make it automated? Similar to how you could show a form of message box during editing for particular situations by abusing system messages. I haven't got an idea myself, as I'm not familiar enough with all the options we got. – Jack McKalling [
- To change a large amount of pages at a time, we can use bots, but I am not sure if bots are allowed here... Lê Duy Quang (Make some words | Contributions)
New idea
This idea doesn't seem to currently be going anywhere, but I have a different but sort of related idea. Currently, when one edits a page they do not have permission they edit, they just get the following message: "The page has been protected to prevent editing and other actions." I'm thinking we kind of do closer to what Wikipedia does but omit the stuff about edit requests, etc. - mainly say the level of the protection, link to the protection log, and if it's a semi-protected page, suggest that the reader create an account. I think this would be very helpful. The great thing here is we wouldn't need a bot - it would automatically be generated with MediaWiki:Protectedpagetext. I'm going to experiment a bit with this in my sandbox.-- Madminecrafter12
Talk to me
22:49, 16 June 2018 (UTC)
- Anybody want to comment on this matter? You can see some demonstrations of this in my sandbox. Improvement suggestions are welcome.-- Madminecrafter12
Talk to me
13:04, 27 June 2018 (UTC)
- Message boxes are horrible IMO. They're centered on the screen (which means small boxes leave a lot of space on wide screens), and text inside them is also centered (which looks terrible on small screens, and on wide screens when the last word (or two) is the only one on its line. They also have quite a lot of margin and padding, which makes them take even more space. Why not just use plain text? --AttemptToCallNil (report bug, view backtrace) 13:20, 27 June 2018 (UTC)
- Do you think what I have in my sandbox now is better?-- Madminecrafter12
Talk to me
13:46, 27 June 2018 (UTC)
- Do you think what I have in my sandbox now is better?-- Madminecrafter12
- Better, though I would consider splitting the "if you think the page doesn't need to be protected anymore" part into its separate bullet point. Also: 1) "Directors are any user..." has inconsistent singular/plural; 2) the talk page is linked twice, this may be unnecessary. --AttemptToCallNil (report bug, view backtrace) 14:01, 27 June 2018 (UTC)
- I still prefer the "Another idea"'s locks to these huge message boxes. And we could make some sort of expanding the details when the lock is clicked. Lê Duy Quang (Make some words | Contributions) 14:07, 27 June 2018 (UTC)
- @AttemptToCallNil: Better now? Also, Leduyquang753, this wouldn't be huge message boxes anymore, just normal text - additionally, in case you didn't know, this would not actually show up when viewing the page normally; it would only show up in replace of the "This page has been protected to prevent editing or other actions" when editing an article that you don't have permission to edit.-- Madminecrafter12
Talk to me
14:15, 27 June 2018 (UTC)
- @AttemptToCallNil: Better now? Also, Leduyquang753, this wouldn't be huge message boxes anymore, just normal text - additionally, in case you didn't know, this would not actually show up when viewing the page normally; it would only show up in replace of the "This page has been protected to prevent editing or other actions" when editing an article that you don't have permission to edit.-- Madminecrafter12
- @Madminecrafter12: But still, we need a kind of indicator to add to the View mode that the page is locked. –Preceding unsigned comment was added by Leduyquang753 (talk • contribs) at 14:19, 27 June 2018 (UTC). Please sign your posts with ~~~~
- @Madminecrafter12: Better, but it seems you are using the
protectionvariable in your examples, and the variable is not defined. If that's the same as thereasonvariable, I have no further objections. --AttemptToCallNil (report bug, view backtrace) 14:21, 27 June 2018 (UTC)
- @Madminecrafter12: Better, but it seems you are using the
- When I changed the name of that defined variable, I forgot to update all of the cases in the template using it. :( Fixed that now.-- Madminecrafter12
Talk to me
14:24, 27 June 2018 (UTC)
- When I changed the name of that defined variable, I forgot to update all of the cases in the template using it. :( Fixed that now.-- Madminecrafter12
- Jack McKalling - sorry for the ping, but because you didn't seem to think it would be a good idea to use locks to signal page protection until we can figure out a way to automate it, I would be curious to see what you think about this idea.-- Madminecrafter12
Talk to me
18:58, 28 June 2018 (UTC)
- Jack McKalling - sorry for the ping, but because you didn't seem to think it would be a good idea to use locks to signal page protection until we can figure out a way to automate it, I would be curious to see what you think about this idea.-- Madminecrafter12
- I may make a script to automate this. Just need some learning about Lua and MediaWiki... Lê Duy Quang (Make some words | Contributions) 14:17, 29 June 2018 (UTC)
- I definitively think what MadMinecrafter12 made on his sandbox page is a big step in the right direction. Locks on the main page are not really necessary, particularly if it's not possible to make it automatic. However, indicating to users why they cannot edit their pages is absolutely necessary, and giving them instructions to discuss about changes. It may sounds simple, but it's not something obvious for someone new. Perhaps you could reduce a bit the text length and link to the admin list for the third case — but otherwise, I really like his suggestion. JSBM (talk) 14:32, 29 June 2018 (UTC)
- JSBM - I've added the text "or contact an administrator directly" linking to the list of administrators. Also, do you have any specific suggestions of how to reduce the text length?-- Madminecrafter12
Talk to me
13:32, 30 June 2018 (UTC)
- JSBM - I've added the text "or contact an administrator directly" linking to the list of administrators. Also, do you have any specific suggestions of how to reduce the text length?-- Madminecrafter12
- Ok, so, this is my take on the three messages:
This page is protected so that only registered users can edit it.
To edit this page, you'll need to create an account. You can also request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)This page is protected so that only directors can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)This page is protected so that only administrators can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)
- Just an overview of all the changes you made and what I think of them: I like having a bulleted list - it looks cleaner, so I'm opposed to changing that. I support making the intro text bigger, like you did. I also like how you were able to condense the "creating an account" and "requesting an edit" into 1 line, so I support that part as well. I am opposed to putting the protection log information just as small text in parentheses at the end - although perhaps we should move that down a bit from where it currently is, as I do think knowing how the page can be edited is more important than the reason for the protection. I'm neutral about removing the directors definition - it's certainly nice and convenient to have there, but it is a bit out of place and it does link to the MCW:Directors page right there, which contains an explanation.-- Madminecrafter12
Talk to me
17:07, 30 June 2018 (UTC)
- Just an overview of all the changes you made and what I think of them: I like having a bulleted list - it looks cleaner, so I'm opposed to changing that. I support making the intro text bigger, like you did. I also like how you were able to condense the "creating an account" and "requesting an edit" into 1 line, so I support that part as well. I am opposed to putting the protection log information just as small text in parentheses at the end - although perhaps we should move that down a bit from where it currently is, as I do think knowing how the page can be edited is more important than the reason for the protection. I'm neutral about removing the directors definition - it's certainly nice and convenient to have there, but it is a bit out of place and it does link to the MCW:Directors page right there, which contains an explanation.-- Madminecrafter12
- I've done this for the protected page text interface page on the RollerCoaster Tycoon World Wiki, another wiki I'm an administrator on. It works great, and actually looks fairly decent. You can see it in action here.-- Madminecrafter12
Talk to me
13:44, 30 June 2018 (UTC)
- It would have looked even better if the list bullets weren't barely distinguishable from the background. --AttemptToCallNil (report bug, view backtrace) 14:12, 30 June 2018 (UTC)
- That's just exclusive to that wiki - wouldn't be a problem here. Yeah, there are a lot of CSS skin problems on that wiki.-- Madminecrafter12
Talk to me
14:16, 30 June 2018 (UTC)
- That's just exclusive to that wiki - wouldn't be a problem here. Yeah, there are a lot of CSS skin problems on that wiki.-- Madminecrafter12
- This looks good! I already implemented it on the German wiki. The old text really was not informative at all. | violine1101(Talk) 15:41, 30 June 2018 (UTC)
- So, this discussion has been up for 2 weeks. It seems that the clear consensus is to definitely give more of a description on the MediaWiki:Protectedpagetext page. This proposal has not gotten any strong objections and seems to have mostly support, and nobody seemed to think that what I had in my sandbox was problematic, after I had modified it to comply with what people thought about it. Also, remember that these actions are easily reversible - if a mob of users suddenly come and for some reason say that we should just have that one old non-descriptive sentence, I or another admin can just modify that page. Likewise, if a lot of people think a change needs to be made to this, which is something I'm definitely expecting, we can easily do that as well.
- So, please comment if you think this needs to be changed, tweaked, removed, etc., but for now I've Done what I had in my sandbox.-- Madminecrafter12
Talk to me
16:05, 30 June 2018 (UTC)
- I think the padlocks we use as indicators at the top of protected pages, could be added to that page with the padlock and the text why the page is protected, and I could think the text could be:
Semi protected:
This page is protected so that only registered users can edit it.
To edit this page, you'll need to create an account or sign in. You can also request a change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)
Full protected:
This page is protected so that only administrators can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)
Directors only protected:
This page is protected so that only directors can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)
- psl85 (☎ Talk | ✏️ Contribs) 06:33, 2 July 2018 (UTC)
- @Madminecrafter12:, I definitely like the system message solution. It is automatic and doesn't need any additional admin action during protecting. I really like the more condensed version of JSBM as well. It is too much to read if there are 4 bullets below the main line, 2 lines would be ideal. That line about the protection log can be further simplified as a single link like this:
This page is protected so that only registered users can edit it [protection log] - To edit this page, you'll need to create an account. You can also request change on the article's talk page.
- You can discuss about the protection on the article's talk page or the admin noticeboard.
- I believe this is enough for all three cases, only differing in the usergroup in the bold text, with a link for the directors. No need to explain what directors are, this message/page is not responsible or related to the definition of each usergroup. The link should be fine. I combined JSBM's table here with your bullets, because I really like the offset background so that it pops up and it definitely deserves that. It doesn't need to be centered but I think this way it shows the importance of the message, as opposed by regular text. I also added Psl85's padlocks, it provides a fast message at glance to reduce the need to read even more. But I'm not sure about the table border between. I don't want this to turn into a centered message box though, I agree this one needs to be left aligned along with the text there. – Jack McKalling [
] 08:01, 2 July 2018 (UTC)
- In my last few edits to the page, I went ahead and condensed the information into two bullet points. I also removed the protection log bullet point and added the link to the log in the first line instead. Finally, I made the "This page has been protected so that only [X] can edit it" text bigger. I'm not too sure about implementing it into a table. And as for the locks, I do think that would be a good idea. I like what Psl85 did, I just think they should probably be a little bit smaller. If we do end up using a table, I'm against putting the lock in a separate cell from the text - I just think it would look much better if the lock and the text are together.-- Madminecrafter12
Talk to me
13:11, 2 July 2018 (UTC)
- In my last few edits to the page, I went ahead and condensed the information into two bullet points. I also removed the protection log bullet point and added the link to the log in the first line instead. Finally, I made the "This page has been protected so that only [X] can edit it" text bigger. I'm not too sure about implementing it into a table. And as for the locks, I do think that would be a good idea. I like what Psl85 did, I just think they should probably be a little bit smaller. If we do end up using a table, I'm against putting the lock in a separate cell from the text - I just think it would look much better if the lock and the text are together.-- Madminecrafter12
- Here's kind of what I'm thinking for incorporating the locks:
This page is protected so that only registered users can edit it.(see the protection log)
- To edit this page, you'll need to create an account. You can also request a change on the article's talk page.
- You can discuss the protection on the article's talk page or the admin noticeboard.
- -- Madminecrafter12
Talk to me
13:22, 2 July 2018 (UTC)
- Good message, but the text "to edit this page, you'll need to create an account." could be changed to "to edit this page, you'll need to create an account or sign in" to add a link to allow signing in from that link instead of only a link for creating an account, and I would also be able to edit those Mediawiki: messages instead of only admins and wiki guardians, this wiki and other Gamepedia wikis could add a interface editor user group and users in that group could be able to edit the Mediawiki: messages, and could be given through requesting the right, is this possible??? psl85 (☎ Talk | ✏️ Contribs) 17:43, 2 July 2018 (UTC)
Another idea
I have also a new idea - the padlocks could be replaced with blocks in Minecraft - iron block on semi-protected page, gold block on fully protected page, coal block on directors protected page, emerald block on move protected page, and lapis lazuli block on upload protected file, and those soes not needed to be uploaded, and only be used on the top right corner on protected page, and the Mediawiki:protectedtext could be a message box, with padlock/the blocks mentioned before image, and information about the protection, reason, and then add a link to suggest the reader to create an account/submit a edit request using a new template {{edit request}}, and a link to the admin noticeboard to remove the protection if the protection is not needed anymore, I planned to experiment with the edit request template and the new protection messages in my sandbox - psl85 (☎ Talk | ✏️ Contribs) 06:06, 27 June 2018 (UTC)
- The Minecraft-themed protection locks would certainly be an interesting idea. It's still not addressing the problem about adding the locks automatically, which is something that many people seem to think is necessary (although I personally don't think it is). I've tried to see if MediaWiki:Protectedpagetext can detect protection levels on another wiki, and it definitely works! I'm not really that supportive of creating the edit request template, though - there's not really much need for it on such a small wiki, and we don't need to have all of the complex systems that Wikipedia has.-- Madminecrafter12
Talk to me
12:50, 27 June 2018 (UTC)
- Maintenance issue. We in general should not use images of game content as part of wiki design for the following reason:
- If the depicted object's appearance is changed, the image has to be reuploaded. Allowing regular users upload system images is a risk due to potential severe harm from vandalism. Disallowing this would require administrators to upload the image, rendering them not uploadable by regular community members for essentially no good reason. Keeping duplicates used solely in the interface will make the engine unhappy (it will list the files as duplicates), or cause discrepancy between these two files, which would have to either be kept (for no reason) or fixed by having administrators upload the protected copy (creating a duplicate with restricted maintenance). Images which can never be updated, such as locks, solve all the aforementioned issues.
- --AttemptToCallNil (report bug, view backtrace) 12:57, 27 June 2018 (UTC)
- Definitely a good point. We don't want anybody who's logged in to be able to overwrite an important skin image, nor do we restrict the ability to reupload several images that would appear on Minecraft-related articles (that may need to be updated to comply with new versions), to administrators. Therefore, I have to withdraw my support to use Minecraft icons to signal page protection.-- Madminecrafter12
Talk to me
13:01, 27 June 2018 (UTC)
- Definitely a good point. We don't want anybody who's logged in to be able to overwrite an important skin image, nor do we restrict the ability to reupload several images that would appear on Minecraft-related articles (that may need to be updated to comply with new versions), to administrators. Therefore, I have to withdraw my support to use Minecraft icons to signal page protection.-- Madminecrafter12
- I can try drawing 16x16 padlock icons to make them look like Minecraft... Lê Duy Quang (Make some words | Contributions) 14:27, 27 June 2018 (UTC)
- For more appealing results you could just extract the padlock from this file and recolorize the body. Just a suggestion. – ItsPlantseed ⟨₰|₢⟩ 15:32, 27 June 2018 (UTC)
- I can try drawing 16x16 padlock icons to make them look like Minecraft... Lê Duy Quang (Make some words | Contributions) 14:27, 27 June 2018 (UTC)
- Madminecrafter12: See my sandbox now, I created some differently-coloured message boxes with the blocks I mentioned above, and some links on the message boxes to suggest the reader to create account/log in, request edit or unprotection, and I will now try to start working on the edit request template I mentioned above on the sandbox - psl85 (☎ Talk | ✏️ Contribs) 15:51, 27 June 2018 (UTC)
- As you can see above, Nil pointed out that the message boxes are a bit disruptive and messy, and it would be better to use plain text. As shown in my sandbox, I've used plain text instead - as I agree with this. Also, note that GRASP aren't able to edit fully-protected pages - only admins and wiki guardians can. And I personally don't think an edit request template would be necessary, as I've said above. I do like where you're going with this, though. :)-- Madminecrafter12
Talk to me
15:58, 27 June 2018 (UTC)
- As you can see above, Nil pointed out that the message boxes are a bit disruptive and messy, and it would be better to use plain text. As shown in my sandbox, I've used plain text instead - as I agree with this. Also, note that GRASP aren't able to edit fully-protected pages - only admins and wiki guardians can. And I personally don't think an edit request template would be necessary, as I've said above. I do like where you're going with this, though. :)-- Madminecrafter12
- Madminecrafter12 I will use plain text, but I created some differently coloured message boxes, and I think those not was too messy an ugly, I can add the protection block and plain text- psl85 (☎ Talk | ✏️ Contribs) 16:04, 27 June 2018 (UTC)
- @psl85: I have made the locks, which you can preview here:
- File:All locks.PNG
- Lê Duy Quang (Make some words | Contributions) 16:14, 27 June 2018 (UTC)
- Leduyquang753 Cool locks, and I would use those, the only need is only have one file/padlock - psl85 (☎ Talk | ✏️ Contribs) 16:22, 27 June 2018 (UTC)
- I fail to understand the insistence on styling everything like Minecraft. The current locks are already perfectly functional, the choice is purely stylistic (following an unstated and pointless guideline), so creating new images where other already exist and are capable of doing their job is a wasted effort. --AttemptToCallNil (report bug, view backtrace) 16:55, 27 June 2018 (UTC)
- psl85. Here are 10 icons in the preview colored according to Wikipedia's protection locks with description of what they do. You can try using them in your sandbox messages. And AttemptToCallNil, if this wiki doesn't need anything to look like Minecraft at all, why does the Hydra skin exist? And the icons near the links in the mainpage. They all have the same purpose to make this Wiki look more like a Minecraft wiki, don't they? Lê Duy Quang (Make some words | Contributions) 01:22, 28 June 2018 (UTC)
Comment I don't see the point of having that padlock template at all, it's just adding more workload to the admins who have to change the template every time they change the protection. Apart from that, it's rather obvious if a page is protected or not, protected pages have "View source", unprotected pages have "Edit" (and "Edit source" if you've enabled the visual editor).
My point is, we aren't Wikipedia. I don't see the point in creating meta-templates which add nothing to the contents of the page. It will just make everything messier.
Lastly, Leduyquang, I appreciate the work you put into pixeling the padlocks, but in my eyes, they don't fit to Minecraft at all and also look a little clumsy. As I mentioned on Discord before, it would make more sense and look better if you just used the padlock texture that's included in Minecraft anyway (given that it's decided that such a template is needed in the first place). | violine1101(Talk) 09:45, 28 June 2018 (UTC)
- "doesn't need anything to look like Minecraft at all" means "shouldn't have elements which look like Minecraft", the opposite of which is "may have elements which look like Minecraft". What you're trying to accomplish is "shouldn't have elements which don't look like Minecraft", which is not a valid opposite.
- And yes, why bother adding locks if we can just change the protected edit message? --AttemptToCallNil (report bug, view backtrace) 10:05, 28 June 2018 (UTC)
- Adding locks gives a nice, compact indicator to the users about the protection state of a page. Having a massive message box (a small one is still big and distracting in this case) at the top isn't good for focusing on the below content. And the difference between "Edit source" and "View source" only indicates whether the user can edit it or not. Lê Duy Quang (Make some words | Contributions) 14:05, 29 June 2018 (UTC)
- And also using the vanilla's lock icon doesn't give a nice result because it needs to be recolored to indicate different protection states. The lock's texture looks like gray stone, so recoloring it makes it ugly. Lê Duy Quang (Make some words | Contributions) 14:08, 29 June 2018 (UTC)
- My main point was that admins would have needed to update the template on the page every time. This problem has been solved with AttemptToCallNil's proposal below. Locks are fine with me, but to be honest, I still don't like your pixel arts.
The question now is, which indicators do we need? Should the colors mean something or should they be random? Let's take a look at your proposal from User:Leduyquang753/locks:
- My main point was that admins would have needed to update the template on the page every time. This problem has been solved with AttemptToCallNil's proposal below. Locks are fine with me, but to be honest, I still don't like your pixel arts.
| Color | Default | Your proposal | My proposal | Meaning | Notes |
|---|---|---|---|---|---|
| Gold | File:Minecraft protection lock full.png | Fully protected | Gold makes sense, but your color looks a little dull at the moment. | ||
| Green | -- | Move protected | Do we really need a seperate lock for move protected pages? | ||
| Silver | File:Minecraft protection lock semi.png | Semi protected | Makes sense, but the gray is a little dark. | ||
| Pink | -- | -- | Template protected | What's the difference to normal protection? Besides, this protection level doesn't exist here as far as I know. Also, the pink is too similar to the purple of the Upload Protected lock. | |
| Purple | -- | Upload protected | Again, what's the difference to normal protection? Why do we need a seperate lock for this? Do there actually exist pages which are upload protected. Also, the purple is too similar to the pink of the Template Protected lock. | ||
| Light blue | -- | -- | Cascade protected | Every page which is cascade protected is also normally protected. Why do we need an extra lock for this? Also, the light blue is too similar to the cyan of the Create Protected Lock. | |
| Cyan | -- | -- | Create protected | Again. Why an extra lock? Also, the cyan is too similar to the light blue of the Cascade Protected Lock. | |
| Blue | -- | -- | Extended confirmed protected | What is this? I don't think this protection level exists here. | |
| White | -- | -- | Pending changes protected | No such protection level exists on the Minecraft wiki. | |
| Black | File:Minecraft protection lock full.png | Office protected (directors and above) | I would use the same icon as for full protection; there's just a small amount of users to whom it matters whether a page is fully protected or protected on directors level. |
- | violine1101(Talk) 14:57, 29 June 2018 (UTC)
- Cascade protection used to be used with the main page onto various templates, but in most cases its a bit difficult to tell why a page is protected if its just marked with regular protection (difference between "we think this page is a target" and "we think this page may be used to target another page") so it might be worth a separate lock to mark. Hard part is its slow to fetch anyways compared to regular protection data.
- Otherwise, I prefer the locks that are actual sprites over the pixelated ones. Between the antialiasing and the black borders they don't really match Minecraft's style in my opinion. –KnightMiner · (t) 18:46, 29 June 2018 (UTC)
Yet another idea
JavaScript could be used to place locks on protected pages automatically. It saves the need for administrators to add a template every time a page is protected and remove the template when it expires or if it is removed. It could be implemented as a gadget.
This script I wrote (it's not exactly pretty, but I found no predefined functions to set indicators) uses the Wikipedia-style icons. As I have said before, these icons are perfectly functional, there's no point to create new ones as if just to conform with a nonexistent rule demanding we make every interface image Minecraft-styled. --AttemptToCallNil (report bug, view backtrace) 14:12, 29 June 2018 (UTC)
- We should make a debate... Lê Duy Quang (Make some words | Contributions) 14:30, 29 June 2018 (UTC)
- Support This works really well, nice script! | violine1101(Talk) 14:57, 29 June 2018 (UTC)
- Nice script. That's a kind of script what I meant above. Whould this script fit in Mediawiki:Common.js? This would work very well for the main view of a page, and the system message from the New idea above would work for the edit view. – Jack McKalling [
] 08:48, 2 July 2018 (UTC)
"Twinkle" gadget on this wiki
Hello! I think that this wiki should have some new gadgets from Wikipedia, such as Twinkle, Navigation popups, wikEd (I edits with this gadget installed in the JavaScript subpage), and minor gadgets for syntax highlighting, mark blocked users and admins, and dropdown menu to easily choose edit summary while editing, think I to be added to this wiki, and I search for more gadgets, if Twinkle should be added, could it be customized for use on this wiki and its usage could be same as on Wikipedia, and it may need some lesser templates and only existing templates should be used by the gadget. psl85 ☎ Talk 14:14, 5 June 2018 (UTC)
- Support. These could be great things to keep the Wiki fresh and clean. Lê Duy Quang (Make some words | Contributions) 01:21, 24 June 2018 (UTC)
- Support twinkle and navigation popups. No opinion on wikEd as I generally don't use any type of visual editor, although I will note that the correct link is User:Cacycle/wikEd, not User:Azatoth. Also, I'll note that I tried to use twinkle via user JS and that didn't work, though that was a while ago; the module would be very nice (but it definitely would need editing for the list of templates). --Pokechu22 (talk) 01:41, 24 June 2018 (UTC)
What if Minecraft appears in another game?
What shall we do if Minecraft appears in another game, like the upcoming Super Smash Bros.? Should we create an article for the game? Hugman_76 [
] 16:07, 9 June 2018 (UTC)
- There is a section about Minecraft references in other games (Minecraft#References_in_popular_culture) :) • Yanis48 (talk) 16:23, 9 June 2018 (UTC)
- To give a more general answer, no. This wiki exists to document what's in Minecraft, not what's in other works. Besides, that "news" is just a rumor from DasVergeben, who isn't a particularly reliable source according to this GameRant article. – Auldrick (talk · contribs) 16:51, 9 June 2018 (UTC)
Development versions or current version for names, images, sprites, etc.
There seems to be some dispute as to whether the title of images, the texture of images, the texture of sprites, and the word used in articles for a certain title of a feature or texture of a feature, as to whether it should be the one in the latest development version or in the latest full-release version. It seems like the description of the actual functionality of features is always how they work in the current version (except for statements marked with {{upcoming}}), so it seems like the names and textures should be the same way. I've been trying to keep them as they are in the current version, because it seems to make the most sense - a few times this has gotten reverted, but most of the time it hasn't. Here are some examples:
- In this edit, all instances of "fish" were replaced with "cod." I changed this back later, and this time it was actually undisputed. However, it had stayed at the 1.13 name for a long time.
- As can be seen here, the image was reuploaded in February to comply with the new 1.13 texture. I reverted it back, explaining my reasoning. However, that was reverted again by somebody else, because File:Pufferfish 13w43a-18w08b.png exists. I didn't re-revert, because I didn't want to start an upload war.
- All of the fish textures and sprites were updated to the 1.13 textures. I changed them back after many months of being on the 1.13 names, and most of the changing back was undisputed; in fact, I actually got a few thanks for it. However, many of the sprites now seem to use the 1.13 name - but again, I don't want to start a sprite-edit war.
In my opinion, we should try to have both the texture and name in the current development version and the current full version, but the one in the full version should always take priority. For images, the actual in-game names, such as File:Water.png and File:Pufferfish.png should be the texture of the current version, not the latest development version. However, I think there should also be separate files, e.g. File:Water in 18w15a.png and File:Pufferfish 18w08b.png, for the textures in the latest development version. For the sprite names, I think that both the name in the current dev version and the current full version should be aliases for each other - however, I think that the current name is what should be used in articles, which is not the case right now. For sprite textures I feel the same way as I do for the images - the main one should be of the texture in the current full version, but there should be an additional one with the texture in the latest dev.
My reason for this is, 1.12.2 is still the current version the game is on right now - so no matter what crazy features have been added in development versions, the names/textures in 1.12.2 are the names and textures in the game. Another reason is for consistency with the actual description of features. The descriptions of the features is mainly how it is in the current version - with upcoming changes marked with {{upcoming}}. I don't see why textures, names, and sprites should be any different. However, I do think it can't hurt to prepare for 1.13 - which is why I support adding the dev names as aliases in sprites, and upload the new textures as separate files.
I propose that we discuss this here so that we can come to a decision once and for all.-- Madminecrafter12
Talk to me
13:49, 13 June 2018 (UTC)
- I mostly agree. In my own words, I think all files and other assets that are named in-game, should always carry the same name as in the latest full release. Any new name for them introduced in development builds/snapshots/releases should be an alternate name with the relevant version in it. If the graphic was not changed, the development name should redirect, otherwise, it should be an alternate file/asset altogether. As for the text on the articles, this should always reflect the latest full release, with specific
{{upcoming}}notations/history entries being the only exceptions to that. – Jack McKalling [
] 14:34, 13 June 2018 (UTC)
In my opinion, we should try to have both the texture and name in the current development version and the current full version, but the one in the full version should always take priority.The highlight of the message, and I agree with it.I think there should also be separate files, e.g. File:Water in 18w15a.png and File:Pufferfish 18w08b.png, for the textures in the latest development version.Also agree.For the sprite names, I think that both the name in the current dev version and the current full version should be aliases for each other - however, I think that the current name is what should be used in articles, which is not the case right now.Agree with everything but one case. If development versions for one full version change both the name and the texture, no full version exists where the new name corresponds to an item with the old texture. This is why I think that, in such cases, the new name should be mapped only to the sprite with the new texture.- --AttemptToCallNil (report bug, view backtrace) 14:58, 13 June 2018 (UTC)
- I agree that upcoming textures and names should both not be used until a release. In my opinion MCW:FUTURE already applies to feature names and textures as well direct information. At the very least we should add on the style guide that it specifically applies to textures and names as well. –KnightMiner · (t) 15:10, 13 June 2018 (UTC)
- Ah yes, I was going to mention in the post but I forgot - whatever the consensus is, I think we should add it to the style guide. That way it will be clear to everybody that it is an official guideline, rather than just one user thinking that it makes sense one way.-- Madminecrafter12
Talk to me
15:16, 13 June 2018 (UTC)
- Ah yes, I was going to mention in the post but I forgot - whatever the consensus is, I think we should add it to the style guide. That way it will be clear to everybody that it is an official guideline, rather than just one user thinking that it makes sense one way.-- Madminecrafter12
- (Edit conflict) In the past, it clearly made better sense to stick to released versions' names and images, because those are familiar to everybody whereas updated versions might not be. Unfortunately, this rule is no longer tenable because there is no longer a clear line between released and development usage. You all may not have thought of this, given that you equate "1.12.2" with "released version" and "1.13" with "development version" (sadly, one of the many examples of insidious Java elitism among the editors on this wiki), but different editions have different chronologies and any feature can be in both states at the same time. For example, the new Pufferfish texture is already in the release version in Bedrock but still in development in Java. (The last time I looked, the Fish (mob) infobox bizarrely had the new texture but the old sprite.) Given this conflict, I think we need to be more flexible. I suggest that a texture or sprite be allowed if it has been released on any version, or used consistently across several development versions in one or more editions. – Auldrick (talk · contribs) 15:31, 13 June 2018 (UTC)
- I say that makes sense to extend the idea to being released in any version. Since we can not easily just use all sprites, the one that makes most sense is whatever is the current texture, so a priority system to show the texture from the latest release makes sense. Just as long as we clearly show that it has not changed in all editions yet. –KnightMiner · (t) 15:49, 13 June 2018 (UTC)
- Agree with the proposed edition-related amendment. What if an item has different names and/or textures in different editions? That case isn't covered. --AttemptToCallNil (report bug, view backtrace) 16:10, 13 June 2018 (UTC)
- I think if we stick to just moving the images, it's fine (which is atthis moment basically already done (only Tall Grass -> Grass and Double Tallgrass -> Tall Grass left); the actual pages themselves shouldn't be moved yet until 1.13 release though. Without a doubt the bedrock (and possibly legacy console) editions will start following the new names soon. FVbico (talk) 18:40, 25 June 2018 (UTC)
Zombie hurt.ogg
The file doesn't work on the Zombie page. –Preceding unsigned comment was added by Enderdespawnmite (talk • contribs) at 3:50, 17 June 2018 (UTC). Please sign your posts with ~~~~
- Works fine for me. –KnightMiner · (t) 04:05, 17 June 2018 (UTC)
Moving mod files to a sprite sheet
Hi! In my desire to improve the mods part on the wiki, I wanted to find a solution about all these mod files, mainly grids, used only once. So I thought about making a sprite sheet for that. With the agreement and help of Madminecrafter12, I tested it and it works exactly like InvSprite. It is currently called ModSprite.png, with the corresponding template and module.
So, what do you think about that? Do you agree to move the maximum number of mod files into this sprite sheet? • Yanis48 (talk) 15:20, 17 June 2018 (UTC)
- The Russian wiki creates a sprite sheet for every mod which contains sprites just for that mod. The English version of Module:Inventory slot should have similar support.
- Note that some people have been moving to deprecate mod support and eventually migrate all mod articles from the wiki. --AttemptToCallNil (report bug, view backtrace) 15:33, 17 June 2018 (UTC)
- I definitely that would be a good idea if we decide to keep mod content here, but there's not much point of working hard on a sprite for mods only to have all mods removed or migrated.-- Madminecrafter12
Talk to me
15:50, 17 June 2018 (UTC)
- Opinion Hi there. i personally think that we should keep mod articles here. Any objections or support?--TheCreeperStrikes (talk) 17:49, 17 June 2018 (UTC)
- I personally would be in favour of removing mod content from this wiki, but setting up a sister wiki dedicated to mod, fandom, etc, content. - MinecraftPhotos4U (talk) 17:53, 17 June 2018 (UTC)
- What should we do?, Anyone? - - TheCreeperStrikes (talk) 18:05, 17 June 2018 (UTC)
- Its worth mentioning this wiki has an unofficial partnership with the Feed the Beast Gamepedia, which covers many mods both in Feed The Beast packs and some independent ones. I personally would rather just drop modded content in favor of not duplicating effort between this wiki and that one. They have a much better framework set up for mods (including support for Forge features like the oredictionary in modded recipes), plus it saves us from having to make a list of guidelines about what makes a mod notable. Additionally, with how poorly maintained the mod pages are here, I doubt we would have an easy time finding enough editors to handle all the mods, most editors tend to just handle a couple mods they personally play. –KnightMiner · (t) 18:23, 17 June 2018 (UTC)
- 😞 I spent so much effort uploading all those images and they’ll just get DROPPED? Like that?!, *deep breath* Sorry, just went a little overboard there *sigh*
- -TheCreeperStrikes (talk) 18:33, 17 June 2018 (UTC)
- Hmmm… maybe we could make a wiki for each individual mod (not everything)?-TheCreeperStrikes (talk) 07:52, 18 June 2018 (UTC)
- Wiki for each individual mod? That's not really a great idea IMHO - seeing how much the FTB Wiki relies on some common stuff (common templates like infoboxes, navbox and oredict frameworks, vanilla Minecraft crafting templates and tilesheet, etc. - imagine syncing changes to that...) and that many mods have integration with other mods (copying a template for some machine across 10 wikis to show some mod integration?). Keeping that stuff in sync would me more trouble than it is worth. Also, you'd have a lot more than one recent changes page to keep track of. Modded content doesn't really have enough wiki manpower for splitting it like that in my opinion. --Hubry (talk) 08:24, 18 June 2018 (UTC)
- Agreed with Hubry. We don't need another wiki for each mod on here. The Feed The Beast wiki already covers a great deal of the mods, it would not be a bad decision to relocate all our mod content over to that wiki, or delete if it's already there/outdated. Our wiki isn't really suitable for mods, we're just documenting the game itself. – Jack McKalling [
] 09:46, 18 June 2018 (UTC)
- Then we could just export
{{ModSprite}}there.-TheCreeperStrikes (talk) 14:33, 18 June 2018 (UTC)
- Then we could just export
- Agreed with Hubry. We don't need another wiki for each mod on here. The Feed The Beast wiki already covers a great deal of the mods, it would not be a bad decision to relocate all our mod content over to that wiki, or delete if it's already there/outdated. Our wiki isn't really suitable for mods, we're just documenting the game itself. – Jack McKalling [
Project announcement
MCW:Projects/Refactoring edition specific information is a new project intended to explore ways we can structure edition-specific information to yield smooth, natural prose in articles, and later to clean up articles that need it. Interested editors are encouraged to join by adding their names to the Members list on the project page. – Auldrick (talk · contribs) 02:00, 20 June 2018 (UTC)
Elements and existing pages with the same name
- Here's a couple of pages that I think should be moved to free up space for element redirects
- Gold to Gold (disambiguation)
- Iron to Iron (disambiguation)
I don't think there are any other pages like this, but I'd like some input before I (or someone else) move these. Kienan (talk • contribs) 19:20, 20 June 2018 (UTC)
- No support for redirecting the pages to the element. I suspect that the majority of users entering Gold or Iron as a URL would not want to see the element, but instead a disambiguation. Maybe support moving the articles and having Gold redirect to Gold (disambiguation), and including the element on there. But maybe it's just better to leave it as-is. Wikipedia seems to just not use the (disambiguation) suffix in that case (in fact, they redirect the disambiguation page back); for instance Mercury and Mercury (disambiguation). In fact, that gives a fairly good case for it, in that mercury itself is an element. --Pokechu22 (talk) 19:32, 20 June 2018 (UTC)
- Oppose moving. The primary meaning for non-Education Edition-oriented readers (which I expect to be the majority of the wiki's audience) would most likely be the resource in general, not the element. Redirecting Name to Name (disambiguation) would be completely pointless, same with the reverse redirect; or, to be more accurate, these redirects are only useful if some program code we can't modify handles "(disambiguation)" titles in a desirable special manner, and I am not aware of any such distinction. --AttemptToCallNil (report bug, view backtrace) 19:51, 20 June 2018 (UTC)
- Weak oppose. If we were to be perfectly consistent and always use the in-game names, the pages should be moved, which is why my oppose is weak. However, I really think readers searching for gold are much, much more likely to want to go to gold ingot or gold ore than the element page. In my opinion, this is more important than being perfectly consistent and always using the in-game names.-- Madminecrafter12
Talk to me
01:52, 21 June 2018 (UTC) - Oppose moving; while it has to be acknowledged that they are in-game names, they're not something from the core gameplay. The existing pages for gold and iron have to take precedence in ambiguous situations like this because they are based in the core gameplay. – Sealbudsman talk | contribs 02:46, 21 June 2018 (UTC)
- Oppose move. The disambiguation suffix should only be used for pages like this when there are other articles with the same name, but as said above, the term "gold" and "iron" are only a partial use for in-game names. Those elements from Education Edition are basicaslly edition exclusive and that's not enough reason to override that partially used in-game name. Having a link to Gold (element) and Iron (element) on the Gold and Iron pages respectively is the best way here, IMO. – Jack McKalling [
] 08:54, 21 June 2018 (UTC) - Oppose. We should instead keep the page Gold (element) for the element, like Clay (block), and leave the Gold page alone. Lê Duy Quang (Make some words | Contributions) 01:16, 24 June 2018 (UTC)
Item stack general format
So, when a high amount of item is expressed in the Wiki, it would be "x stack(s) and y item(s) (n total items)", which is a bit complicated. So I am thinking of a template that we could write it as for example "2s35" with the hover comment "2 stacks and 35 items (163 total)". Improvements can be made as long as they make sense, then this would make the Wiki more compact. Lê Duy Quang (Make some words | Contributions) 02:36, 24 June 2018 (UTC)
Question about sparklers
According to the text:"When lit, the sparkler will emit colored particles; the durability meter depletes while the sparkler is burning.",is that means sparklers have it's item durability? (In zh,it displays "?")--Wth213 (talk) 08:24, 28 June 2018 (UTC)
- Absolutely, it only burns when you hold it in your hand though. – ItsPlantseed ⟨₰|₢⟩ 10:30, 28 June 2018 (UTC)
Weird spacing and bullet formatting on templates
I'm not entirely sure where to post this so I guess I'll post this here: On navboxes, the formatting seems to be a bit bugged with creating additional bullet points - while it does make it in parentheses, at the end it has a weird space before the ")" and it creates a space between that and the next item. You can see this better on the Bedrock Edition versions template. It just seems off so if this can be fixed that would be great. --Marioprotvi (talk) 20:16, 28 June 2018 (UTC)
- It's been the case since tidy was broken, and tidy is a requirement for hlists to work properly, so nothing we can do about it. –Majr ᐸ Talk
Contribs 07:52, 30 June 2018 (UTC)
Replace edition abbreviation links with templates
Replacing edition abbreviations links like BE with templates like {{BE}} would be useful as we can have the template link to the full page name, so the title says the full name rather than just the abbreviation to make it clearer to readers what it means. It also provides the opportunity to add some styling to the links (like a background colour or icon). –Majr ᐸ Talk
Contribs 08:01, 30 June 2018 (UTC)
File naming consensus
There doesn't seem to be any file naming consensus except for things from mods (suffixing with "(<mod name>)").
There's files in all different naming conventions:
runninglowercase
lowercase with spaces
Capitalrunning
Capital On Every Word
Capital on first word
etc.
Even file extensions have the FULLCAPS and nocaps variants used interchangably.
Alongside this inconsistent naming, there is no telling if the file is a user file by name (or from who it is in general).
I propose the following naming convention:
File:<user name in case it's a user file> Capital On Every Word (<mod name>).lowercase extension
Examples:
- File:FVbico Some Funny Meme.gif
- File:Computer (ComputerCraft).png
- File:Skeleton Riding Spider.png
Of course, changing all existing files will take a long time, so when a naming convention is chosen, I (potentially others too) will go through all files and move to the proper naming. FVbico (talk) 12:51, 1 July 2018 (UTC)
- I Support it, though I might take it a step further; for user files, call it like: File:User FVbico Some Funny Meme.gif. Just so that it's more obvious in case someone's username is something ambiguous like Indev. –Preceding unsigned comment was added by Sealbudsman (talk • contribs) at 17:13, 1 July 2018 (UTC). Please sign your posts with ~~~~
- Neutral. I would be open to having a message when uploading a file, telling the uploader to give the file a detailed name that describes the image clearly, AND use whitespace where you normally would. We could also add that little bit to MCW:IMAGES. However, I don't think the userspace and capitalization restrictions would be necessary, so I'm against making that part a formal guideline.-- Madminecrafter12
Talk to me
13:43, 3 July 2018 (UTC)
Drowned and Zombie
The information for the Drowned is on the Zombie page, so why not merge the pages?
File:Talk.png File:Edits.png 02:34, 3 July 2018 (UTC)
- If so, it should also applies to Husk. Hugman_76 [
] 14:27, 3 July 2018 (UTC)
- Comment Husk has already been merged into the zombie page.-- Madminecrafter12
Talk to me
14:29, 3 July 2018 (UTC)
- Comment Husk has already been merged into the zombie page.-- Madminecrafter12
- Oppose. Drowned currently is actually quite a long page as far as content goes, with a lot of detail about spawning, drops, and behavior, much of which is very different than zombies. Merging the two would make the zombie page more cluttered, with little benefit.-- Madminecrafter12
Talk to me
14:39, 3 July 2018 (UTC) - Oppose. It's pretty clear that they are different mobs. Also, merging all entities that could fit under the term "zombie" doesn't help much with adding more information to the wiki, but only clutters it up with so much information that it gets confusing. (Hence I also disagree with Husk and Zombie villager being part of the Zombie article. They aren't real zombies either and have their own special properties.)
On an unrelated note, this should be on Talk:Drowned, not here. | violine1101(Talk) 15:32, 3 July 2018 (UTC) - Note - the same thing is currently being discussed here.-- Madminecrafter12
Talk to me
12:46, 4 July 2018 (UTC)
Using artworks instead of renders in some info boxes
Some entities got official artworks. I was wondering, why don't we use these in 'Entity Boxes'? I've put an example on the right side to prove you how it could render, but it can works with other mobs with official artworks, like
,
or even
. Hugman_76 [
] 17:51, 3 July 2018 (UTC)
- While I can definitely understand the appeal of this, I'm not sure if this will fit well in an unofficial encyclopedic context (especially given these are not honest in-game appearances), and the fact that we don't have artworks for absolutely everything would cause major inconsistencies. I otherwise wouldn't mind this if it weren't for these problems. - MinecraftPhotos4U (talk) 15:40, 3 July 2018 (UTC)
- Take the encyclopedic context out of the cage. Does other game wikis will choose a T-Pose of the mob in question? Nope, and we're litterally doing this. Also I don't think they aren't honest in-game appearances, and even so, again, the other wikis does this as well. For the inconsistencies, we could keep the 'T-Pose' renders under the first paragraph or something like that, or even make an
image2in the infobox. Hugman_76 [
] 17:51, 3 July 2018 (UTC)
- Take the encyclopedic context out of the cage. Does other game wikis will choose a T-Pose of the mob in question? Nope, and we're litterally doing this. Also I don't think they aren't honest in-game appearances, and even so, again, the other wikis does this as well. For the inconsistencies, we could keep the 'T-Pose' renders under the first paragraph or something like that, or even make an
- My opinion: This looks nice, and arguably better than the renders from the game we have now. However, the wiki is supposed to document the game as it is. Ironically, Minecraft's artworks have a different artstyle than the actual game, it uses even more simplified textures for everything. Therefore, I don't think that it would be a good idea to change the images in the info boxes so that they are different from the game.
Also, there's the question of where to get the artworks from – we can make the renders by ourselves, for the artworks we would need to wait for Mojang or Microsoft to come along and create one. | violine1101(Talk) 18:05, 3 July 2018 (UTC)
- We could display these artworks somewhere else, like in the second image of the info box template to not remove the render. Or even add it under the first paragraph of the article. Hugman_76 [
] 18:48, 3 July 2018 (UTC)
- We could display these artworks somewhere else, like in the second image of the info box template to not remove the render. Or even add it under the first paragraph of the article. Hugman_76 [
- I have to agree with Violine1101 here. I definitely see where you're going with this, and I like how they look - however, I really think it's better to use the exact in-game textures for infoboxes, as they are right now. Also, I don't really see much benefit for having the artwork as the second image in the infobox. However, I do like the idea of including the artworks in the gallery.-- Madminecrafter12
Talk to me
12:50, 4 July 2018 (UTC)
A patroller user group
This was suggested on Discord and seemed to be supported. Pinging JSBM and MarkusRost, as both of these users participated and voiced their opinions in the discussion, so it would be great if they could do the same here.
So as you can see above a proposal was made to create a new user group that can semi-protect pages. However, there were a number of concerns raised about this on Discord that I agree with. First of all, I could easily see this being abused in edit wars even by an experienced user - one user thinks they're right so they just semi-protect the page. Second, many experienced users may semi-protect incorrectly - e.g., because of 2 IPs vandalizing twice in the last month, or one IP vandalizing 5 times. Also, protecting usually isn't the answer to vandalism - it's usually actually blocking. So if we give somebody the access to semi-protect, they may do that when blocking is really the answer - because they don't have permission to block. And if we allow them to protect AND block, then we might as well just go ahead and give them admin. Finally, I'm not sure if it's possible to allow editors to only protect pages for a short amount of time - we would likely have to create a whole new user permission, as currently it's just listed under one: protect. And is it really worth it, especially considering protecting really isn't usually the way to go in cases of vandalism? Many of these concerns I have are shared here.
However, I support creating a new user group called "Patrollers" that gives the following rights:
- Mark others' edits as patrolled (patrol)
- What this does: It allows to click the button "Mark as patrolled" in a diff. In recent changes, any unpatrolled edits have a red exclamation mark next to them. This allows admins (and possibly soon patrollers) to see the edit, look over it, and know that it has not yet been reviewed, or the administrator who reviewed it doesn't know if the information is accurate or not. Although this isn't a necessary feature, I definitely think it would be helpful.
- Reason: The patrol backlog is very large right now. Dinoguy and I are pretty much the only ones patrolling, and about half of all edits remain unpatrolled by the end of the day. I could see this being very helpful for users who can't look at every edit in recent changes - they would be able to see which edits have been reviewed or not, so that the unpatrolled can take priority. Patrolling isn't a necessary feature, but I do think it's a good idea and helpful in many circumstances.
- Quickly rollback the edits of the last user who edited a particular page (rollback)
- What this does: On the latest diff of a page, there is a "rollback" button. When this is clicked, it will revert all of the last consecutive edits by that user. This will also automatically mark the user's rolled-back edits as patrolled. Additionally, Majr created a wonderful script that allows for a custom rollback summary without having to load any new screens. This is very helpful for reverting multiple good faith edits.
- Reason: Rollbacking is much, much quicker. Especially for multiple edits. If a normal user finds a user who made multiple vandal edits, they must navigate to the diff before their edits, reload several screens, click the edit button, wait for that screen to load, put in the edit summary something like "Rvv last 3 edits," click save changes, and wait for that to load. With rollback, all of that's in a single click. Additionally, you can revert multiple good faith edits using rollback much quicker as well, as long as you don't disable to editable rollback summary gadget. Instead of doing the same thing as for vandal edits except adding an extra custom edit summary, just click the pencil button next to the rollback link, quickly edit the summary, press save, and the edits will be reverted right away. Additionally, rollbacking automatically marks edits as patrolled, which is another reason why having a user group that can rollback edits would be helpful.
-- Madminecrafter12
Talk to me
13:41, 5 July 2018 (UTC)