I think there should be a page that shows the periodic table of Minecraft.[[Special:Contributions/71.35.109.25|71.35.109.25]] 16:47, 7 March 2015 (UTC)
Revision as of 16:47, 7 March 2015
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 forums.
Hello ! I often use Wiki in my smartphone with Android. Unfortunately, the site on Android have many mistakes (eg. text is only at left side, images doesn't load or they disappear). It's really frustrating. So I have idea - application for Android wich can be downloaded from Google Play. But someone else must make it because I don't have enough time to make this project. How about you? Please write what are you thinking about that. Sorry for my English. --Mccv13 (talk) 14:42, 2 January 2014 (UTC)
YES! and IOS app too, but it could be an offical Gamepedia android app, so every game in gamepedia has one. --- Tonkku107 (User Page|Talk) 14:45, 2 January 2014 (UTC)
See Talk:Minecraft Wiki#Minecraft wiki app. An wiki app isn't practical, it is a far better use of resources to improve the mobile site. Post screenshots of things that are broken or need improvement. –Matt ᐸ Talk Contribs ⎜ 14:49, 2 January 2014 (UTC)
I just use the desktop site instead of the mobile one on my Android.
Have you tried the mobile site at all? And if so, what are your reasons for not using it? –Matt ᐸ Talk Contribs ⎜ 11:08, 13 March 2014 (UTC)
Deleting images
Hiya, infrequent wiki-editor here. Apologies if this question has been asked before, or if this is the wrong place to ask it, but I'd like to know: If I think there's a reason for an image uploaded to the wiki to be deleted, what should I do? A Moon (talk) 09:52, 7 January 2014 (UTC)
Add {{delete|reason}} to the file's description page. You can also comment on its talk page, if you're less certain it needs to be deleted or feel more explanation would be helpful. -- Orthotopetalk 10:00, 7 January 2014 (UTC)
Thank you very much. A Moon (talk) 10:47, 7 January 2014 (UTC)
Greek Minecraft Wiki
There are quite a few pages with /el subpages, so I would like to propose a Greek translation of this wiki. I have contacted Curse staff, and the staff member that replied says to ask the community. Opinions? Meeples10t ~ c 23:28, 16 January 2014 (UTC)
Translation projects generally only get their own wiki when they are reasonably complete and active. There are currently only 25 pages in Category:Greek translation, most of which haven't been worked on for at least six months. At this point, it isn't ready for its own wiki; it needs to have active translators, and to have a lot more well-translated pages. (Note that running pages through Google Translate does not count as a good translation; a fluent human editor needs to be involved.) -- Orthotopetalk 09:26, 17 January 2014 (UTC)
If I was to translate much more pages into Greek, would that be worthy of creating a new wiki? If I create a wiki, I edit it frequently, so it would be no problem to have at least half as many pages as the English wiki in maybe a day. About Google Translate: I do not use it. I may use it for a word I can't remember (single words usually translate more accurately than phrases or sentences), but that's about all. I can change the input of my keyboard so that it functions like a Greek keyboard (so I can type at normal speed and not have to go back and forth between the "Special Characters" tab of the toolbar and the edit window). Meeples10t ~ c 10:52, 17 January 2014 (UTC)
First off, we don't vote, we discuss. Secondly, Minecraft Wiki/el needs to have all the primary links translated before a subdomain will be created. And I mean, the pages that the links point to need to be fully translated. As it stands, most of those links point to the English pages. That is not resolving the links. If the Greek community wishes to have a subdomain, they need to get active in translating. I also won't create a subdomain if there is only one person working on it, because eventually, you will get burned out and stop, and we will end up with a dead wiki. -- Wynthysttalk 13:42, 17 January 2014 (UTC)
Use of pronouns for player and Steve
I'm considering going through the pages and changing uses of "he" and "he/she" to "They" (I've already fixed the ocelot and player pages). After all, the player could be of a gender that doesnt use he or she pronouns, or simply doesnt use either. They is a catchall pronoun and commonly used as a singular gender-neutral pronoun. I think this would be a good idea so everyone is included; especially on articles which just refer to the player as "he". The wiki is intended for everyone, not just for people who are in the gender binary.
Also, Steve was confirmed to be agender, so they shouldn't be referred to by male pronouns.
Notch himself, who named Steve (originally "Steve?") said that Steve is genderless. "They" or "it" would be the best pronoun to use in my opinion. Meeples10t ~ c 01:09, 23 January 2014 (UTC)
How can I turn an animated texture into a .gif? --tonkku107 «Talk Contribs» 18:31, 31 January 2014 (UTC)
Check the documentation for your image editing program; most competent ones can make animated gifs, but the exact process varies. -- Orthotopetalk 19:53, 31 January 2014 (UTC)
Armor Page Split
First suggested by admin Majr April last year, he suggested that the Armor page should be split up into 5 pages - 1 for each armour part, and one for a basic overview of armour/properties etc. The individual armour parts (i.e. Helmet, Chestplate, Leggings, Boots will detail information specific to those items, e.g. crafting recipe, statistics, etc. Also, the armor page is very long, as you can tell by the massive info box on the side. Splitting it should allow the page to load faster for all devices.
I will collate these pages on my user page, then transfer it over if there is enough support. Please comment below whether you support this change. –Goandgoo ᐸ Talk Contribs Edit count 09:18, 2 February 2014 (UTC)
I think it makes sense to move item info box(es), crafting recipes, item history, etc. to item-specific articles, but much of the rest of the info is useful to have in a compare-against-each-other format, so I wouldn't want to see that split up (they might be reproduced on individual pages, but should also be on the armor page). —munin · · 11:14, 2 February 2014 (UTC)
Yes I would actually suggest a sixth page as well, for "Armor mechanics". The basic armor point and durability tables would be on the main Armor page, while the detailed analysis, formulas, and enchantment information, would be on the "mechanics" page. Also, I'd suggest keeping the grand list of recipes on Armor, but make it default-collapsed (and perhaps loadfiled). --MentalMouse42 (talk) 14:19, 2 February 2014 (UTC)
It seems like no-one is objecting to creating separate pages for each of the armor types, so I will go ahead with doing that. However, I am unsure how much material should be left on the Armor page, and whether an Armor mechanics page is a good idea. –Goandgoo ᐸ Talk Contribs Edit count 07:00, 4 February 2014 (UTC)
PS3 acknowledgement under Upcoming Features
I know this may be trivial but it would be nice if under upcoming feature the PS3 version would be linked as it should even if it is a replica of the Xbox 360 version.
Random page
I think there should be a random page option for the wiki. All the other wikis have one and I enjoy randomly finding pages.
I noticed the fish article was all merged, including Cooked Fish, and I would suggest the same with chicken, beef, pork, and potatos. When looking over raw and cooked steak, I noticed the articles had basically the same information, except each one had it's own hunger information and data value. --KnightMiner(talk|contribs) 15:16, 15 February 2014 (UTC)
My personal opinion is that as many items should have their own pages to avoid confusion. --▶ ZlingerZZ◀ (talk | contribs) 14:05, 21 February 2014 (UTC)
Then I would suggest splitting Fish into normal and cooked, to keep it the same. --KnightMiner(talk|contribs) 18:25, 21 February 2014 (UTC)
Here on my Mac, running Chrome 32, the Minecraft style tooltips (minetips) have a blurry font, unlike the reference image. This is pretty annoying, does anyone know why this happens? —Fenhl 11:06, 19 February 2014 (UTC)
I don't know about Mac, but on Windows if you use DirectWrite it seems to apply a blur to all text. This looks fine for normal font where sub-pixels make the font look smoother and easier to read, but not for font where the pixels line up exactly. This doesn't happen on any Linux distribution I've used, whatever font rendering used looks identical to DirectWrite's superb quality, but doesn't unnecessarily blur things.
Until browsers add a way to specify which font rendering to use, the only way to fix it on Windows is to go back to GDI (disabling hardware acceleration seems the easiest way), which then makes all font not so smooth. –Matt ᐸ Talk Contribs ⎜ 12:19, 19 February 2014 (UTC)
Finding Translation Projects
I've realized that most Translation Projects doesn't have that many active users. I'm in the Swedish Translation project and it took me ages after ive created my wiki account to discover the Translation Project. I think that if there was an easier way than just randomly finding them, the translation projects would have more recruits. Best Regards ▶ ZlingerZZ◀ (talk | contribs) 14:15, 21 February 2014 (UTC)
Hello, I have just started in the Norwegian translation project and I cant find any project leader. In fact very little have been done in several years. The users seem inactive too.
I guess I then may decide by myself how to translate words that can't be translated directly? And edit the other articles to fit to the style I use on my articles. And change layouts that I think I can do better.
I mean, if it isn't anyone there to ask if my edits are okay, and if I do what I can to make it look more tidy, then I can just go on? :) Powerminerdude (talk) 14:13, 24 March 2014 (UTC)
By the way, most of the articles that are done, have grammar with frustrating low quality, and are completely outdated. It looks like it will be a one-man-project for a while, and that I should clean up from scratch even before I start translate more myself. I had a sneak peak on the Swedish projects, and there it was some equally poorly translated swedish. ( I cant write swedish very good but its very similar to norwegian and Danish) Alas :P Powerminerdude (talk) 12:07, 25 March 2014 (UTC)
¨
Yeah I've also seen that the translation projects arent that active at all, and also most of them are outdated and poorly translated. And that I think is caused by just translating the english version instead of freely writing and get information from the english Minecraft Wiki. Also, I don't really enjoy translating the articles themselves, I like translating templates more. But again if we could find a good way to recruit people to the Translation Projects they would probably be more active and more users can fix grammar-issues and keep the articles up-to-date. ▶ZlingerZZ◀ ( talk | contribs| edits) 08:12, 14 April 2014 (UTC)
Awards on minecraft wiki?
Is this [[1]] something to be considerated? Maybe not that huge amount of different awards, and preferably a minecraft inspired award system.
But minecraft wiki should definitively have an award system ^^ Powerminerdude (talk) 23:11, 24 March 2014 (UTC)
It's probably a great idea to give people motivation to continue contributing but the what should the prizes consist of? ▶ZlingerZZ◀ ( talk | contribs| edits) 08:15, 14 April 2014 (UTC)
How do i know if I have vanilla minecraft or not
well i see many people saying that they have vanilla minecraft or bukkit but i am not sure what mine is, i have 1.7.5 version of minecraft and i have done everything i could to find out if it was vanilla or not? i really have no idea and i am guessing that its something super obvious and im just not getting it--107.222.205.198 22:21, 26 March 2014 (UTC)
Most people consider vanilla to if you've installed mods or not. The solution is pretty easy; If you've installed mods, you are not playing vanilla. ▶ZlingerZZ◀ ( talk | contribs| edits) 08:17, 14 April 2014 (UTC)
I should've done it earlier, but....
I just merged my account today, because I haven't had any time then and I just... forgot about it, so I did it today. Why is it telling me my account name wasn't able to be merged, and why do I have this login name with random numbers at the end? And where is my profile? Creepergoboom64 (talk) 03:13, 27 March 2014 (UTC)
Why does my character keep talking as i walk?
My character keep talks or saying things as i walk and didnt before? if i walk on stone he just keeps going " stone stone stone stone" lol how do i stop this? 24.144.251.110
Check your calendar :-) --217.81.252.60 17:44, 1 April 2014 (UTC)
Exactly, today is April Fools' Day! Kingpowl~es.Wiki Admin (talk) 18:00, 1 April 2014 (UTC)
the villager prank :/
Font changing on user talk
Just a question, am I allowed to change the font on my talk page? ▶ZlingerZZ◀ ( talk | contribs | edits ) 13:30, 15 April 2014 (UTC)
Yes, within reason. As long as it's still easily readable, I don't have a problem with it. -- Orthotopetalk 14:26, 15 April 2014 (UTC)
color write
How do Write in chat color???
There's a nice list of formatting codes you can use to change text colour. I hope this helps! EthanCentaurai (talk) 12:56, 17 April 2014 (UTC)
No Captcha
I found a security problem about editing pages.
I found a missing thing in the String page's history (Console Edition TU14)
When i fixed that, no captcha appeared to confirm that i wasn't a spam bot.
Without captchas even a bot can randomly edit the page, damaging its integrity.
Please fix this! (sorry for my english) –Preceding unsigned comment was added by Sbarza (talk • contribs) 12:42, 25 April 2014 (UTC). Please sign your posts with ~~~~
In general, Curse wikis allow editing by anonymous (unregistered) users. Captchas are used in some situations, but have a tendency to be glitchy and not work well for some users. However, there are other filters in place that block the majority of the attempted spam and vandalism. -- Orthotopetalk 15:57, 25 April 2014 (UTC)
What happened?
I haven't been on the wiki for about a week until today, and I was just wondering... what the heck happened? Meeples10t ~ c 22:54, 10 May 2014 (UTC)
Are you asking about the profiles? or just a general list of events? or what is new in minecraft? --KnightMiner(talk|contribs) 02:16, 11 May 2014 (UTC)
Profiles, friends, why I'm getting notification emails every few seconds when I've specified not to send any. Meeples10t ~ c 10:43, 11 May 2014 (UTC)
For profiles, they are a new way to show a bit about yourself, and apparently it stretches across gamepedia accounts. See here for a bit more information. I think friends are along the same line. And as for the notification thing, there is a new notification tab in the preferences to turn it all off (if you haven't tried that yet) --KnightMiner(talk|contribs) 13:32, 11 May 2014 (UTC)
I tried adding my map reader program to Programs_and_editors/Specialized_programs, but the edit failed because your spam filter blocked my url http://mapreader.at [NOT SPAM] space.co.uk/. This makes no sense, there's nothing wrong with my page and it is not spam. In fact, I asked more than 6 months ago on the Talk page if I could just add my program. Since nobody replied all that time, I just went ahead and added it anyway. Also, nowhere in the progress was I ever told that some web hosts were blocked. The url posted fine in the description of the accompanying image, and there were no warnings or errors on 'Preview'ing my edit. Anyway, someone, please add the url (remove the " [NOT SPAM] " message, it wouldn't even let me ask this question), it doesn't make sense for an online tool to not have a url associated with it, thank you. And someone, PLEASE kick the spam filter very hard, it is stupid. DaedalusYoung (talk) 16:36, 31 May 2014 (UTC)
I don't see a mention of this in the filter logs. It's probably an automatic restriction based on the number of edits you've made; once you're in the autoconfirmed user group, this should no longer be a problem. -- Orthotopetalk 20:00, 31 May 2014 (UTC)
File:Spamfilter.pngThat's not the error I'm getting, see attached image. It clearly says that url triggered the spam filter. If it was based on the number of edits, then the error message is wrong. Also, that would mean that, if finally I'd get my url on that page, every time someone tries to edit the page, the spam filter will find the offending link and stop the user from posting, right? DaedalusYoung (talk) 16:17, 1 June 2014 (UTC)
Should be fixed now; sorry about the inconvenience. -- Orthotopetalk 01:11, 2 June 2014 (UTC)
Thanks a lot, that works! :) DaedalusYoung (talk) 17:30, 3 June 2014 (UTC)
Transferring content from wiki.vg
We have been contacted by the people from wiki.vg about transferring their content to here. Their wiki hosts information about minecraft development, which could augment the development information we already have.
We will also need to decide where to put the content. It has been suggested to put it in a Development: namespace, however I'm always wary of namespaces being used simply as a category, so we should decide if there is value in having this namespace. For instance: could there be a lot of naming collisions between development related pages, and other types of pages; and is there enough of a separation between development related content and other content to justify a namespace?
Please leave your comments below. If transferring the content is decided to be favourable, it will be imported by their admin. –Matt ᐸ Talk Contribs ⎜ 02:16, 4 June 2014 (UTC)
Interesting, looks like a lot of it is documenting the network protocol, while we have more on file structures. Might be useful for developers to have all the documentation in one wiki. Looking at wiki.vg/Special:AllPages, it doesn't look like there'd be many collisions with existing pages. If it's really needed for naming disambiguation, we could use a pseudo-namespace like we do with tutorials. -- Orthotopetalk 02:42, 4 June 2014 (UTC)
Some interesting stuff there. And I agree with Orthotope that subpages of Development might be a good place for them, or use development as a hub article linking to the various ones. Would just the information be imported or the entire wiki (users, edit history, ect.)? --KnightMiner 15:06, 4 June 2014 (UTC)
New Feature?
I was playing some survival single player on the 14w29b 1.8 snapshot and I noticed my lily pad spread like a vine! I am not sure this is an intended feature or if it is a bug?
Image Guidelines
Hi there. I asked about this on the talk page for the Style Guide a while ago, but I guess that page isn't very busy. I can't find any guidelines for images, and what they should and shouldn't contain. Can anyone offer any information? A Moon (talk) 22:21, 27 June 2014 (UTC)
Can no longer log in / account does not exist?
I used to be LB, then LB725C when merged with Curse, and then via Curse I changed my account to LB_ with an underscore at the end. My 30 days of being logged in expired and now I cannot log in again, and it seems my account doesn't exist because it tries to ignore the underscore. When I click on my username via one of my contributions (e.g. this one) it says that user is not registered. I have no idea what I should do, can anyone help me? I can still log into Curse just fine. 99.164.78.31 21:39, 12 July 2014 (UTC)
OK, so when I log in with my email address, it says the supplied username is invalid. I am pretty sure it has to do with the underscore because all the links initially have the underscore but it gets stripped when the page loads. Still no idea what I should do. 99.164.78.31 21:48, 12 July 2014 (UTC)
Yeah, the underscore could be the problem. I'd try contacting Game widow, see if someone at Curse can get your account straightened out. -- Orthotopetalk 22:29, 12 July 2014 (UTC)
I'm quite sure that is the issue, but I don't know the solution (yet). I have kicked this up the chain and should hopefully have a fix soon — Game widow(talk) 00:49, 13 July 2014 (UTC)
Thanks guys, I appreciate it. Let me know if there's anything I have to do. 99.164.78.31 00:56, 13 July 2014 (UTC)
I've issued LB_ a global rename credit for now. The Gamepedia platform doesn't support leading or trailing underscores for the time being, so you'll need to choose something without either of those. We'll be looking into putting a block in place so that people don't experience this issue inadvertently with renames in the future! Sorry for the trouble. CrsBenjamin - (talk) 00:57, 13 July 2014 (UTC)
Thanks for the help! I'm able to log in with my new username now. LB(T|C) 02:32, 13 July 2014 (UTC)
I think we must have a discussion about these filters
Firstly,there is a filter which disallows new users to remove sections.But there are lots of reasons to remove a section.(For example,Removing spam/nonsense,etc.)
Secondly,new users may not add external links.I saw a discussion at Minecraft_Wiki:Admin_noticeboard#Delete_the_external_links_filter.I disagree because useful links is much,much more common then spam.Thanks.Please share your thoughts below.Crep987 (talk) 07:04, 17 July 2014 (UTC)
The filters mostly prevent nonsense sections from being added, and you only need to have 10 edits to not be considered a "new" user, so most editors will have no problem removing the small amount of vandalism that gets though. Anyone can add external links, only spam links and URL shorteners are on the blacklist. –Matt ᐸ Talk Contribs ⎜ 07:20, 17 July 2014 (UTC)
Minecraft Splash Messages
I started up Minecraft and saw the splash message "Oh man!" and decided to look up what it may be a reference to. Turns out on the Minecraft wiki page it doesn't have anything linked to it, nor does the splash message "Octagonal!". I just want to make a quick suggestion that those may be a reference to the episode on sesame street when jack black taught the shape octagon, or it could just be referencing the meme. Change the wiki page if you believe this is true.
There's also another splash message I found on the wiki page, "Mmmph, mmph!" needs to be given a description, it's from Team Fortress 2, there is a character named the Pyro who can only mumble because of his suit.
Hey everybody! I've been working a bit on the Dutch wiki and since there are no active admins at the moment, I want to ask here: what's the way to transfer images from the English wiki to the Dutch? Some are already there and some just don't appear if I try. Thanks in advance
Herkio (talk) 08:51, 27 July 2014 (UTC)
Just download the images you want from here and upload them on the Dutch wiki. -- Orthotopetalk 09:18, 27 July 2014 (UTC)
There is an active admin. But just to do some checking after edits by people. :).
Don't forget to download the highest quality image, not the resized one. \
Hi!
The german wiki community discussed a new style for the main page and some templates. The idea is to replace all blue bars with the dirt-texture of Minecraft. It would fit better to the new wiki logo and the top bar. For a draft please visit this page: http://minecraft-de.gamepedia.com/Benutzer:Oliver_Scholz/Minecraft_Wiki
On the light gray background of the main page, it looks much too dark. On the blue content background it's not as bad, but I still don't think it looks very good. –Majr ᐸ Talk Contribs ⎜ 13:46, 30 July 2014 (UTC)
I like the new style. In my opinion, the blue boxes look a bit old-fashioned and does not fit so well with the rest of the wiki as the new boxes. The main page indeed looks a bit dark, but I do not find this bad. I think it is a nice contrast between the title and the content. --Elike98talk 14:19, 11 August 2014 (UTC)
In my opinion, the Minecraft Wiki is not "minecrafty" enough. On the main page, there is not really much (style) reference to Minecraft exept the logo and these Item icons like "Community Portal", "Admin noticeboard" etc. I'd like to see more Minecraft textures on the main page. Also, if you don't like these "dark" dirt bars, why don't use grass bars which reduce the contrast a little bit and also have, in my opinion, more reference to Minecraft? | violine1101(Talk) 14:07, 23 November 2014 (UTC)
Why not use a lighter stone color? It would would contrast well with the dark stone background. –KnightMiner · talk 02:21, 24 November 2014 (UTC)
That also is a good idea! Another option would be to take the default Minecraft button texture. | violine1101(Talk) 21:54, 24 November 2014 (UTC)
Updating All 'Computer Versions' Pages To Match 1.8 Format
The current way version history works is a mess. For the 1.8 snapshots it works great, but trying to go back to the 1.7pre snapshots and earlier leads to a mess of confusing pages, with inconsistent navigation and duplicate / inaccurate information. All snapshots and releases since Minecraft 1.0, at the latest, should have their own pages, with the same navagation as in the 1.8 snapshots. Ideally, the old unified 'version history' page should go away completely. For versions released before 1.0, it gets trickier, but at the very least there should be consistent navigation between each consecutive release.
Yes, the original plan was to use 1.8 as the testing group, but then someone started making pages for the new 1.7 versions that came out while 1.8 was being developed and didn't even convert the existing 1.7 versions, making a confusing mess for that set of versions. Since 1.8 is taking so long we really should just start converting the old pages, there doesn't seem to be any issues with the new format, aside from a few people wanting all the snapshots on a single page, which is impractical for 1.8, but not so for versions with only a few snapshots, so I'm going to make a way to have it as an option. –Majr ᐸ Talk Contribs ⎜ 05:37, 31 July 2014 (UTC)
Great! glad to here there's a plan in place.Tinaun (talk) 05:54, 1 August 2014 (UTC)
Bot - Request
Hello! IdefixBot is a new bot run by ObelusPA2, an admin on the French Minecraft wiki. The bot is using Pywikibot to work on interwiki links. We have tested it on the French Minecraft Wiki. Can you change the status of this user? Thanks. — Itouchmasterprodc 19:29, 31 July 2014 (UTC)
Please add a page or refer me to the minecraft page(s) dedicated to xbox edition. PC edition has many things xbox doesnt seem to be able to do and is extremely frustrating. please help –Preceding unsigned comment was added by 10.64.180.41 (talk • contribs) at 23:48, 3 August 2014 (UTC). Please sign your posts with ~~~~
My Ocean image
Hello, guys! I'm GnomeCustomer, I started my account just yesterday and I would like to know how to upload images into pages. I tried to put my "dry Ocean" image in the World types page, following every single step from the help pages and the 2 other image examples in it, but when I uploaded it, the image wasn't there, only it's name: "Mineshaft_No_Ocean". Can someone help me explainig why this happened or fixing the image for me? Thanks for reading! :)
P.S.: Please don't rage at me, I'm just a newbie...–Preceding unsigned comment was added by GnomeCustomer (talk • contribs) at 11:01, 10 August 2014 (UTC). Please sign your posts with ~~~~
Hi there, it looks like you haven't actually uploaded the file. On the tools in the left sidebar, ensure you have properly uploaded the image and it should work. –Goandgoo ᐸ Talk Contribs Edits 11:49, 10 August 2014 (UTC)
Template needed
There is a template needed for the *Template:BlockLinkClock whatever that is , and it is needed now in the show red stone sectionShooter1166 (talk) 07:04, 18 August 2014 (UTC)Shooter1166
No, you just didn't put the vertical bar between {{BlockLink}} and Clock. Although a clock requires redstone to craft, it doesn't actually interact with redstone power, which is what the redstone navbox is about, so I removed the link. —munin · · 07:38, 18 August 2014 (UTC)
Thank you —munin –Preceding unsigned comment was added by Shooter1166 (talk • contribs) at 20:09, 18 August 2014 (UTC). Please sign your posts with ~~~~
Preview problems!
I'm posting here because there was no other place to post here.
When editing a page, there is a Preview tab AND a Preview button. Seems counter-intuitive, don't you think?
GunslingerN7, Technology and Gaming Freelancer (Talk) 20:06, 19 August 2014 (UTC)
That's maybe just in case the either fails. Naista2002 ♦ 09:23, 3 October 2014 (UTC)
The preview button is the standard MediaWiki preview. The preview tab is from the WikiEditor extension, and loads the preview in place rather than reloading the page, which is much faster and doesn't loose textarea history. Disable the "side-by-side preview" option to get rid of the tabs. –Majr ᐸ Talk Contribs
–Preceding undated comment was added at 09:37, 3 October 2014 (UTC). Please sign your posts with ~~~~
Matt, you accidentally missed a tilde when signing. Naista2002 ♦ 09:47, 3 October 2014 (UTC)
Yeah it's going to take awhile to get used to having to do a full signature again, as I used to have the date as part of the signature. –Majr ᐸ Talk Contribs 09:49, 3 October 2014 (UTC)
Update articles to use style guide
I have noticed many articles, including several new ones, currently do not follow the style guide. I have been working to rewrite articles as I find them, but I was wondering what the best way to actually clean up the articles would be. Basically, should I make it a Project or should I just keep cleaning up articles as I randomly find them? --KnightMiner 17:35, 25 August 2014 (UTC)
I've been doing it randomly. If a project was made, I would contribute to it.
I think it's often better to tackle groups of articles at a time that share a common theme, to ensure that similar content is being written in a consistent way, inappropriate content is being moved to tutorials consistently, etc. —munin · · 21:52, 25 August 2014 (UTC)
I've started the project. It divides the pages needing to be finished into sub-groups of blocks, items, and entities. --KnightMiner 17:57, 26 August 2014 (UTC)
Creating Structure Renders
Hello! I'm interesting how do you create images, like this, i want to update it, because from 1.8, pyramids generates with colored stained glass, not with cloth. P.S I recommend you to rename image, I've linked to "Desert Temple", because it violate wiki rules calling files. --109.68.237.19 04:49, 5 September 2014 (UTC)
The first edit you made to that talk page added the interwiki link. –Majr ᐸ Talk Contribs ⎜ 04:40, 13 September 2014 (UTC)
Majr, I'm talking about interwikis that add a specific translation page to the "In other languages" list. They shouldn't appear on the page itself. That's what I'm talking about. What was going on with my mind that day... –Naista2002 ᐸ Talk Contribs 16:37, 22 September 2014 (UTC)
CSS
Not sure where to put this, so I'm going to ask here. What can I put in my commons.css to add another link under the "tools" section in the left sidebar? Meeples10t ~ c 23:36, 22 September 2014 (UTC)
From what I've found, you will actually will need something in your commons.js. I am not sure exactly how it is done, but in one of Majr user scripts (User:Majr/editcounter.js), there was an additional link added to the tool box. --KnightMiner 23:44, 26 September 2014 (UTC)
I've noticed the wiki currently contains a major mess of features that are not in the game. We really need to have official policies to organize them.
First off, there are many pages floating around saying "Notch tweeted he wanted blah in the game, but it has not been added yet" or "Dinnerbone showed off this feature, but it may have been a command visuals instead". Secondly, many articles are littered with "In the future, this may also do blah". Finally, the page about Unimplemented features is a complete mess of features in the game that do nothing, features that were removed, and features either mentioned or dropped in development, and part of it's information is given a spotlight on Upcoming features.
I came up with a solution, although it requires a new rule, a revision to the Style guide, and a rewrite of both Unimplemented features and all versions Upcoming features. The main reason I am mentioning it here rather than on the other pages is any of those changes by themselves would be in vain if the others were not added.
The new rule would be in the style of the rule about tutorials and would state as follows:
Features that are not currently in the game should be in the versions Upcoming features article.
This excludes features with have been removed, which may be noted in either their own article or in the proper articles history section.
This also excludes features from development versions, which may be noted on articles affected by the feature and the relevant upcoming version article.
I know this rule would remove the article 1.9, but really there is no reason any of those features may not be delayed for a later update, as most of them are listed as 1.9?. Some are simply what a dev wants to do in the update, while some may be actually be being coded.
The style guide will need a rewrite of its section on future features, as it overall works better to use templates like {{upcoming}} to note features not currently in the game. It would state that any features that have appeared in development versions should be noted using {{upcoming}} and the development version it was added in.
Features planned for the next update, except features already noted on a upcoming version page, which will be linked to.
Features mentioned by mojang as upcoming. These are less likely to get added soon, so the section will be smaller.
Features dropped in development. These features had valid sources that they were upcoming, but were canceled for various reasons. This section may be better stated as the article Canceled features.
I know this is a lot to read, but hopefully this plan can solve the problem. Even if this plan is not used, I do believe either a revision to the style guide or the rules is necessary to sort all the excess of planned features, otherwise it is simply hard to read and leaves many stub and inaccurate articles.
I definitely agree that we need to remove potential future information from articles - listing that Notch/Dinnerbone etc may add something is not helpful as it may never enter fruition. I also like the idea of using unimplemented features for features which appear in game but have no use. What I am currently not sure about is the changes to the Upcoming features page that you mentioned. Upcoming implies that those features will most likely eventually make it into the game, but listing features there that were initially stated to be planned for a version but have not made it into the actual version seems rather counterintuitive as those features ar no longer upcoming, even if they were at some point. Hence I think cancelled features makes more sense.
Just for clarification, where would a page like Lantern go? There were plans for it but it was dropped, so what that be in cancelled features?
What about features that were in the game, but are now not? E.g. obsidian walls, brick pyramids
What happens to features that were mentioned as upcoming, but seem unlikely to be added due to context/time elapsed. e.g. Capture the flag was mentioned way back by Notch, but now since Notch is no longer developing Minecraft and command blocks etc can replicate this functionality it seems unneeded as a stand alone game mode. –Goandgoo ᐸ Talk Contribs Edits 05:47, 28 September 2014 (UTC)
Also, one of the problems with the other planned features on the upcoming features page is that many of those features seem like they will never actually be added because of time elapsed. For example, back in 2012 Dinnerbone tweeted that buckets will be fillable from cauldrons. It seems likely that this has been forgotten by now and therefore may not really be upcoming at all. –Goandgoo ᐸ Talk Contribs Edits 05:53, 28 September 2014 (UTC)
The way I see it, there are three main categories of unimplemented features:
Upcoming features: Things that are in snapshots, but not yet in release versions.
Unimplemented features: Things that have been mentioned by Mojang, but aren't in snapshots. They may have been cancelled (publicly or not), abandoned, forgotten about, or maybe they just haven't started releasing snapshots for the next version yet. Either way, they've been mentioned, but not implemented in any version available to players.
Removed features: Things that were in the game at one point, but have since been removed, and aren't in the current release or dev version.
Arguably, things that are mentioned as being planned for a specific version could be considered Upcoming, but once snapshots for that version are released, they should be moved back to Unimplemented if they aren't in a snapshot. -- Orthotopetalk 06:52, 28 September 2014 (UTC)
@Goandgoo: Lantern would be placed on canceled features, with a note that lanterns have been added.
Features that are in the game but are not longer would either be in the proper history section (eg. obsidian, brick), or a removed features article.
As for capture the flag, we really don't know whether it was dropped in dev or is still planned, so it might work best on a new article mentioned features, or on upcoming features which would list features mojang suggested, but are not currently adding.
@Orthotope: What about the features that are in the game, but currently do nothing? Such as we really don't need a whole article on a single sprite in the items folder.
As for upcoming features in general, we will already have a version article listing all those features, and simply transcluding it really looked bad. It may be better to list "upcoming updates" with a link to the proper version then "features planned for upcoming updates", rather than all the features in the new update.
Features planned for an update that might not make it are often very few, which is why I think they should be merged with the features mentioned, but not in development.
I would like to see upcoming features removed entirely. The first half of it is content from the individual upcoming version pages, which should instead be linked to on something like upcoming versions, and the second half is just random things that have been mentioned at some point and we have no evidence to suggest that they are "upcoming", so they belong on unimplemented features.
I agree with having a removed features article. Individual pages on things like crying obsidian (which was just an unused texture in a file for a couple of versions) are really unnecessary. –Majr ᐸ Talk Contribs ⎜ 02:53, 30 September 2014 (UTC)
The problem that I see with simply stuffing everything into the unimplemented features article is that they imply that the features are there but simply not implemented, which is not always the case - many of the features were just mentioned at some point in time, with potentially no hope of implementation. But I agree that perhaps upcoming features page is not necessary. –Goandgoo ᐸ Talk Contribs Edits 03:07, 30 September 2014 (UTC)
Does unimplemented imply that the feature is there (aka... implemented, just not fully)? Surely it implies the opposite? But either way, I'd be fine having a separate mentioned features page. Anything is better than what we have now. –Majr ᐸ Talk Contribs ⎜ 04:41, 30 September 2014 (UTC)
Unimplemented does sort of imply it exists, but is not implemented, although it could also refer to an unimplemented idea. I think a separate mentioned features page would be best, and simply use {{about}} to help readers searching for those, or renaming it to unused features. The title "Mentioned features" could also cover the features that were implemented, but never made a development version or release, such as lanterns or custom cloud height. --KnightMiner 04:48, 30 September 2014 (UTC)
Upcoming features: features that are not in the game, but have been confirmed to be in a future update. It will links to upcoming updates and lists upcoming updates that have not had development versions. Will be either be renamed to upcoming versions and link to any updates with development versions.
Mentioned features: Features ideas from mojang members that are not in the game,. It will also contain features that have not appeared in a development version.
Unused features: features in the game that currently do nothing, such as the unused potions or sprites in minecraft.jar. Will also mention features that were removed and did nothing.
Removed features: Features that were removed from the game, such as generated structures, blocks, ect.
I'm not sure about upcoming features. Until a feature actually appears in a development version, I don't think we can count anything as being "confirmed" for a future update. And once it appears in a development version, then it'll be on that version's page, so there will be no need to duplicate it on upcoming features. I say redirect upcoming features to upcoming versions.
As for unused features mentioning features that were removed and did nothing, shouldn't that go on removed features? –Majr ᐸ Talk Contribs 03:29, 23 October 2014 (UTC)
That sentence I forgot to remove when finalizing the plan...
Yeah, I guess I agree they would go well on mentioned features. Upcoming features could simply list an link to upcoming updates, or be removed as the links on the main page do well. (would not have a lot of content).
The pages are finished within my sandbox. I can import them into the actual pages if the consensus is to use them. I am really not sure about upcoming versions, as there really is no content to put on it. But other than that, there is mentioned features, unused features, and removed features. These pages will ultimately replace the various pages that simply described an idea of a developer or a sprite in the game.
Opinions? –KnightMiner 17:16, 25 October 2014 (UTC)
Looks good. Pages such as Crying Obsidian, Lanterns etc and anything in the Unimplemented category can also get redirected to these pages. –Goandgoo ᐸ Talk Contribs Edits 00:47, 26 October 2014 (UTC)
Upcoming versions is very much dependent on Mojang's activity, so it's the sort of page where I'd consider a lack of content to be acceptable. The main page only displays versions that have come out (development or otherwise), so I wouldn't consider it a replacement. We could try to extend the amount of information on the page by also including upcoming versions for other editions, and maybe include versions that are coming in the future (1.9), although then we may want to call the page "planned versions" to make it seem less immediate.
I don't like the duplication of version content in the "planned for an upcoming update" section in mentioned features. I think removing the fixes section would help (fixes aren't really features, anyway) and if we expand upcoming versions to include planned versions, then I think the section should be removed entirely as planned versions would replace it. Otherwise, I'd say link to the version pages themselves and just provide a basic list of features, without the descriptions (the version pages already have that extra information).
As for the other pages, aside from a few minor spelling/sentence errors, they look good and I would support replacing and moving existing pages with them or moving them to the mainspace and redirecting any pages they supersede, as appropriate. –Majr ᐸ Talk Contribs 06:41, 26 October 2014 (UTC)
Put them on the same page and use {{pocket}}, etc.? –Majr ᐸ Talk Contribs 09:21, 26 October 2014 (UTC)
Agree with the proposed structure, but, KnightMiner, maybe make this project located where it belongs (say, at Minecraft Wiki:Projects/Upcoming, unimplemented and mentioned features rewriteMinecraft Wiki:Projects/Upcoming and unimplemented features rewrite), not in userspace? This would make more sense. --Naista2002 ♦ 09:42, 26 October 2014 (UTC) (with edits at 09:43, 26 October 2014 (UTC))
Projects are for larger, more widespread things involving multiple users, not just a quick rewrite of a couple of pages as a demo. –Majr ᐸ Talk Contribs 12:29, 26 October 2014 (UTC)
I was originally planning on the other versions getting their own page, such as we did with "upcoming features", although I wouldn't be against it being on the same page.
The "Planned for an upcoming update" was intended to replace pages such as 1.9 (which have no development versions), since all its major sources are either mentioned features or a bug tracker to do list. It would make sense as merged with upcoming versions under the title planned versions, or we could just leave it as its own page and clearly mark which features are added upon development version release, then simply link to it (brief summary would not really be needed).
I have changed "Upcoming versions" to "Planned versions", and it now covers features planned for an upcoming update, but not yet included. Should we add features planned for a update with development version on the article itself? We did that with 1.8, and it stopped most of the IPs from adding mentioned features as current features.
It looks alright. We probably need to work on having individual pages for the other editions next so we're not copy-pasting the content from that page to its version page when it does eventually get released. I'll need to fix the version nav template to work properly with other editions.
I'm thinking we might be able to just get rid of that template. All the links it has should be in the navbox, so do we need it? We also have the disambiguation page to point people to.
Maybe a feature where there is some actual information about it and it seems certain that it will actually get into the game could get a page. Otherwise, I'd say a redirect to the appropriate place at most.
You mean removing the edition name from the version title, without having to change the link? Basially what was done in {{history}}
The disambiguation page would be sufficent, although it should likely link to to mentioned features.
But what is defined as actual information? A signal screenshot was considered sufficient for slime block, but even with all the information given on lanterns those never got added. We would need to define something as to what is declared sufficient information, such as what Plugin API has - we know it is upcoming, and not simply an idea, as recent changes were directed towards making it possible; although, it still has yet to release.
I'm not sure if mentioned features really belongs on a disambig page for version history. It's not a version or history (in regards to it being added to the game).
I suppose you could base it on if the article would be considered a stub. But maybe it would just be easier to disallow them entirely until a (development) version contains them. We could even get rid of Plugin API. While we know that progress has been made towards it (and maybe you could consider that progress a partial implementation) and it is most likely going to be implemented at some point, Mojang could easily drop it or keep delaying it for a long time. It was originally going to come out in 1.3, which was released over two years ago. It can hardly be considered "upcoming".
Yeah, that makes sense. Would removed be relevant on the version history disambig? Otherwise it can be left to current versions.
Yeah, we have no garentee it will be released, and there is not too much content on the article to move into mentioned features. Although we do need a good place to place the policy should we make it official, as simply referring to this discussion anytime a future feature page is created would not go over easily. I proposed something on the rules talk page, since that was where the rule about tutorial existed; although, it may be a better idea to create something similar to WP:Notability, only describing required locations of content (mentioned on mentioned features, tutorial as subpages tutorials)
I think there should be a Random Page button (Doesn't go to Talk pages, only goes to Wiki pages) on the main page. If someone is bored, they can click it then learn all about Villagers, for instance. It might take someone to a page they never would've visited before, or it might expand their Minecraft knowledge. I know this is a suggestion and not General Discussion, but there's no way else to tell everyone.
We have one, Special:RandomPage. You can reach it from the special pages link in the tools section. It is not directly on the sidebar because of an excess of language translation, mod pages, and other pages you would not need to be directed to. --KnightMiner 01:55, 30 September 2014 (UTC)
Still receiving emails although I specified not to
This is my notifications settings: http://imgur.com/HyPEE5D
This is my email: http://imgur.com/LeITtwQ
I have not changed my settings in weeks, but the reality contradicts the settings. Is there a way to fix this? LB(T|C) 04:31, 30 September 2014 (UTC)
Those emails come from the general email settings section of the main preferences tab (which was enabled by default in MW1.23), not from Echo. –Majr ᐸ Talk Contribs ⎜ 04:34, 30 September 2014 (UTC)
Woah, thanks! Why are there two different places for email settings? Oh well, problem solved. LB(T|C) 04:56, 30 September 2014 (UTC)
It seems curse disabled the location from echo, it is only in the profile now. --KnightMiner 04:59, 30 September 2014 (UTC)
Page merging and splitting policy
As brought up on Talk:Wet Sponge, we really need some form of standard of what pages should be merged and split. For example, we currently have various pages of blocks that are separate or merged simply because of data values.
We should likely come up with a system of merging based on usage. For example, Sponge and Wet Sponge have a different function, while the different types of Flowers are all fundamentally the same. Dirt, Coarse Dirt, and Podzol are also rather inconsistent when it comes to merging.
If we put in sub-headers, we can talk about individual criteria, and have votes.. I'll start with one, though I know there should be others too – Sealbudsman (Aaron)T, C, b 17:52, 30 September 2014 (UTC)
How likely that readers interested in page A will need to visit page B
I advocated for this just now on Talk:Wet Sponge. In my opinion, if blocks A and B are closely-enough related that a reader visiting either page A or B will mostly likely need to move to the other page to complete some crucial understanding of a topic – then that the reader would be better served with a single page.
I do not mean to imply this as a comprehensive criteria.
Examples: A reader of Wet sponge will almost surely also want to read the contents of Sponge, and vice versa, because of the relationship between the two blocks and how they are used. A reader of Podzol would not really need much information from Dirt, if any, so this particular criteria would not apply (Though other criteria might).
That seems valid. While rewriting articles, one of my main goals was to avoid sending people to another page just to get the information. Such as magma cubes claiming to behave like slimes. Pages should definitelly be merged if their only usage requires each other. —KnightMiner 18:02, 30 September 2014 (UTC)
As I have mentioned a few times, if two pages contain the same primary usage, they should be merged. Examples include different types of flowers (all simply are decoration and create dyes) or all the types of fences (all have the same basic behavior, and noting connections between nether brick and wood is better done on one page). —KnightMiner 18:02, 30 September 2014 (UTC)
Mossy and normal Cobblestone Walls would meet this criteria. They might even meet this criteria so far as to merge with Fences – not to open a can of worms, just to say maybe we could try to articulate some other rule why Walls might not merge with Fences.
I think Cobblestone and Moss Stone themselves would not meet this criteria; Podzol, Dirt and Coarse Dirt would not; The Stone Brick types I think would (all decorative); Stairs merge with this rule, so do Slabs.
What do you think about doors, trapdoors? – Sealbudsman (Aaron)T, C, b 18:19, 30 September 2014 (UTC)
Doors/trapdoors are all the same, except iron cannot be opened by hand, everything else would be redundant to mention on two pages. With the dirts, each one just has one unique trait (podzol requires silk touch to collect, dirt allows grass/mycelium spread, coarse dirt hoes into dirt).
Although I would agree that if the obtaining is still significantly different, they should not be merged, such as with most building blocks, and the various types of dirt.
As I've recently (and briefly) said on Talk:Red Sandstone, if blocks with different block IDs use block data/block states for minor things like orientation, their pages are allowed to merge (e.g. fences and doors). But if they use them for many different block variations (like sandstone and red sandstone), they are not to be merged. The only exception is when variations of a single object deplete one block ID's data and require another block ID, like in case of wood.
Really if they share the same origination/rotation, they either have the same usage (see above), such as fences or doors, or are rather different in most other aspects, such as droppers and dispensers. –KnightMiner · talk 21:55, 20 November 2014 (UTC)
Reverting consecutive edits
How can I revert consecutive edits without editing text manually? —Naista2002 ♦ 06:15, 6 October 2014 (UTC)
Press edit on the revision you want to revert to, then save. –Majr ᐸ Talk Contribs 06:16, 6 October 2014 (UTC)
Thanks, let me try... —Naista2002 ♦ 06:34, 6 October 2014 (UTC)
Then, how the message like this can automatically appear in the edit summary?
You'd have to type it manually. –Majr ᐸ Talk Contribs 06:58, 6 October 2014 (UTC)
Minecraft Wiki namespace shortcuts
Names of pages in Minecraft Wiki name-space tend to be big. So I suggest making short-cuts to these pages, similar to Wikipedia. (Use {{Comment}} for answers.) --Naista2002 ᐸ Talk Contribs 07:47, 29 October 2014 (UTC)
Can you give examples of what kinds of shortcut you're looking for? The Project: and Project talk: namespace aliases redirect to Minecraft Wiki: and Minecraft Wiki talk: respectively. There are also specific redirects for Projects and Wiki Rules. -- Orthotopetalk 09:42, 29 October 2014 (UTC)
Redirecting to specific projects is not really needed, but a namespace shortcut may be helpful. Such as "MCW", "MC", or "MW". (also, we have Style guide) –KnightMiner 14:26, 29 October 2014 (UTC)
This has been proposed before, but nothing has happened with it. It's a pretty simple setting change, so I don't see any reason it can't be done, so I'll follow up on it. –Majr ᐸ Talk Contribs 04:29, 5 November 2014 (UTC)
MCW: and MCT: namespace aliases can now be used. –Majr ᐸ Talk Contribs 06:02, 26 November 2014 (UTC)
One of those isn't a shortcut, but yes some common page shortcuts would be good. We should agree on which pages need shortcuts and what those shortcuts should be. The shortcuts should remain in the project namespace, the style guide shortcut is an exception as it is already in use and was made before we had the namespace shortcut. –Majr ᐸ Talk Contribs 05:21, 27 November 2014 (UTC)
There are some long names for project names. We can make a shortcut MCW:P for MCW:Projects, and then MCW:P/RFS for MCW:Projects/Rewrite for Style; MCW:P/ID for MCW:Projects/Indonesian translation (if it does not conflict with other shortcuts!) and so on. --Naista2002 (talk|contribs) 16:57, 27 November 2014 (UTC)
I suggest unite them, because they have not big difference, only texture. --Dand0 (talk) 12:03, 31 October 2014 (UTC)
I don't see any reason for merging them; these pages are big and the resulting single page will be messy. And, remember, when requesting a merge, post about it on a talk of one of the pages to be merged. --Naista2002 ᐸ Talk Contribs 12:22, 31 October 2014 (UTC)
Community portal content page redesign
The community portal content page is really lacking in usefulness, as most of its current content either outdated, random requests with no followup, or sends you to another page.
Hot discussions really never happen, or at least there is no guideline on what to add here. The occasional discussions that have wiki breaking changes already tend to be on the talk page.
Current wiki news really needs some form of a guideline as to what is defined as "current" and "news", as its only item is an very old item about the gamepedia merge.
Wanted pages is random requests for pages that normally are not followed up.
Requests for comment needs a better system to propose requests, and a better format for such requests. We also should remove requests that are at least six months old, unless they are still active, in which case it may be relevant in Hot discussions
Really a redesign of the page may be in the best interest, such as follows:
Merging Other perennially useful pages and Style guidelines into one section at the top called Useful pages.
A section called Active projects might be helpful for users to know about current projects, otherwise the projects page should be linked in Useful pages
Current wiki news could really be removed, or we need some way to add content to that section (maybe results of Hot discussions?)
Hot discussions should be expanded to contain any discussions that are rather active, such as the merge proposal on Red Sandstone. It could even link to active community portal discussions that are active.
Then we have Requests for comment, which will be contain a list made using a template to format requests. Each request contains a page, section, a description, and a date. Requests that are over six months old without any action should really be removed.
Wanted pages should either be removed, or maybe moved to its own page. If it is to remain on this page, I would place it near the bottom. Many of those are single person requests, and a lot of them are either not descriptive, or better suited elsewhere than a wiki (like maybe a forum).
I agree that a redesign of the page is necessary. I think wiki news should go altogether. The only problem with your plan is that there may be some overlap between hot discussions and request for comment - when does a request for comment become a hot discussion etc. –Goandgoo ᐸ Talk Contribs Edits 23:55, 15 November 2014 (UTC)
My idea was to move the page link from requests for comment to hot discussions if it is very active, especially if it is out of time for a request for comment. It would basically be request for comment, only it would contain places many people are posting at the time (maybe as a subsection, as any hot discussions we would request comment anyways). A request for comment would upgrade to hot discussion if three or more people are actively posting/debating (active could be defined as four or more replies within a week maybe), although that definition may need a bit of work.
I would agree to removing wiki news, the only uses I can think of are wiki breaking changes (which rarely happen) and updates (which would do better as a sitenotice) –KnightMiner 01:51, 16 November 2014 (UTC)
Obtainable Items page
I have an idea for a page, though I'm not sure if it would be welcome or not. In addition to the ever-so-useful renewable resource page, I personally would really like to have a list of every obtainable item/block, whether or not they're renewable. Being a completist, I'd really like to develop a world that has established regions for quick and easy access to every resource in the game (and I'm reasonably sure I'm not the only one). Most players have a designated mine area, and some survival servers deliberately try to position areas for harvesting useful resources (like the Mesa biome's collection of Hardened Clays) such that they minimize interference with the natural landscape).
As it stands, a player working on this kind of project has to either already know what's available (a list that grows significantly on every update, these days), or has to dig through the full list of blocks and the list of items, and sort through which blocks are just the placed form of an item (for example - the 2 types of door block, vs a door in your inventory).
If the table is made sortable, it could potentially contain all the information from the renewable resource table, too - A column could tell us if it was non-renewable, or renewable through farming, trading, mob grinding, or craftable from renewable resources, etc.
I would be willing to lay the foundations for such a page, but I don't want to do so if moderators will immediately dismiss the idea as superfluous and delete it again. (It might be an interesting project for me, anyway - I really should devote the time to learning how to do things in wikis other than display words and sign things.) Rashkavar (talk) 18:27, 8 November 2014 (UTC)
I really don't see the point of such a page, as if you refer to data values, the text for blocks and items is colored based on if you can obtain the item. Methods for obtaining also also best discussed on the individual page, as most items have many methods from crafting to generation to drops. –KnightMiner 18:54, 8 November 2014 (UTC)
While this information does already exist elsewhere, the sortable table idea is interesting. You could create it in your userspace (for example, at User:Rashkavar/Obtainable items) and use it to experiment with learning MediaWiki syntax. If people like the results, it could be moved into the mainspace. -- Orthotopetalk 21:58, 8 November 2014 (UTC)
It has come to many of our attentions that the infoboxes are becoming excessively long, and as much of its information is now being placed in other sections, we should really decided which content still belongs in the infobox. I am starting this discussion here, as it affects all our infoboxes, rather than just the blocks.
Really the infobox should be a brief summary of general attributes, based on how useful it is to the player. Some rows have a few problems, for example:
Requirements does not help much, especially since it has not worked properly for over a year. Even assuming it did work, all it states is dirt/sand and sunlight or darkness.
Spawn on entities is rather long in many cases, as it must state several methods of spawn, as well as dimensional requirements (and in some cases, block type), either it needs to be slimmed down, or we simply refer to the spawn section.
The first version really does not affect game play much, and when playing older versions you really should use the entire history section anyways.
Is data values (and the entity's variant) really required in the infobox? We have a more descriptive data values section it could be moved into, and people looking to quickly grab a block by value could much more easily check data values.
Do sounds really belong in the infobox? Really where would sounds belong?
Also, what about sectional links that replace content? For example, with many block hub articles it makes sense to move data values to a section, but does drops really need a sectional link as well?
I agree that Requirements, Spawn, firstver/multiplevers, and data values should be removed in favor of just discussing the material in the article. I'd also remove gravity/Physics since it only applies to a few blocks and should be discussed in Usage. Even block's type and transparent are questionable, since both solidity and opacity can be complicated. Tool and hardness are now discussed in Obtaining, and renewable probably should be discussed in Obtaining (providing a brief summary of how it's renewable). Flammable is actually a little more complicated than Yes/No (some blocks, like doors, allow fire to spread but don't burn themselves).
I would also suggest even putting all of the remaining entries in a collapsed table, so that it would just be the pictures, then "Details [show]" or something. —munin · · 19:03, 14 November 2014 (UTC)
I also agree on removing Spawn, Requirements, firstver/multiplevers and firstdev. For Drops, mobs which have a lot of drops like zombies and chicken jockeys make infoboxes really long. (chicken jockeys have 14 possible drops). LauraFitalk 21:16, 14 November 2014 (UTC)
I generally agree, more specifically:
Requirements can be stated in Spawning/Usage/Behavior (if ever!), depending on in which sense it is used, and the infobox can have a link to that section.
Collapsible tables don't always work, so I don't think it's a reliable way.
Firstver/multiplevers can be rerouted to History; however Firstver is quite short, so it may be kept.
Same with Firstdev. It is short, so in normal situations can be kept.
The problem is firstver and firstdev cannot still be short when we include editions other than the PC, and really does not help the reader much as most readers play the latest version, and those who don't should already be reading the history section for differences. –KnightMiner 15:21, 15 November 2014 (UTC)
Regarding drops: I think that they should be renamed common drops (as on the wither page) and only include the common drops (eg. bones & arrows for skeletons, and rotten flesh for zombies). This allows for quick info while keeping the info box short. For mobs such as chicken jockeys, perhaps we could just put something like "regular zombie/chicken drops", with a link to the Drops section? -Sonicwavetalk 03:13, 18 November 2014 (UTC)
When collapsible tables "don't work", do they fail gracefully? If they fail by not collapsing, then that's fine -- most people will have a collapsed table, and the rest will still be able to see the info. But if they fail by collapsing but not allowing uncollapse, then I agree that would not be acceptable (though that would mean we shouldn't use them ever). —munin · · 15:33, 15 November 2014 (UTC)
Only problem I see with collapsible tables is the infobox size changes at the press of a button, the rest I can find would be visual preference (I like uncollapsed a little better too) –KnightMiner 15:39, 15 November 2014 (UTC)
I agree with moving requirements to usage or behaviour.
Spawn could perhaps be reduced to a "Spawns in" section, which only lists the dimension, with further spawning defaults in the spawning section.
First (dev) version used to make sense before all the other editions came along. It was useful for people not playing on the latest version so they could see straight away if the feature doesn't exist for them yet. But with other editions adding all these features, the section is always going to get a bit lengthy, so I think getting rid of it and just using the history is best.
Data values also used to be simpler and so a single entry in the infobox was usually enough, now that's not the case, and we also have some really nice data values sections, which are much better to direct people to.
Nuke sounds entirely. What's the point?
Long drop sections should be replaced with a section link, but small ones with just a few (3 at the most?) should remain. I'd also like to see the drops section be an improvement over the infobox section it is replacing, rather than worse, as it is now (unstructured and lack of images).
Section links should remain for all migrated information for a transition period (at least until all pages are done). Past that, drops is probably the only one that should keep a section link as only the long sections will be moved out of the infobox. Section links shouldn't be duplicated, for example only put a section link in {{{drops}}}, leave {{{commondrops}}}, {{{raredrops}}} and {{{equipment}}} empty.
@Naista2002: Can you clarify when collapsible tables don't work? I've only seen a single edge case where it wasn't working (single cell table with only images, and no text), which was fixed. –Majr ᐸ Talk Contribs 09:34, 17 November 2014 (UTC)
nameid also gets very long when there are multiple blocks/items on the same page. As for sounds, I don't know where to put them. LauraFitalk 01:59, 18 November 2014 (UTC)
All sounds are already documented at sounds.json, along with the in-game events which trigger them. If there's a need to put playable sounds on the wiki, we can just put them there? —munin · · 02:10, 18 November 2014 (UTC)
munin295: that is a good idea, if we don't have any place to put sounds in block/item/entity pages. LauraFitalk 02:29, 18 November 2014 (UTC)
I personally see the sounds.json page as a page describing the sounds.json file (a file which basically links sounds to sound events, used for resource packs) rather than describing sounds itself (and besides that article is long enough already). However, I'm considering expanding the sound (disambig) page to include all of the sounds (as well as basic info such as sound range/distance, etc). -Sonicwavetalk 03:05, 18 November 2014 (UTC)
Or just create a sounds page. LauraFitalk 03:15, 18 November 2014 (UTC)
Some of the drops sections look decent, although the problem of a lack of images is not easy to solve without placing images within the text, which would just end up looking bad. A table could be a solution.
I would prefer to list all of the drops in the infobox, though on jockeys and witch it would be to long. Although, with the rest of the infobox slimming it would fit well in most other cases.
As for migration, couldn't we start that with history now (via hardcoded see history)? On almost every article it is already incorporated into the history section. –KnightMiner · talk 05:36, 18 November 2014 (UTC)
For clarification: firstver and firstdev condense into one line when viewing the page (even though they are 2 lines in the editor), so linking it to history doesn't actually save infobox space :). Although for old versions we could leave only the firstver or even get rid of the section altogether (instead of linking to history).
I agree that data values could be removed (especially since we use name ids now). -Sonicwavetalk 05:10, 20 November 2014 (UTC)
Linking to history was for the sake of transition, and because adding pocket, console, pi, and multiple items on a page caused it to get rather long. –KnightMiner · talk 05:26, 20 November 2014 (UTC)
HESI Project
Hi,
The Highlighting_Edition-Specific_Information (HESI) project was recently confirmed discontinued by its owner Augurnz (IP only). So I was wondering, would anyone be willing to take this project over? (Or change or even delete it). -Sonicwave (talk) 05:52, 14 November 2014 (UTC)
It may be better rather than simply bringing back the project to revamp it, as it is a little vague as to how to accomplish its goal (or at some points what its goal is). –KnightMiner(t|c) 17:47, 14 November 2014 (UTC)
As for some specific ideas, the infobox could use a parameter denoting version, as {{pocket}} and alike look really bad along side the infobox.
Really it comes down to one decision, do we describe features from all versions, then say "In the PC edition" and alike, or do we describe the PC edition, then state "But this is not in the Y edition"? –KnightMiner 04:29, 15 November 2014 (UTC)
I definitely believe that version specific information needs to be highlighted more in articles through a project with clear and comprehensive guidelines. I think using the PC version as the standard and mentioning what is different in other versions (much like what is already happening on much of the wiki) is how the wiki's information should be organised. –Goandgoo ᐸ Talk Contribs Edits 12:53, 15 November 2014 (UTC)
Outdated info in tutorials
I see that tutorials sometimes have obsolete information (as well as a few pages about the game features such as blocks), since I don't see people paying attention to that. I think that a project could be made here, so to get rid of obsolete information in tutorials.
Yes, like that. Another example: Tutorials/Shelters#Other at some point states that carpets aren't flammable, while they were made so in 1.7, more than 1 year ago. I saw even more obsolete content: on Russian wiki, there were articles saying Beta 1.9-pre instead of Beta 1.9-pre1; it was only actual more than 3 years ago. However, I did launched a project there.
Now, more to the project: When I receive approval, I'll immediately launch this project.
A project of this nature is a good idea, marking pages with Rewritten tutorial or something like that. –Goandgoo ᐸ Talk Contribs Edits 23:53, 15 November 2014 (UTC)
I don't think something like this actually needs admin approval, just the agreement of several regular editors. If pages are outdated, you can go ahead and update them even without a formal project. -- Orthotopetalk 23:33, 20 November 2014 (UTC)
The project allows to keep track of done pages and manage them.
It seems that a lot of the mods listed in the Mods Category are very outdated (for example CamelOre is still in Beta 1.6.6). Also I don't know if people are actually updating these pages anymore, meaning that some mods that have updated to 1.6/1.7 haven't been updated for quite a while on this wiki. Many of these pages also seem very disorganized.
Many of the better known mods already have their own wikis; and besides I have yet to hear someone on the MC Forums refer to this wiki for mod information.
So the question is: should we still include pages on specific mods? Sonicwave (talk) 09:28, 12 November 2014 (UTC)
I personally do not find the mod pages very useful, as very few people actually work on the pages, and most mods should be documented on their download site anyways, otherwise who would download them? The main reason we have them might have come from the earlier days of Minecraft Wiki when there were fewer mods, and the most popular mods got documented here. We also declare at the beginning of the pages that we do not support the mods, yet we host information about them...
Largely out of date mods and mods that have had little backing on the wiki I believe should be removed. Really linking to the website, forum thread, or even mod's wiki would be better, as those would all be updated more. –KnightMiner(t|c) 01:00, 13 November 2014 (UTC)
In addition, I archived the modlists that were on the Mods page a while ago, so I think that the wiki should even go as far as not hosting any mod pages. –Goandgoo ᐸ Talk Contribs Edits 23:52, 15 November 2014 (UTC)
Not every mod developer has the time/resources/etc. to set up and admin their own wiki, so I think it can be beneficial to the Minecraft community to allow documentation of mods here. If the mod pages aren't being updated, it's probably because the mods page no longer provides links to them, making them harder to discover. I would vote for adding a list to the mods page saying "This wiki provides some documentation for the following mods:" and see if that helps.
If we do decide to take the drastic step of deleting information from the wiki, we should at least put a notice on the pages saying that they are being considered for deletion so that anyone who might still be using them can raise objections and discuss alternatives. I know MentalMouse42 was working on the Thaumcraft articles this summer -- he might want to save them to his userspace or something. —munin · · 00:21, 16 November 2014 (UTC)
I mostly agree with Munin. Thankfully, there are wikis on Wikia about Minecraft mods, e.g. here. Wikia is more maintained than this wiki, so there it might be more up-to-date. For listing mods, one could look into [[Category:Mods]]. --Naista2002 ᐸ Talk Contribs 12:41, 16 November 2014 (UTC)
The reason the mod articles are poorly supported is because this Wiki is pretty hostile to mods, it's pretty discouraging. You've got aggressive disclaimers, and a ban on mod discussion or modded-game images outside the Mods/ articles themselves. In Thaumcraft's case, I've been saving info here because the alternatives were generally in poor shape, and I had trouble logging into some. I'll check out Wikia. And yeah, I'd want to copy the pages to my userspace before a deletion. I don't know how much would be useful, but there's at least a few bits. --MentalMouse42 (talk) 01:59, 8 January 2015 (UTC)
One thing that may be worth mentioning for many mods is the official feed the beast wiki, which has recently moved to gamepedia. (link). It seems to cover all the mods we cover best, although it does need expansion.
As for hostility, the disclaimers are really not necessary on every page, a general mod disclaimer could do a lot better, but the ban on mods in the main pages makes all to much sense. –KnightMiner · talk 03:40, 8 January 2015 (UTC)
Having looked around, Wikia's Thaumcraft4 wiki and FTB are both semi-abandoned, and what's there is from a older version. If you do decide to nuke the mods, you can move the Thaumcraft tree to my userspace -- I and whoever else can salvage stuff to one of them as time and energy allows. (I'll start copying some pages, but I can't seem to find a "copy" option on the menu, so I'll be C&Ping and will lose history. --MentalMouse42 (talk) 20:24, 10 January 2015 (UTC)
To maintain compliance with the Creative Commons license that the wiki content is released under, you can't simply copy-paste pages like that; you have to preserve the page history. You should be able to move the pages to your userspace by using the page rename functionality. 「ディノ奴千？！」? · ☎ Dinoguy1000 20:27, 10 January 2015 (UTC)
I wouldn't worry too much about pages being deleted in the near future. If there is a consensus to get rid of mod pages at some point, it would probably start with the old, outdated ones; I'd keep anything that's being actively maintained/worked on, at least until it's documented better elsewhere. -- Orthotopetalk 20:59, 10 January 2015 (UTC)
I think moving mods the Official FTB Wiki would be great, I'd support it for sure. I use that wiki as an official wiki for all my mods. Xbony2 (talk) 22:59, 17 January 2015 (UTC)
Some mods are being moved over, such as ones done by TheWombatGuru. –KnightMiner · talk 23:41, 17 January 2015 (UTC)
I would agree that moving any mods that are in the FTB pack to the FTB wiki would make sense, they're going to document them anyway, no point in duplicating the effort. However, I don't think we can or at least should be copy-pasting the content and loosing its history, assuming there is actual history. If there's just a few edits by one person who agrees to copy-pasting it, or does it themselves, then it should be fine, otherwise the mod pages should be exported with full history from here then imported on the FTB wiki. –Majr ᐸ Talk Contribs 00:22, 18 January 2015 (UTC)
I agree with Majr, although we document more then the mods just in the FTB modpacks. Btw, Mr. Guru has already moved a couple pages over :) Xbony2 (talk) 22:43, 18 January 2015 (UTC)
In my opinion all mods that are in FTB should only be documented there, apart from one main page as an intro to the mod on the Minecraft wiki. If we choose to do it like this, we could have this one intro article about a mod in the main space as there won't be that many, and it's very unlikely there will be mods that are called "stone" for example, which would mean it has to be placed at "stone (mod)".— TheWombatGurut | c NL Admin 20:27, 19 January 2015 (UTC)
Stone mod. Heh, I looked it up. I found a New Stone Mod if that counts :P Xbony2 (talk) 22:13, 19 January 2015 (UTC)
Hey guys, FTB Wiki administrator here. I'm just coming to say that we allow and love for documentation of all Minecraft mods. Whether they are in an FTB pack does not matter, unless you are a staff member, which would restrict you from documenting non-FTB pack mods. If you guys want to legally (that is, doing necessary things that your and our license require) transfer content over and convert it to our syntax and templates, that would be lovely. And just to avoid confusion, we are talking about the FTB Gamepedia Wiki, not ftbwiki.org. TheSatanicSanta (talk) 22:22, 19 January 2015 (UTC)
I'll be happy to help moving/converting templates over if anyone needs any help. Just to note though, the FTB Wiki doesn't like videos; stuff like spotlights need to be moved out when converted over. Xbony2 (talk) 22:36, 19 January 2015 (UTC)
The problem with still maintaining an info page on mods that now have been migrated is that the people who look after the mod pages will now be on another wiki. We also have to separately create notability guidelines for mods, as most policies on one wiki will not apply to the other.
As for the mods page, the tables of available mods should be removed if we remove the pages, as there are better lists on the forums, curse.com, or FTB:. The page will then discuss what mods are, and link to FTB:. –KnightMiner · talk 23:04, 19 January 2015 (UTC)
Linking them to another wiki isn't a problem as far as I'm concerned. Just link them to a special page that tells them they are being redirected or that tells them to click somewhere to redirect. Just like FTB does. — TheWombatGurut | c NL Admin 14:27, 20 January 2015 (UTC)
Kind of, like Stone on FTB. it would be nice to make this possible: FTB:Stone. (Which I now see is already possible) — TheWombatGurut | c NL Admin 15:41, 20 January 2015 (UTC)
And just for the record, us at the FTB Wiki our much easier to contact on EsperNet at #FTB-Wiki :) TheSatanicSanta (talk) 03:11, 21 January 2015 (UTC)
Aside from that being a rather hostile attitude toward everyone who's contributed to the FTB wiki, the Russian wiki can keep mod pages if they want to. -- Orthotopetalk 18:51, 24 January 2015 (UTC)
I am sorry if I was interpreted as excessively hostile. What I want to say is that I object against the Russian translation on FTB being considered official, and I object against removal of modification pages from the Russian wiki. I do not mind if the FTB translation exists.
Sorry again for being unable to post properly and without any hostility. I currently am in an unfriendly environment IRL, and that affects online behavior.
If you want to talk about demoting or blocking me, please do that on my talk page. --GreenStone (talk) 23:43, 24 January 2015 (UTC)
As an admin on the FTB wiki, I personally don't mind if the Russian wiki wants to retain its pages on mods. You're free to call yourself the official wiki for all things Minecraft in Russian. However we will continue to allow people to translate our pages into Russian if they want to. Considering we have custom extensions and templates made specifically to handle the massive amounts of items and their complex recipes in modded Minecraft, I'm saddened that you don't want to take advantage of what we have, although I understand that you want to retain the linguistic freedom to write articles your own way specifically catered towards Russians. To the English Minepedia: We welcome all mods, regardless of their affiliation to FTB. Feel free to export any mod pages we don't have yet and import them over at our wiki. Just try to fix the pages so they match our style guidelines and use our system of templates. Retep998 (talk) 07:04, 25 January 2015 (UTC)
2 questions
What does right translate do and what extension added it?
"Real name" field in preferences saids that it will be used for "giving me attribution for my work". What does it mean? Does it mean that it will be used to show entered name in differnces pages etc.? If yes, it does not work. dand0 (talk) 07:51, 20 November 2014 (UTC)
The group rights are from Extension:Translate, though it's not currently installed here.
There's a MediaWiki option to show the most recent editors of a page in the footer; I believe the real name option is used there. It's disabled by default, though, as it's somewhat resource-intensive. -- Orthotopetalk 15:27, 20 November 2014 (UTC)
Suggestion: tab infobox images
Currently, having two images of monsters, like uncharged/charged creeper, normal/baby zombie etc. and gifs of different types of blocks, like stairs, stained clay etc. takes quite a lot of space and waiting for a specific frame of a gif is a nuisance too. How about making tabs, like this: [2] or this: [3]? Please consider this, it would improve aesthetics of pages. Xeoxer (talk) 15:30, 22 November 2014 (UTC)
That would make some infoboxes very long. –LauraFi·talk 15:50, 22 November 2014 (UTC)
The thing is, with most blocks there will be no more than 4 frames of unique designs, so it is not a long wait (especially with only 2 seconds between frames). The ones with more frames tend to be simply color swaps, such as wool or types of wood, so each specific image does not change much. We also frequency use the animated images elsewhere, causing an inconsistency when we do not have that many images to begin with. Both of those had at least 10 to 20 images that all had between minor and major differences, causing some necessary time to figure out what is different. –KnightMiner · talk 15:50, 22 November 2014 (UTC)
I've been thinking about asking for tab boxes too, as a way to flip between redstone circuit screenshots and schematics compactly. I don't think I would use them for infoboxes though. —munin · · 16:29, 22 November 2014 (UTC)
Entity data
Can we add NBT data trees to pages about entities? Since we have them for block entities, why not have them for actual entities too? --Naista2002 (talk|contribs) 14:01, 25 November 2014 (UTC)
From what I heard, allowing the values to sync is in progress, see Talk:Chunk format#Splitting the page into templates. munin295 and LB1 are working on it, though not much progress recently has been made. If you want you could start adding trees without the sync, you could, otherwise you could wait for or help out the project there. –KnightMiner · talk 16:31, 25 November 2014 (UTC)
(edit conflict) The main issues I see are article length (the tree to fully describe a mob is about five screens long on my monitor; less on large displays, but way too long on mobile) and maintainability. If a tag in the generic Entity class changes, some 70 pages in Category:Entity would need to be updated. There's a proposal at Talk:Chunk format#Splitting the page into templates that would solve both problems, but I don't know if it's ready to implement yet. -- Orthotopetalk 16:33, 25 November 2014 (UTC)
I think we've stalled on working on it, if someone else wants to take up the torch… But if LoadBox is used for common field groups, then changes shouldn't propagate, right?
I think there were some problems trying to make LoadBox play nice with the treelist view. Until that's resolved, maybe the articles could just list their specific fields with links to the common fields. —munin · · 17:57, 25 November 2014 (UTC)
I agree with Munin. Until LoadBox is fixed, we can use links. --Naista2002 (talk|contribs) 07:51, 26 November 2014 (UTC)
1.6.1, 1.7.2 and 1.8 snapshot downloads
I just found where the 1.6.1, 1.7.2 and 1.8 snapshots are stored. They are stored in s3.amazonaws.com/Minecraft.Download/versions/[version here]/[version here].jar/json. Shall we provide links to the jar and json downloads in the 1.6.1, 1.7.2 and 1.8 snapshot pages or just leave as it is? --ToonLucas22 (talk) 23:57, 5 December 2014 (UTC)
I don't see any need to, since you can get all of them more easily through the launcher. -- Orthotopetalk 01:15, 6 December 2014 (UTC)
But 1.6.1 and 1.7.2 snapshots aren't available trough the launcher, and only some 1.8 snapshots are available trough the launcher, so I think we should put the links. --ToonLucas22 (talk) 01:21, 6 December 2014 (UTC)
Hmm, looks like they've been removing older dev versions from the launcher. If they're no longer available there, adding links makes more sense. -- Orthotopetalk 01:35, 6 December 2014 (UTC)
So are the 1.6.1, 1.7.2 and 1.8 development version downloads being linked? --ToonLucas22 (talk) 01:54, 6 December 2014 (UTC)
No response recieved since my last response, so i'm taking that as a yes. --ToonLucas22 (talk) 01:27, 7 December 2014 (UTC)
I would agree to linking them, as only the latest few tend to be in the launcher. {{Version nav}} already supports adding them, via its parameter {{{clientdl}}}. –KnightMiner · talk 01:45, 7 December 2014 (UTC)
Well, maybe a {{{jsondl}}} parameter should be added, as the json files are also stored there. --ToonLucas22 (talk) 01:54, 7 December 2014 (UTC)
Nevermind, I'm just going to put the .json links in brackets in the {{{clientdl}}} parameter. --ToonLucas22 (talk) 17:40, 7 December 2014 (UTC)
Looks good. –KnightMiner · talk 23:07, 7 December 2014 (UTC)
Curse host broken
The Curse host is broken. I wanted to edit my userpage but I couldn't because the host always threw me an error. The edit only succedeed 2 times, but both times the edit refused to get saved. My internet connection is perfect, so that can't be it. --ToonLucas22 (talk) 22:05, 13 December 2014 (UTC)
Apparently, the error is also there when attempting to get to the Recent Change page or to backtrack. --ToonLucas22 (talk) 22:08, 13 December 2014 (UTC)
Protected edit request template
I would like to propose a template, along with a few categories, to aid users in requesting edits to protect pages, as well as aid people with proper rights in finding those requests. I personally have made requests on a few pages that were never found, so it would be nice to have an easier way to bring them up without spamming the Admin noticeboard or this page.
I am mainly wondering if people would use the template, and if users/admins would check the semi/fully protected request categories to actually answer the requests.
Also, what would be a good way to tell users about the templates? I know a link in the admin noticeboard may help for the sake of fully protected pages (similar to the {{delete}} link).
–KnightMiner · talk 21:02, 17 December 2014 (UTC), edited at 23:13, 17 December 2014 (UTC)
I don't think this wiki is anywhere near big enough to require such a template. The admin noticeboard isn't being spammed at all, there's not even a post per day. –Majr ᐸ Talk Contribs 10:00, 23 December 2014 (UTC)
In that case, I'd assume you would advise posting unanswered requests on the admin noticeboard? –KnightMiner · talk 14:42, 23 December 2014 (UTC)
If it requires admin attention, it goes on the admin noticeboard. That's what it's there for. –Majr ᐸ Talk Contribs 09:43, 24 December 2014 (UTC)
Well, by UTC time. Still have a few hours to go where I live.
Happy New Years! –KnightMiner · talk 00:08, 1 January 2015 (UTC)
Same with me, my GMT is +04:00, meaning I have to wait 2,50 hours more. Well, anyways, happy new year! :D --ToonLucas22 (talk) 00:33, 1 January 2015 (UTC)
I have to wait 35 minutes :) –LauraFi-talk 02:25, 1 January 2015 (UTC)
Oh shoot, just 9 minutes left and the host goes down. For some reason everytime I try to view a page the host goes down. --ToonLucas22 (talk) 02:41, 1 January 2015 (UTC)
Happy New Year :) I celebrated it on 21:00 of UTC, since I use UTC+3. Also, at the actual begin of the new year in my region (Vladimir oblast, Russia), I wrote a celebrate message on Russian wiki. There, I was some 27 minutes late because I didn't started to write the message before the actual new year. When it became 00:00 as of UTC, I was already sleeping. --Naista2002, now NickTheRed37 (talk) 09:40, 1 January 2015 (UTC)
Translation issues...
Hello!
I'm new to this community.
I'm italian, but I can speak/understand english pretty well.
Yesterday, I was searching some information on this Wiki in my language, italian, and I realized that the translation isn't good at all.
Luckly, I can understand english, so I started to search information in english.
But there's a problem not all people can understand english in my country.
Can I translate some articles or pages to italian???
This can help the community a lot, in my opinion.
Sorry if I made some mistake, but like I said I'm italian. –Preceding unsigned comment was added by Incredituber3011 (talk • contribs) at 10:41, 03 January 2015 (UTC). Please sign your posts with ~~~~
This is the English wiki, the Italian wiki is here. The whole point of a wiki is anyone can edit it, you don't need to ask to get started. --–Majr ᐸ Talk Contribs 10:46, 3 January 2015 (UTC)
British English translation
A UK english version of the wiki would be fairly better for UK users, if unnecessary. Just a suggestion. - MinecraftPhotos4U (talk) 18:16, 7 January 2015 (UTC)
The main problem would be getting support. If you can already under stand the American English wiki, why use the British English one which lacks content?
Also, the wikis would be mostly identical, except minor spelling and slightly different vocabulary. The languages are too similar to require a separate wiki. –KnightMiner · talk 18:48, 7 January 2015 (UTC)
That was the main problem I was actually thinking about, and I still haven't thought of a workaround - MinecraftPhotos4U (talk) 20:51, 7 January 2015 (UTC)
As a point of comparison, consider the fact that there is only one English version of Wikipedia (plus Simple Wikipedia, but that's not really a language variant). This suggestion has been made for Wikipedia in the past, and was rejected for largely the same reasons. One potential solution would be some sort of variant selector, like is used on the Chinese Wikipedia, but I suspect developing that would be a very involved affair, and even after extensive development would have a lot of problems. 「ディノ奴千？！」? · ☎ Dinoguy1000 22:22, 7 January 2015 (UTC)
Usage of categories
I've noticed many of the main Minecraft Wiki categories are also containing both user pages and translation projects, and as neither of those are helpful when using the category, that proposes a problem. The thing is, though, there is no stated rule or policy in place that translation pages and user pages cannot use those categories (instead, users who have been on the wiki longer remove them, and new users may simply copy/paste them onto their page)). What I'm proposing is creating such a stated policy on this wiki, something along the lines of "Categories not designed for project pages or user pages should not contain project pages or user pages."
I'd agree with that. Feel free to remove those misplaced categories from people's userpages. "Don't touch my stuff" rules don't apply when that stuff is disrupting the usage of the wiki. –Majr ᐸ Talk Contribs 10:34, 11 January 2015 (UTC)
Userpages are useless in content categories, remove them on sight. 「ディノ奴千？！」? · ☎ Dinoguy1000 11:31, 11 January 2015 (UTC)
And I assume translation project pages should use the /lang version of categories instead of the main ones? –KnightMiner · talk 20:13, 11 January 2015 (UTC)
If you were asking me specifically, I don't really have an opinion; if it's SOP to create language-specific categories then keep doing that and switch articles to them as needed. 「ディノ奴千？！」? · ☎ Dinoguy1000 23:10, 11 January 2015 (UTC)
It was a general question to both of you, stating it twice would end up a bit redundant (though I could have used {{@}}...).
For the most part it has been practice, but never stated, and I wanted to at least have a bit of stated backing before I changed dozens of pages, rather than going based on unstated practice. It also helps the usability of the categories. –KnightMiner · talk 16:52, 12 January 2015 (UTC)
Infobox usage with version exclusive templates
We really need to adjust the infoboxes to include some sort of parameter to state edition, as this really looks bad. It would be nice to only use those templates when there is no infobox, as there is no nice looking way to implement them together, especially if the article's content exists in multiple non-pc editions.
Also, it is currently impossible to find out something does not exist in an edition without scrolling all the way to the history section. If there was an infobox row stating as such, a user can then instantly find out something like "Iron golems are not in PE".
The main problem would be adding this parameter so it is not intrusive, yet gets the point across, and preventing it from excessively expanding the infobox. Maybe within the blue infobox title using {{OS}} and titles?
Done. I also have made a separate template for editions. It allows you to show or hide the textual link to the edition too. –Nick the Red37 — ru.wiki moderator (talk) 17:39, 12 January 2015 (UTC)
The icons look decent, still needs a bit of work on the sizing. I personally prefer it without the text, as not only is it more similar to the current column "required tool(s)", but it will be a consistent size whether there is one or all four versions. –KnightMiner · talk 02:28, 13 January 2015 (UTC)
As an alternative here, Wikipedia has had a top icon system for years that is used for denoting e.g. featured articles and page protection levels; as long as the version icons are still easily identifiable after being scaled down to an appropriate size (or can be replaced by appropriate such icons), implementing that system would allow us to keep the current template transclusions untouched (other than adding icons to denote the versions a given object appears in where they are absent) while solving the presentation issue. 「ディノ奴千？！」? · ☎ Dinoguy1000 23:35, 12 January 2015 (UTC)
I've always liked the look of those icons. I'm taking it they are controlled directly using absolute positioning? I'd love to see what it would look like here. –KnightMiner · talk 02:09, 13 January 2015 (UTC)
I've made an early version of the top icons in my sandbox, it was based off the wikipedia version, although I could drop half the code using variables and one quarter since we only use one skin for styling. –KnightMiner · talk 03:20, 13 January 2015 (UTC)
There may or may not be CSS in Wikipedia's Common.css file specific to top icons, and there is (or was) work being done to add similar functionality to core or in an extension, but (as you noticed) Wikipedia's current implementation is entirely contained in the ((top icon)) template. There's zero reason for us to not use variables (or a Lua module if Majr or someone else feels like coding one up, and if it would be less overhead than a template) or trim the code to account for our single skin, though. 「ディノ奴千？！」? · ☎ Dinoguy1000 05:10, 13 January 2015 (UTC)
Top icons don't work on mobile, while there are many players playing Pocket Edition. Nick the Red37 — ru.wiki moderator (talk) 06:44, 13 January 2015 (UTC)
Something in the mobile CSS is setting .content .topicon {display:none !important}, which might be the issue, but I can't figure out why without access to LocalSettings.php; it's not in MediaWiki:Mobile.css. Upgrading to MediaWiki 1.25 would add page status indicators, which might work on mobile, but who knows when that will happen.
Technical issues aside, I have a couple of concerns with using top icons. One, the icons are relatively small and easy to miss, so we'll still need to mention version exclusivity elsewhere in articles. Two, sometimes version exclusivity only applies to part of an article (such as Technical blocks or Bowl#Usage), so a single set of icons for the whole page doesn't make sense. -- Orthotopetalk 09:47, 13 January 2015 (UTC)
I have fixed the mobile error as a temporary preview, by adjusting the top positioning and forcing a display (to override display none). Can someone with a mobile check that on my sandbox? You have to have the top icon section open for it to appear. If used in the future, they would all be in the main section, and the positing would be controlled through the main css files.
@Dinoguy1000: There was some code, only it was in each different skin file, so I took the code from the skin most similar to ours (vector.css) and modified it from there.
@Orthotope: They are a little small, especially unnoticed on larger screens. No matter what we should keep the individual version notes within articles, as there are always going to be differences between versions.
As for applying to only part of the article, there really is no fix for that other than an infobox parameter, but since the main article that is affected by that is Technical blocks, and that already uses its own block template, that would be an easy fix. The rest multiblock should already note which are in each version.
The top icon does appear on mobile (but in the same place as the page title’s text), but it becomes hidden when the ad box is shown. Tested with mobile version of Google Chrome 28.0.1500.94 on Sony Xperia E1 with Android 4.3. –Nick the Red37 — ru.wiki moderator (talk) 15:52, 13 January 2015 (UTC)
I'm not sure about the ad part, but the icon should no longer appear within the title (I moved it to the line with the edit and watch icons) –KnightMiner · talk 16:16, 13 January 2015 (UTC)
Months before this discussion started, Ivan-r of Russian Minecraft Wiki made a template that fulfills the same goal: ru:Шаблон:Версии. Example of usage. Aside from icon size, there are problems with clearance, but I think that it can be used as a convenient alternative to top icons (can be used multiple times) and infobox icons (can be used outside of infoboxes). I may create a fork of it in my Gamma sandbox and do necessary fixes. I’m NicktheRed37, f.k.a. Naista2002 17:15, 30 January 2015 (UTC)
I’ve made a test fork of it here. Sorry for Russian text, but, for reference, parameters for it are пк (pc, computer edition), карман (pocket, Pocket Edition), консоль (console, Console Editions) and пи (pi, Pi Edition). I’m NicktheRed37, f.k.a. Naista2002 17:38, 30 January 2015 (UTC)
It looks decent. I'm unsure if it has it already, but some tooltip text would be nice to describe the icon. The main question would be whether to use it per section or per page.
It may also work to have two versions of the template to fix the spacing issues, that is one called by the infobox (like this maybe?, and one used when there is no infobox, which would appear similar to the one shown before. –KnightMiner · talk 20:29, 30 January 2015 (UTC)
I've adjusted that template to use a div box, so it works fine on mobile and in the infobox title. I shall later add a switch to don't show the box around it. I’m NicktheRed37, f.k.a. Naista2002 09:36, 31 January 2015 (UTC)
Talk page guidelines
I've noticed many new users post messages on talk pages that get reverted by a more seasoned user due to violating general talk page usage. The problem is the new user has no way of knowing they were not suppose to do that, as it is never stated outside of edit summaries.
Currently the only two rules stated are only discuss the page and its content, and sign your posts. The best way to state the other guidelines are a page which will not only state the aforementioned two rules, but will also mentioned the following:
Don't Generally avoid replying to a comment more than a year old, as the user is very unlikely to see it and your response most like was not relevant back then.
Keep replies to the same topic as the original topic of that section.
Don't edit other user's comments, except to sign unsigned comments or fix minor formatting errors (basically cover someone forgetting to use {{tl}} when discussing a template, forgetting to indent, and forgetting to escape a category/file link).
Don't edit archives (it may seem obvious, but some people still edit them)
Formatting guidelines, including proper usage of indentation for standard topics and consensus topics, and the proper way to link to a template, file, category, ect.
Rule #5 (it relates to talk pages, it would be a good idea to have mention of it so it is all in the same spot)
Rule #22, possibly with some extended guidelines on signatures (such as excessively larges files and text, this rule could theoretically be migrated to the page)
That one thing I'm forgetting, and someone will remind me of in a reply (just so I covered everything)
I don't like the first rule (can we number these for discussion purposes?). One year seems arbitrary, and I'd be happy to answer someone who responded to a years-old post. I'd just make that a recommendation or something to consider -- not something you would, say, undo for "breaking the rule".
For formatting, I wouldn't specify a specific number of indents before using outdent -- just use it when it feels right. Also, because of the way the wiki formats lists, I like to include a paragraph space between each user's comments -- that also makes it easier to follow the thread in the edit window which doesn't have indenting.
NickTheRed37's rule is fine for article talk pages, but it shouldn't apply to user talk pages -- there the user has total control of what is allowed on their talk pages, as long as it doesn't break the general rules.
It would make sense to change that to recommended, although in most case of replying to an old comment it is a anon telling someone from 2011 to use a hopper to collect items (well, along those lines). I would agree to it being strongly advised rather than revert worthy though.
The number was mainly just copied from the template, I changed it to simply use eight as a standard. And I like the idea of adding a line break between comments by separate users (I already do that normally)
That makes sense, considering the wiki rules. The page now states the only user talk page requirements from that list that is not from MCW:Wiki rules is not editing other people's comments.
I've made one last tweak, as it is mostly generally agreed upon. The signature guidelines now states that the username should either link to your user page (eg, Knight), or display your username (eg, KnightMiner), for the sake of identification. It also forbids impersonating another user by displaying their name and linking to their page (if my signature claimed I as one of the admins for example).
I am a little unsure of how far to extend the last part, as in what would qualify impersonation. It might happen that someone wishes to link another user's page for some reason, and display names are allowed, but both should not be combined. –KnightMiner · talk 16:12, 17 February 2015 (UTC)
What you have sounds reasonable to me. Basically, signatures need to identify the user who made a comment. The MediaWiki default both displays the username and links to their userspace, which is great. Some users may want to display a different name (such as munin, above); as long as there's still a link to their userspace, this is fine when the display name is a variation on their actual username, but something like [[User:Munin295|Bob]] starts getting confusing. Not including a link is questionable at best – Wikipedia actively prohibits it – and I don't see any reason why one person's signature should link to another person's userspace. -- Orthotopetalk 23:46, 17 February 2015 (UTC)
I don't have anything against it being more strict. Most users already follow those guidelines, and those who don't it is usually by accident.
More specifically, I agree signatures should contain a link to a users page or talk page, to help with identification. In this case, it might make sense to go even farther to require a link to their main/talk/contribution page, otherwise the guideline should at least advise it. I would also agree to limit display names to being directly similar to the original name.
With linking another user's page, the only reason I can think of are to clearly show alternate accounts, so I would agree to advise against linking another user's page, if not forbidding it.
It does raise the question of other links though, wikipedia directly forbids external links, category links, and files in signatures, and advises against links not directly related to general information. I think we should take a similar stance taking a similar stance towards external, category, and internal links, though I am unsure about files (the reasons against using them make sense, though files are used to show curse or mojang staff in a few cases). –KnightMiner · talk 05:11, 18 February 2015 (UTC)
Rather than forbid replying to old topics, we should instead try to archive them better.
I think it should be a rule that signatures must contain a link to one of your user pages (not sure if it is necessary to limit that to the more main ones, like main/main talk/contribs/logs), and the name should be similar to your username. It's really inconvenient when someone doesn't have a link to one of their user pages. I think wikipedia's rules are sensible, however as we don't have the talk page density that they have, I think it is fine to allow files, but limit them to one, maybe two at the most as well as sensible size restrictions. Speaking of which, an additional guideline should be that your signature shouldn't increase the line height, doing so causes the rest of the text surrounding the line with the signature to have excess spacing that makes it less readable. It's not like there isn't plenty of room to use anyway. Even though my signature spans two lines, the text is smaller and is pulled closer together, so it still stays within the standard line height. –Majr ᐸ Talk Contribs 05:53, 18 February 2015 (UTC)
We do need a better archiving system, that could be a later project though (would be nice to have one of those archiving bots like Wikipedia has, but a wiki project would make sense for now) We should at least archive entries that are over a year old. (On the proposal page, I did change it to advise against replying to old comments, rather than directly forbid.)
With the line height guideline, I do agree the line height change can be annoying and affect reading negatively. We should definitely advise against it, if not disallow it. For the most part, tags such as small, sup, and sub have little to no visual effect on line height (unless you have too big of font size), so the main things that would affect are files (20 pixel height limit sounds good), and Goandgoo's signature. –KnightMiner · talk 15:50, 18 February 2015 (UTC)
So, any more/final comments on the guidelines? Otherwise, would anyone have anything against implementing them? Assuming there is enough of a consensus then, I can implement the guidelines in a week or so. Link to the proposed guidelines.
It may also be relevant to use the MediaWiki:Sitenotice to alert users of the change for at least a week after, as from what I've seen, many of them don't read the community portal discussions. (it was most notable with the upcoming features rewrite) –KnightMiner · talk 15:58, 21 February 2015 (UTC)
Agree.
My rule about usage of user talk pages can be rephrased like so, changing it from a policy to a guideline: “Using user talk pages for things other than discussion or testing talk page features is discouraged.” — Agent Nick the Red37(talk · contribs) f.k.a. Naista2002 16:10, 21 February 2015 (UTC)
Currently rather than advising against non-talk usage, it advises towards good talk page usage (the rule about talk page usage is advised on user talk pages). I flipped it to discourage non-talk usage. In the case of talk page sandboxes, they would fit the category of advised against usage, but the user is free to do it still. –KnightMiner · talk 16:31, 21 February 2015 (UTC)
I have a couple of additional guidelines to consider: pinging and signature interwiki links.
Pinging should generally be used for pulling someone into a subject that warrants their attention, which they may not be watching. This means that it doesn't apply to the user's own talk page, as they should be getting notifications there already. Replying (which is really just pinging with an @ in front of it), should be used when your reply is to multiple people. It isn't necessary when your reply is to the previous post (the one directly above and one indentation level less), unless you feel they may not be watching the subject (a passing comment rather than a full reply, perhaps), and so you also wish to alert them to your reply.
Interwiki links probably shouldn't be used in signatures, at least not as the only link. Suddenly being taken to another wiki (even if just another language version) can be confusing, and a nuisance if you actually wanted to access a user page or user function on the original wiki. On a related (but not to this topic) note, we should probably also advise against redirecting at least the main user/user talk pages to another wiki/language, and instead use a {{soft redirect}} (and actually create that template too). –Majr ᐸ Talk Contribs 00:16, 22 February 2015 (UTC)
The pinging guideline makes sense, it helps to know which user someone is replying to, and it would be a good idea to state when pings are needed and when they are redundant. With the layout of the proposed guideline it would likely fit best in formatting, if not its own section.
As for interwikis, assuming we do not declare them as external links, that could be covered by requiring the link to your user page to be your English wiki user page, as I don't see any other useful English link to require them to have. Someone from another wiki could then link internally to their main page, and interwiki their talk page, or vice versa.
Yeah, that template would be useful, though I think only user pages would use it right now.
Following up the previous topic (#New texture for blue bars and boxes?), where I mentioned a lighter stone color for the blue boxes. I applied a texture like that to Minecraft Wiki/editcopy, and I am wondering what opinions are on the design (as no one replied to any proposal in the previous topic other than the dirt). –KnightMiner · talk 05:43, 24 January 2015 (UTC)
Looks okay, though I'm concerned there's not enough contrast between the black text and gray stone texture. -- Orthotopetalk 06:55, 24 January 2015 (UTC)
I brightened it somewhat to increase the contrast. I think the contrast is alot better, the only place I'm at all concerned is completely standard text (which is only used on MCW:Community portal) –KnightMiner · talk 23:51, 24 January 2015 (UTC)
Much better, though I'd like to get Majr's opinion before rolling it out to the main page. -- Orthotopetalk 00:52, 25 January 2015 (UTC)
I still don't like the new boxes as the black text and the grey backbround blend in far too much. I think using stone is probably not great as the box background. –Goandgoo ᐸ Talk Contribs Edits 02:22, 25 January 2015 (UTC)
One option would be recoloring the stone to make it blend slightly less; either lightening it more or giving it a tint, provided it does not take away from the Minecraft feel.
If using a different block, we would need to make sure it is iconic enough to denote usage on most pages, while being simple enough that words can be read on it. That basically leaves block such as stone, cobblestone, dirt, grass, wooden planks, obsidian, maybe clay or sand, wool, possibly stone bricks, water, and lava. From that list, stone does fit the criteria the best, as the rest are either not as iconic or too dark/noisy.
Otherwise we could keep the current, but that really both does not say "Minecraft" like the rest of the skin, and has been in place for awhile (over three years it seems). –KnightMiner · talk 14:55, 26 January 2015 (UTC)
White text on dirt might be reasonably readable. -- Orthotopetalk 15:31, 26 January 2015 (UTC)
I personally don't like that bright stone texture, I still prefer the dirt one although I have to say that the texture really was way too dark, so I made an experiment on my test page (compare: former (darker) version). I also blurred the background file so you can read the white text better. | violine1101(Talk) 18:38, 1 March 2015 (UTC)
I personally still think it is a little dark, as it requires a font color of white. I am not fully sure what can be done about that though. –KnightMiner · (t) 16:59, 2 March 2015 (UTC)
I had previously ruled it out, due to me thinking it would not look good, but it actually is not that bad, especially the third one (birch, right?). It also solves the issue I was having with the stone being to monochromatic. One minor concern is it does not blend as well with the light blue background, though the yellow message boxes have been doing the same thing for years.
It also sort of makes sense if you conciser the background as natural Minecraft terrain, and the blue headers as player made buildings, though I might be stretching it a bit. –KnightMiner · (t) 19:05, 2 March 2015 (UTC)
In my opinion, the planks texture causes that the text ("About Minecraft", "Play it!", etc.) is more difficult to read, but I think that the birch planks texture would be a good choice if we take a planks texture. Anyway, the dirt texture can always be lightened - also it should be mentioned that the dirt texture is also used in Minecraft itself in the menu. As I earlier said, the texture of buttons would also be an option, but is technically difficult (and would also cause some problems on the German wiki's main page). | violine1101(Talk) 19:43, 2 March 2015 (UTC) Edited 19:45, 2 March 2015 (UTC)
Markus Persson/editcopy?
Everyone probably knows this message box by now:
Note: This page is for users to propose changes for the "insert page here". "Insert page here" is a potential target for mass vandalism, but we want every user to be able to contribute to every page.
Surprisingly, why is there no editcopy version of Markus Persson? BDJP007301 01:57, 29 January 2015 (UTC)
Is there a need for one? Since he's no longer at Mojang, and didn't actively work on Minecraft for several years before it was sold to Microsoft, I don't imagine there will be many changes that need to be made on that page. -- Orthotopetalk 04:06, 29 January 2015 (UTC)
Well, seeing as this template says that every user can contribute to every page, not allowing an editcopy version of that page would just be egregarious lying. BDJP007301 00:23, 12 February 2015 (UTC)
Not if we allow changes to be proposed on the talk page, which allows any user to contribute. I've done that before on that page. –KnightMiner · talk 00:33, 12 February 2015 (UTC)
Maybe we should try using mw:Extension:Approved Revs? It's like FlaggedRevs, but not ridiculously overcomplicated and (hopefully) buggy. It could be used instead of page protection, which would then be used for handling spam. –Majr ᐸ Talk Contribs 02:24, 3 March 2015 (UTC)
Can be insta-mined
I think we should add this into pages in some sort of way (the lowest tool that can instamine a siad block), and add enchantments if necessary. Like put on a page you need efficienccy V and haste II on a daimond pickaxe to insta stone, while a efficiency stone axe will melt mushrooms. - MinecraftPhotos4U (talk) 19:14, 30 January 2015 (UTC)
Even if I see it as useful, I don’t feel like it should be added. I’m NicktheRed37, f.k.a. Naista2002 19:21, 30 January 2015 (UTC)
Comment The problem with insta-mining is it is rather relative, and actually is not instant, just very fast. The only blocks that can really be insta mined would be slime blocks and tnt
This might make a relevant tutorial though, possibly under mining tips. –KnightMiner · talk 20:13, 30 January 2015 (UTC)
It's slightly interesting for harder blocks, but I don't think it's generally useful. Part of the problem is that there are too many ways to do it. For example, saying that "huge mushrooms can be insta-mined by a gold, diamond, or iron axe, or an Efficiency I stone axe, or an unenchanted stone axe with Haste I, or an Efficiency III wooden axe, or an unenchanted wooden axe with Haste III, or an Efficiency II wooden axe with Haste I, or an Efficiency I wooden axe with Haste II" doesn't really help anyone. If there was exactly one way to insta-mine a block in Survival mode, that might be more noteworthy. -- Orthotopetalk 21:04, 30 January 2015 (UTC)
Reform the style guide and wiki rules
I've noticed the style guide currently lacks the ability to expand, as it only lists sections for general feature articles. On a similar note, guidelines on article create are split in multiple places, and are even hard to find within their places, such as the rules has notability as random numbers.
A possible solution would be this proposed rewrite from by sandbox, containing the following pages:
Mostly contains the current style guide, minus the layout sections. This change was implemented on 15:54, 20 February 2015 (UTC)
The section "Section headings" links to the general sections. The section "Article layout" was kept to link to the subpages.
The section "Notability" comes mostly from the wiki rules, except General 4 and 5, which are from the style guide's future section/#Unimplemented, mentioned, and upcoming features This change was implemented on 17:48, 23 February 2015 (UTC)
Notability's wiki rules are duplicated from the remaining rules. They are mainly there so all the information is in one place.
One of the current wiki rules was moved to the section "Images" (previously "Image captions") This change was implemented on 17:48, 23 February 2015 (UTC)
"Article titles" general title format is entirely based on general practice.
A style guide proposed on the style guide talk page previously. Everyone in the topic liked it, but there were only two of us there (including me).
Wiki rules Implemented at 00:49, 2 March 2015 (UTC)
Will contain stuff that is block worthy, rather than just any random policy we want to list (except maybe what would be rule #7).
Removed all the rules that are now within the style guide.
The note about the userspace was moved as well, as now all the rules are required in the user space (except where noted)
Also removed the talk page guidelines, since if we are going to be changing all the numbers, might as well only do it once. (see #Talk page guidelines)
The major advantages of this proposal are that the style guide will be more organized, as well as the wiki rules being all major violations, rather than half being minor. The style guide is also easier to expand for other article types, such as mods, template documentation, and tutorials.
The major disadvantage other than some rearrangement of information (making it confusing for a bit remembering where things are now) is that most of the wiki rule's numbers change, causing previous edit summaries to be broken. Things such as some deletion summaries also would need to be updated to support the notability guidelines rather than rules.
Another thing this would have the ability to solve is the controversy over various parts of version pages, specifically bug tracker titles. With the current style guide, there is no place to put such a guideline relating to anything that is not general article style or specific to feature articles. –KnightMiner · talk 01:08, 17 February 2015 (UTC)
When I feel like there's a sudden change in my real-life schedule, I feel like I need to release all my anger. That same thing went for when Majr edited a tracker title on 1.4.6. NickTheRed decided today to rewrite almost all of the tracker titles on that page after wondering if I read Majr's notice regarding tracker titles. I told myself to stay calm, but my mind kept on telling me to revert every single little change. I eventually decided to give in.
Story aside, I'll now ageee to this change, but on the condition that all nouns (Piston, Baby, Cow, etc.) are capitalized. BDJP007301 02:29, 17 February 2015 (UTC)
On the subject of bug report titles, I don't think it's necessary to rewrite them for the most part. Occasionally there's one that's so badly written it's hard to understand, which should be improved, but I don't see a need to go through all 200+ pages that use {{bug}} just to change capitalization and minor grammar issues. I can understand not liking sudden changes to the way we do things; that's why this is a proposal for discussion, rather than one user deciding to change things without consulting anyone else. -- Orthotopetalk 03:10, 17 February 2015 (UTC)
Other than a preference towards title readability (correcting typos and impossible to understand titles, code tags/{{cmd}} where relevant, ect), I don't have anything against changing the style or the current style, but I am against using inconsistent styles or switching back and forth between the two.
The main thing I was proposing here was a place for the guideline, and turning current standard practice into guidelines to avoid unneeded repeated discussions, which I brought up here as I felt it was directly related. That, and I've had quite a few proposals go unanswered, without anyone agreeing or disagreeing.
Sorry if I offended you with my actions. I often tend to be eager (if not overly eager) to use a new solution or method. –KnightMiner · talk 03:31, 17 February 2015 (UTC)
It's fine for you to disagree with a change and discuss it, however using your condition as a sole reason for not liking a change is not an acceptable argument. There's no reason that tracker titles should be left at a poor standard compared to the rest of the wiki, especially since the lists are not automatically populated, and thus have to use the original titles.
It's not necessary to go through every page and fix every title to have perfect grammar and formatting, but they should at least be readable and have useful formatting like links.
As for the capitalisation: I don't see why tracker titles should treat those words as proper nouns when the rest of the wiki doesn't. If you don't agree with that capitalisation, that is something to take up with the general style guide. –Majr ᐸ Talk Contribs 05:02, 18 February 2015 (UTC)
I think it makes a lot of sense and will be less confusing to have individual guidelines for different types of pages split out from the general guide. I would recommend starting out by just moving the general article structure (what should we actually call these types of pages?) to its own style guide page and any other rules specific to other types of pages to their own pages. Afterwards any changes to the style guides can be proposed as normal. This gets things organised now, rather than having that held up waiting for people to agree on changes to the actual guidelines themselves.
The rule changes as well I agree with, but I'm not sure what the best way to handle the changes should be. Here's the options I can think of:
Rules that no longer apply get moved to another section on the page, but keep their number. Any new rules always get a new number that hasn't previously been used. This retains links, but will continually increase the page size and rule numbers (as well as having gaps in the numbering), and clutter the page with old rules that don't matter any more.
"Version" the rules page. So the old rules page would be left as it is aside from a notice stating they no longer apply, and then a new page would be created somewhere (Wiki rules/v2? Wiki rules/Revision 2? Wiki rules/2015?). This also retains links, and keeps the "current" version clean with just the relevant information. However, maybe the page naming isn't so appealing, and anyone that ends up on the main wiki rules page will be looking at an old version. We could fix that by moving the existing rules page as version 1, but this then breaks links, and if we have the original page name redirect to the current version, this encourages people to create links that could break in the future.
Archive the old rules, as we do with talk pages, then leave links to previous versions of the rules. This keeps the main rules page current and clean, but breaks existing links, requiring the original rule to be hunted down in the archives. Obviously this is no worse than what we already do with talk pages, but that is a technical limitation from wikis not having an actual discussion system, rather than a good way to handle things.
I'll split out the general sections to their own page shortly if no one disagrees. For the most part the style does not contain other page types yet, so we can continue from there with what other guides to add. The best titles I could come up with were "Features" with an optional prefix of "General", or splitting it further into "Blocks and items", "Entities", and "Structures", though splitting would lead to duplicate sections across article types.
As for proposals of actual guidelines, everything except "Article titles" and the version style guide are already rules in action, so assuming the new format is agreed upon, I can start the reorganizing, which would be moving notability guidelines and the image guideline from the rules and later adding the currently general practice guideline from #Unimplemented, mentioned, and upcoming features.
I think archiving the rules would make the most sense, to preserve the commonly used name. It should be fine, as long a section/archive box is added with rule usage periods (so old talk page posts/edit summaries can use their date to discover the rule). Maybe we could add a notice to the top stating the start period of the current rules as well.
That could work, though it does become slightly confusing for the general section links.
Another option might be transcluding the sections, which would add a bit of confusion only to the editing (though if done right, the section editing links would lead to the proper place).
Otherwise, since most feature articles follow the general format listed, except with variants on the names (obtaining for blocks and items, spawning for mobs, generation/creation for structure...), the titles could be changed to state variants (Obtaining / Spawning / Creation), and add anchors for each variant, though that may become more confusing. –KnightMiner · talk 16:31, 18 February 2015 (UTC)
The article structure section on that style guide is here. There are the general guidelines on article layout, and links to sub-guides for guidelines specific to different articles. I may move the general ones to a separate sub-page. But that is a different style guide for a different wiki and discussing it here is off-topic. — Agent Nick the Red37(talk · contribs) f.k.a. Naista2002 16:47, 18 February 2015 (UTC)
I've implemented the first change (moving the article layout to a sub page). If all goes well, I will start moving a few of the rules over in a day or two. It could be split further if desired, having the specific sections link to subpages "Features/Blocks and items" or "Features/Entities", or some other system that gets chosen.
To explain my editing up top, green is notes edited in later, gray is implemented stuff, and strikeout is canceled. –KnightMiner · talk 15:54, 20 February 2015 (UTC)
Rules relating to notability and images were copied over to the style guide. Can an administrator remove said rules from MCW:Wiki Rules, archiving the current rules?
Since rules 18 and 22 are likely to get moved soon due to #Talk page guidelines, I would place them at the end so the numbers are only required to change once.
Also, rule 12 does not really fit with the rest of the remaining rules, although I cannot think of a better place to put it. –KnightMiner · talk 17:48, 23 February 2015 (UTC)
Alternatively, notability could be listed separate from the style guide, which would make the anchors a bit easier to deal with, and allow it to be protected without protecting the style guide. (sample here)
In any case though, something needs to be done with the wiki rules to finish this discussion, and the rules are administrator protected. –KnightMiner · (t) 16:54, 26 February 2015 (UTC)
The rules have been updated, with both the changes here and the talk page guidelines, since they don't belong there either way. I've left the archive page unlocked, if you want to make any changes to it.
In addition, I added the style guide to the sidebar. You may wish to propose a better tooltip for it. –Majr ᐸ Talk Contribs 09:27, 1 March 2015 (UTC)
MediaWiki:Deletereason-dropdown still needs to be updated, adding a new group for notability violation and updating the rule numbers. Currently I have not added anchors to specific notability guidelines, as based on what is wanted we would have only one delete reason for all of notability, or one per guideline. A single reason could be something like "Violates notability", although mentioning which guideline they violated would likely be better.
I don't have anything against the tooltip for the style guide, as it seems rather consistent with the other tooltips. I am mainly glad the link was added, as I use it frequently. –KnightMiner · (t) 20:16, 1 March 2015 (UTC)
It occurred to me while updating the reason dropdowns that rule #11 is a duplicate of rule #4, rule #7 sounds like it belongs in the style guide, and rule #12.1 should be its own rule, rather than a sub-rule of abusing multiple accounts. –Majr ᐸ Talk Contribs 02:16, 3 March 2015 (UTC)
Since these have only been in place for a day, I doubt they are heavily linked enough to require archiving again, so I would just make those changes:
Rule #11 does seem to be covered by rule #4, although I assume it was added due to Herobrine. If needed 4 can be expanded to specifically state facts must be from actual game features.
I really don't see why 12.1 is a subrule, I agree it should be its own rule.
Based on the new rules requirements, 7 could easily be moved to a brief line in "Writing". I cannot foresee anyone being blocked for not leaving edit summaries.
Done. Once the guidelines are all in place, we should probably put up a site notice about the rule and guideline changes. –Majr ᐸ Talk Contribs 04:23, 3 March 2015 (UTC)
You might want to reinstate the disallowing of users from abusing multiple accounts in the user namespace. (numbers changed, but not user namespace exceptions).
As for the rest of the stuff left incomplete, I'll propose that on the style guide a little later. –KnightMiner · (t) 04:30, 3 March 2015 (UTC)
Do you think a Category:Indestructible blocks would be useful? This category is for blocks that cannot be broken in Survival mode. 108.210.219.49 00:03, 12 February 2015 (UTC)
There would not be a lot of blocks (Bedrock, barriers, End portals, command blocks, and Nether portals if you do not count breaking the frame), so I am not so sure of the usefulness. If needed, a user can simply check Hardness#Blocks by hardness and see all the blocks that cannot be broken by hand. –KnightMiner · talk 16:50, 12 February 2015 (UTC)
New administrator
1, 2, 3. The activity of admins on this wiki is dropping down, to the point that administrative actions may take much time to be done. In that time, everything can happen: a new snapshot of 1.9 (with much new blocks, items, entities etc.) or a mass vandalism/spam attack.
To respond to that, we need a new active administrator, and I’m confident that KnightMiner is best candidate for it.
Unsigned comments by new or anonymous users will be deleted. Please sign your comments with ~~~~, which also can be added with or button.
I doubt I am the best person to state reasons why I should be promoted, due to this wiki's administrator promotion policy, so rather I will state a few other things.
The administrator activity is a bit lower than before, though most administrative issues are dealt with in a reasonable amount of time (Majr's response to the first mentioned topic stated that for the most part). The main thing my promotion would change as far as administrator activity is a couple hours where I am online and no administrators are online (towards the early middle of the time I can be found here).
Overall, I would advise if you think I should be promoted to change or expand your approach to state if and why you think my skills or experience would be helpful as an administrator, rather than only my time.
Promote: Basically agreeing with what KnightMiner said. On the contrary of administrator activity, (apologies beforehand to every admin and bureaucrat for checking the contributions) there have been some admins who have been inactive for quite a long time. Take IKJames, Hower64, and Kanegasi for example, who have been inactive since 2011 and 2013, respectively. I think we could promote a few more admins if need be. BDJP007301(t|c) 20:55, 2 March 2015 (UTC)
Split PE versions into their own articles?
I think the PE versions (listed in version history as of right now) should probably be split into their own pages. I talked about this in Talk:Planned versions regarding 0.11.0 being split into a new article (before it got too big) a short while ago and Knight suggested that I should start a discussion here.
TL;DR
Should we split the PE versions into their own articles or leave them as is? BDJP007301(t|c) 19:17, 20 February 2015 (UTC)
I would support splitting them. A few preparations would need to be made first, such as better support for non-PC versions in {{version nav}} (eg, support for multiple release dates and listing which editions got the release at all out of the four mobile versions). We would also need a value for the edition parameter which sets categories and likewise ("Pocket Edition", "Pocket" or "Mobile" would make sense). Lastly we would have to decide a consistent naming format (as of right now, "Pocket Edition version" seems to be the most popular).
I could work on the {{version nav}} changes if there is enough consensus to split the articles. –KnightMiner · talk 19:38, 20 February 2015 (UTC)
Merge granite, andesite, and diorite
I propose that granite, andisite and diorite, as the only differences are their look and the way they are crafted.Please state your opinion.71.35.109.25 19:37, 22 February 2015 (UTC)
They should be merged with stone. And Agree. –LauraFi-talk 21:08, 22 February 2015 (UTC)
This was discussed a year ago, see Talk:Granite#Merge with Stone. The general opinion was to avoid merging them, as rather than decrease the confusion, it would increase the confusion. A similar case was discussed a couple times on Talk:Red Sandstone to merge with Sandstone, and the two cases basically stated that even if blocks function the same way, the community prefers article separate.
Specifically, there is no title the three variants can be merged under that would make sense, and they are too different from stone to consider merging it with that article. Also the crafting recipes would become confusing attempting state the block can be crafting into another colored block. –KnightMiner · talk 00:01, 23 February 2015 (UTC)
How about decoration stone.71.35.109.25 14:48, 28 February 2015 (UTC)
Since they are never called that in game, nor do any of the titles contain "decoration" or "stone", it would simply lead to confusion. –KnightMiner · (t) 15:39, 28 February 2015 (UTC)
Account
I attempted to create an account, but I do not have an email.67.160.25.176 00:02, 24 February 2015 (UTC)
The only solution would be for you to create an email. Many places offer a free email account, and you do not have to use the email account after signing up. –KnightMiner · talk 00:10, 24 February 2015 (UTC)
Why do they ask for your email address?71.35.109.25 03:03, 24 February 2015 (UTC)
According to that, the email should not be required, but it is recommended to help with identification. For example, should you ever have difficulties logging in makes it easier to contact support. –KnightMinert/c 03:41, 24 February 2015 (UTC)
What happens if you try to use someone else's email address?71.35.109.25 02:01, 26 February 2015 (UTC)
You will not be able to confirm the email address, which prevents you from using any of the email features, thus defeating the purpose of adding the email. –KnightMiner · (t) 02:24, 26 February 2015 (UTC)
The page says that if you use your email, you will be able to send and receive emails, but even unregistered users can send and receive messages.71.35.109.25 02:30, 26 February 2015 (UTC)
Why is the wiki "official" ?
Hi, the main page's title is "Official Minecraft Wiki - The ultimate resource for all things Minecraft", but can someone explain me why it is official ? Did Mojang say something about it ?
I am wondering this because of that... • ObelusPA2d · FR Admin · 14:37, 4 March 2015 (UTC)
(User Page|Talk)
talk 13:42, 17 January 2014 (UTC)
17:35, 25 August 2014 (UTC)
T, C, b 17:52, 30 September 2014 (UTC)
or 
button.