Minecraft Wiki talk:Community portal/Archive 4

My Redstone Discovery
Hey, i'm new here - haven't made anything on this wiki yet, And i'm not sure if this is the right page to put this, But relatively recently i discovered a Redstone system, its like a one-clock, But it never burns out, Its designed this way, With R being Redstone Dust, T being a redstone torch, B being any block, A being air and J being redstone ontop of any block.

First:

BABAB AAAAA BAAAB AAAAA BABAB

Then:

BTBTB TAAAT BAAAB TAAAT BTBTB

The torches are on the sides of blocks by the way, So: T B Would have the torch on the north side of the block assuming ^ is north.

Then:

JTJTJ TRRRT JRARJ TRRRT JTJTJ

Then, finally:

RRRRRRR RJTJTJR RTRRRTR RJRARJR RTRRRTR RJTJTJR RRRRRRR

You can probably do it in more orders, but from what i've seen, Thats the most reliable method, i've been using this for a while, I'd appreciate it if someone put the method and system in the appropriate page on the wiki, and, provided this wouldn't be too arrogant, add "First discovered by LukeZaz" or the sort to the area, Thats my IGN name too.

Lastly, wherever theres a space in one of the steps (you know, BT or JT and such), imagine its a new line.

Merge pages about dyes
Having separate pages for each dye seems rather unnecessary to me, especially when you consider the short length of these pages and how little information there is to tell about them. Should we just make one big "Dyes" page that lists all available dyes along with recipes?-- 21:45, 13 January 2011 (UTC)
 * I would support this move, as one of the people keeping an eye on the Page. -St. Fenix (•) 16:46, 15 January 2011 (UTC)
 * I concur. -- 09:40, 28 January 2011 (UTC)
 * Seconding this, as I standardized the pages (somewhat), they started to all seem like repetitive stubs. I'm up for doing the grunt work if there's an authoritative consensus. -- 19:03, 29 January 2011 (UTC)
 * I disagree. I feel they need to be kept separate, lest we dive back into the days when mobs were all on one page.
 * while for now, it seems messed up, a lot of the dyes will likely have secondary uses. Obvious candidates are bone meal, ink sac, coco bean and lapis lazuli. If we merge them all to "dye", then all of the dyes will need merging. We will have 15 infoboxes, info about bone meal as a fertiliser to fit in, info about lazuli ore and all potential future uses for all dyes.
 * This is an editing nightmare, and layout-chaos. and even if the unique ones aren't added, that's still 11-ish infoboxes. That is way too many.-- 11:23, 31 January 2011 (UTC)
 * Separate page with the list of all the dies, but make it so that material that can be used to create dies have a link to the page:
 * Example-
 * Cactus would have a section for one of it's uses, being creating the [green die] which would be highlighted with a link and when click would be moved to the section of the die page where it would show a cactus, and how to turn it into die.-- 10: 03, 04 February 2011 (UTC)
 * Different items need different articles, so concur. - 13:34, 6 February 2011 (UTC)
 * I agree completely, as long as its done right. 02:17, 2 March 2011 (UTC)
 * I vehemently disagree with detractors here. I can see no strong case for why dyes should have individual pages. Bonemeal need not be merged but rather the bonemeal page can link to the dye page on which it can have its dye table. It stands to reason that mobs should have separate pages as they are all hugely different with different shapes, behaviours and functions. Dyes on the other hand are not so. A table can be made neatly and need not reference the alternate uses for various items in each table section. As for cactus, it can have a brief mention of how to obtain green dye on said dye page and a quick reference on the cactus block page as well. I would be willing to make a sample page and we can undo it if we like, but I suppose Miner Key has already volunteered and would do a better job than i could. -- 02:27, 16 March 2011 (UTC)
 * I'm neutral on this, but here's an idea: If all the dyes were on one page, perhaps the crafting box should be like the one for, ie. One animated grid? The more I think about it though, it starts to feel too complicated. 12:54, 19 March 2011 (UTC)

We could shorten it a bit by merging the flower dye pages together. (Putting Dandelion Yellow and Rose Red together) Then, we could pair cactus with cactus dye... -- 20:22, 9 April 2011 (UTC)

Disabling forced preview on authenticated users and allow unregistered editing with forced preview enabled
Basically, this would mean that people who are already registered would only have to authenticate themselves on their page, which is a really quick job and only requires you to register your email address. After this you are free to edit around without being forced to preview your work first. (but please try to do so every once in a while)

Along with that, we'd like to allow unregistered users to edit again, increasing the community, but only under forced preview so the spam is limited.

Please share your opinions on this matter.-- -  MCWiki Administrator  21:53, 3 March 2011 (UTC)
 * Personally I don't like unregistered users, I see it as if you can't be bothered registering for the site, then you can't be bothered making any good edits. So the only reason left to use unregistered is for spam.
 * Forced preview, well I'm not sure about that. I don't really think it's all that useful as back when I had it, I'd just click show preview when the page loaded, and start editing afterwards, so it was more of an inconvenience, than a thing to force me to actually check my edits.
 * I'd still like to see a "Trusted editors" group, that gives people some extra tools for editing, while not actually making them admin. – ( at 22:34, 3 March 2011 (UTC)
 * New user groups are not gonna happen. As for unregistered users, I'm all for it. People aren't going to register to fix typos, but they will fix them from an IP. Even that kind of small edit makes the wiki better. Excluding potential editors because they don't want to register is just anti-wiki. As long as the community and administrators are aware, spam/vandalism should not be a major issue. --   23:39, 3 March 2011 (UTC)


 * I personally am annoyed at the forced preview, but I also think that IPs can have good info, but should be encouraged to register. Hence, put a slight roadblock/inconvenience (forced preview) for them, but for registered users it goes away. -- 00:49, 4 March 2011 (UTC)


 * Or make them complete a captcha every edit. :P – ( at 00:53, 4 March 2011 (UTC)


 * All captchas have been broken by bots. I prefer the forced preview. --   05:49, 4 March 2011 (UTC)


 * That was a joke. – ( at 06:11, 4 March 2011 (UTC)


 * Not unless you used reCAPTCHA, that stops just about every bot and helps out with books, which I say if possible to use reCAPTCHA on top of this plan and then I'm for it... I guess. 05:54, 4 March 2011 (UTC)


 * LOL Ultra! And as has been documented, reCaptcha has also been broken by bots. The only real protection from bot spam is a vigilant community. I think this one is ready for anon edits. The potential editors we can gain far outweigh the negatives. --   06:15, 4 March 2011 (UTC)


 * Forced preview for me doesn't work as it should. I end up rushing past preview and still submit mistakes. It'll be much better to have it off for auto-confirmed users; the wikicommunity can shoot down any mistakes or whatnot. As for anonymous editors, they're cool for quickly fixing little spelling mistakes (as they tend to do) but it also opens the flood gates for more spam. Per Wyn though, there's enough activity to stay vigilant here. However, might I suggest using http://www.mediawiki.org/wiki/Extension:Approved_Revs for approving anonymous edits first? This way they can immediately submit fixes without hassle, then it's up to us to confirm them, so the mainspace isn't subjected to spam and malicious edits. -- 08:00, 4 March 2011 (UTC)


 * I loathe forced previews for unauthenticated editors, but I accept the necessity to get rid of spammers (bots and humans alike). I myself would have done lots of minor edits before, and would likely do so in the future without logging in even though I have a registered account. 10:21, 4 March 2011 (UTC)
 * I prefer you keep the forced previews, because sometimes I accidentaly click the Save button in the middle of editing. Also, don't allow unregistered users to edit, they either are: A. Too lazy to make an account or B. Spammers. If you do allow them, make sure you put reCATCHPA. 13:32, 7 March 2011 (UTC)
 * I also think allowing unregistered users to edit is bad; we get enough willing participants making accounts every day, it's not like it's hard, and it limits short-term spammers etc. As for forced preview, I can't express how much easier it is in the long term for users getting accustomed to this wiki when mandatory preview is off. NNOYING  23:39, 7 March 2011 (UTC)
 * I could not support the removal of forced previews more. Perhaps adapting an anti-vandalism bot for trusted users just to be sure would be a good idea though (Although there seems to be little enough activity at the moment to just check Recent Changes). undefined 13:48, 10 March 2011 (UTC)


 * No opinion on unauthenticated editors, but the forced preview is really annoying 90% of the time, and the other 10% I'd hit it even if it wasn't forced. Kill it, please. 08:36, 13 March 2011 (UTC)
 * I'd rather keep it because when I hit that "Preview" button I catch mistakes I wouldn't have seen. 01:30, 14 March 2011 (UTC)


 * Please God yes. Most of the time I preview anyways, but being forced to preview on edits I don't need to (like talk page comments where I'm not linking to all and sundry) is just a hassle. (that, and for most template work, preview doesn't catch any but the biggest syntax snafus) 「」· 01:40, 14 March 2011 (UTC)

Apparently, I more or less sparked this discussion, but I haven't been on MCwiki for some time, so I completely missed it :P Anyway, the rant I put on my talk page: It's one thing to have anon edits disabled (which already turns away tonnes of potential contributors), but the obligated show preview before edit is ridiculous. I've only just found out now, but after talking a bit on IRC on the gwiki channel, I immediately got response from a couple of people that that's why they don't edit here (anymore). Is Minecraftwiki actively trying to discourage editing or something? Wikis should strive to reach out to as many people as possible, and while it's primarily used as an information source, it shouldn't discourage editing. If someone finds an inaccuracy or error somewhere, or just wants to elaborate on a certain point they come across, they are forced to making an account (which, considering the many anon edits to gwiki, where I primarily reside, is a huuuuge turnoff), but every time they try to edit, they are also forced to virtually reload the page, for even the slightest edit (say, capitalising a letter in a text). It discourages vandalism very effectively, but vandalism is so easy to counter anyway that a wiki shouldn't limit it's editors to less than a quarter than they could potentially reach, if not more, just to counter it. Tl;dr: Allow anon edits, disable forced preview. Any additional spam/vandalism is easily outweighed by the massively increased amount of users and active editors. Also, I'm not a wikimaster or something, but Guildwiki has blacklists for links iirc. Dunno how it works, but I think it stops a lot of bots.-- 16:00, 15 March 2011 (UTC)


 * We have taken the first step in this, and removed forced preview for all registered users. Now let's get serious about the rest of the proposal. Wiki's should be a place where anyone who is interested in the topic can edit. (Please do not tell me what Wikipedia does as that simply does not apply here.) That being said, requiring registration to do any sort of editing is eliminating a HUGE portion of the users who visit and use this wiki from participating. I know you are going to say that registration is quick and painless, so why not just register? For a wiki noob (no offense intended by that nomenclature), first edits are often simple things like correcting typos, and grammar. Many people don't want to bother registering in the beginning, but would be willing to make these kinds of edits. These kinds of edits are actually crucial to a well presented wiki. This wiki is currently attracting somewhere in the range of 70 million views a day. Think about how dynamic this community could become if we open it up to anon editing... The possibilities are endless. Please consider this and comment. --   01:34, 19 March 2011 (UTC)


 * I don't really know why the unregistered users have to preview, I mean if they're just doing grammar and punctuation etc. then they should be the ones without the preview, not us. -- 12:04, 4 April 2011 (UTC)


 * My opinion is that forced preview should stay. However, I do think it would be okay for non users to be allowed to do a few things. Such as:

JSan 21:21, 20 April 2011 (UTC)
 * Requesting a page to be deleted.
 * Edit X number of words per day to fix grammer issues and such.
 * Post in a suggestion box for non members, allowing someone to view it and decide if it is worth using the given information.

Anonymous editors can make edits just as good as registered ones. I see no reason to limit their capabilities to fixing grammar. 16:55, 21 April 2011 (UTC)

Should a page be made for this?

 * KizzyCocoa tweeted: "@notch @jeb_ This is one of the coolest Minecraft mods ever: http://i.imgur.com//rBqdC.png"
 * Notch replied: "@Kizzycocoa @jeb_ Oh wow. :D That's actually planned, though!"
 * KizzyCocoa replied: "@notch @jeb_ cool! great to hear that! :D"


 * So. Looks like we're gonna be getting shelves soon. Would it appropriate to create now?  05:00, 5 March 2011 (UTC)
 * I'd say no, don't speculate; wait until shelves are actually added. 06:21, 5 March 2011 (UTC)
 * "Don't speculate". Ok, then what about the pages for the Trap Block, or the Scare Crow, or even the Mystery Block? Speculation galore right there. ;) 06:32, 5 March 2011 (UTC)
 * It can be added as long as it's tagged properly as is . --   06:50, 5 March 2011 (UTC)
 * Well I didn't create these pages... I still think speculation should be kept to the forums. 12:56, 7 March 2011 (UTC)
 * I will add this page to my "to-do" list.-- 19:40, 30 May 2011 (UTC)

Is there a need for a Welcome Project?
The heading sums it up well enough.

I had considered just placing the concept on the Project page, and sketching out a brief framework on its attached sub-pages, but I am not too sure that there's an actual need.

Are there sufficient new users such that a welcome/newbie-patrol project is needed, or are the number of edits of sufficient number and quality that it is obvious that new members are picking up on the rules and culture of this wiki? Is there sufficient interest from existing members to participate in it such that establishing it is worthwhile (and not overtaxing)? - 10:16, 7 March 2011 (UTC)
 * Hmm. Depends whether you want to go that way with welcoming users. I have a colleague who works for the Wikimedia Foundation and they did a study and found big annoying copypasted welcome templates were more likely to scare off users than help them assimilate into the wiki.
 * However, I'm not against the idea of giving newbies a directory to look up once they've made an account. My idea is to make a template at that outlines the welcomenewbie things we need to show them. That page is the first thing all new users see when making a new account. I think that's a must, whether we want to use that template is some sort of talk page welcome system is a separate issue IMO. NNOYING  12:10, 7 March 2011 (UTC)


 * Doesn't sound like a bad idea; we have plenty of new users each day (10 to 20 or so?) and its never a bad thing to help newbies on their way, is it? So how would it look like? A simple FAQ, some examples, stuff like that?-- -  MCWiki Administrator  15:12, 7 March 2011 (UTC)


 * I thought that it'd be better to poll newbie-need and participatory-desire first before moving onto the nitty-gritty of development and operations. I think any discussion of such would be best served on the Project page.  If I see another "yes, good idea/we need this" posted here, I'll post up the Project page and those interested can brainstorm therein. - 22:59, 7 March 2011 (UTC)


 * I would like to echo Aclectasis thoughts that creating big welcome templates is generally a fail situation as they tend to come off as overly official, and intimidating. I would recommend something more in the line of some dedicated wikiers who are willing to commit to being available to assist new editors upon request, as well as to just be more aware of new edits via the, and willing to jump in and provide guidance to people who are obviously having difficulties. I do agree it is worth talking about, so I say create the project page and let's move the discussion there. --   23:28, 7 March 2011 (UTC)


 * A project for this might be a little too much for a simple job. I've been doing this to some degree (a good example ) but I've been kinda putting less effort into it because it doesn't seem to have much effect. I think there should be a project to better beef up the help pages and formulate better guidelines for the wiki and then create article creation wizards/checklists (using the inputbox extension) to make things easier for them and for us by decreasing the amount of junk new pages we get.


 * On a semi-related note, welcome templates for talk pages should be an absolute no-no. They are horribly impersonal and just get ignored. -- 23:44, 7 March 2011 (UTC)


 * There's no reason there can't be both project (Help pages and Wiki Helpers). Beefing up help pages don't do any good if people can't find them, don't have basic wiki coding skills, etc.. The Helpers could make those impersonal Help pages make sense, as well as point to them. I'm not so into wizards and checklists..... --   23:52, 7 March 2011 (UTC)


 * I think there's enough discussion here warranting the creation of the project and a talk page to discuss it all therein. The Project page is up, and I'll be copy-pasting this to the talk page there for reference reasons. - 01:08, 8 March 2011 (UTC)

Chinese Translations?
Since more and more people are playing Minecraft now, should we have a Chinese translation of the wiki? This can help unify Chinese players out there (unlike other languages, MC Chinese userbase is rather discrete IMO). 13:30, 9 March 2011 (UTC)
 * Already started --    13:36, 9 March 2011 (UTC)

Oh, I'm sorry. Gonna remove this in the RFC section now. 15:12, 9 March 2011 (UTC)

System requirements?
I have a small Dell Inspiron mini. what exactly are the system requirements of minecraft? I dont want to buy the game if it wont run on my computer. Thanks 02:37, 10 March 2011 (UTC)
 * is probably the only hint you'll get. As for my answer, pretty sure if you can play the java applet of Classic, you should be alright for the game. NNOYING  10:32, 10 March 2011 (UTC)

I only know you need java as the most important part. but then again, i just bought it, never really looked at the system requirements. It runs perfectly on my computer though.

Recent Spam Attacks
I've noticed they have been happening a lot within the past two days. What should we do about it? My suggestion is filling out an application, and then e-mailing it. 02:17, 12 March 2011 (UTC)
 * I'm not exactly sure I follow what you are proposing. There are a few things that can be done about spam, but the best option is a vigilant community. Spam and vandalism are a fact of life on any wiki, and there is virtually nothing that can be done to get rid of all of it. This is a community driven site, and it's success lies with the community that maintain it. Unless it becomes a major issue, I will not back any proposal that makes it any more difficult for the community to contribute, in fact, just the opposite, I would like to see this wiki opened up to IP editing. --   11:05, 12 March 2011 (UTC)

Set up rules for screenshots used in the mainspace
I've noticed that the screenshots used on the wiki all use different texturepacks, default, high-res, custom UI's, etc. I propose to throw in a rule on screenshots that no longer allows screenshots with texture packs/UI mods, and only allows Vanilla textures and UI's. The wiki should be understandable for as much people as possible, and showing screenshots with custom content in it isn't really helping out there.

Of course, this has no effect on the and  pages, although I personally advise the writers of tutorials to show Vanilla content everyone is familiar with.

Throw in your opinions, comments, additions, and lets see what this'll result in.-- -  MCWiki Administrator  22:47, 12 March 2011 (UTC)
 * I would support this idea for all pages except mod pages :D --   22:54, 12 March 2011 (UTC)
 * I'll chime in with agreeing on all Q's points. The Tutorials should be vanilla so that viewers can visually check that what they'v created is close to what is shown. - 23:33, 12 March 2011 (UTC)


 * Another suggestion: for anything where the GUI is not required, hit F3 before you take the shot. Otherwise, the GUI just gets in the way.   16:00, 18 March 2011 (UTC)
 * – ( at 00:55, 13 March 2011 (UTC)
 * With texture packs it's hard to tell which is which unless if you're familiar with that specific one. 00:33, 14 March 2011 (UTC)
 * -- 02:49, 15 March 2011 (UTC)
 * MoonBeans (--) 14:38, 15 March 2011 (UTC)
 * How about this as the rule: "Please use a vanilla minecraft with a vanilla texturepack when showing screenshots so that the wiki is understandable for as many people as possible.  Screenshots with alternate texturepacks or UI mods can be confusing." -- 22:03, 15 March 2011 (UTC)
 * 20:54, 17 March 2011 (UTC)
 * I'd say yes, but either include a small note somewhere about the nominclature, or just call it the default UI/texturepack to begin with. &mdash;

Alright, considering the positive feedback we're getting on this, how about we bring it in effect? Let's get working on this right away! I'll set up a project for replacing all existing screenshots that aren't following this new rule later today.-- -  MCWiki Administrator  08:57, 21 March 2011 (UTC)
 * Rule added and started.-- -  MCWiki Administrator  15:51, 21 March 2011 (UTC)

Consolidating block information in one place
I've created and  to hold data that is defined for every block, but used in multiple places. For instance is used in  to fetch the Blast Resistance for the block, but its also used in  to create the table there. This prevents data duplication, which means values are in sync and you only need to edit stuff in one place. That's all to the good. However, it also makes it harder to change the value, because instead of changing it on the block page (in the template parameters) you have to go change it inside the template. Also, page moves (which seem to be rather frequent) will break the link, requiring it to be updated in several places.

What would be ideal is if the data could be stored on the block page itself, but still transcluded elsewhere. What are the chances of getting Labeled Section Transclusion installed? That would allow us to label the data in the block infobox and transclude it into tables or formulas elsewhere.

The reason this came up is that in order to programmatically generate the table at, I need to get the tool type per block. So I wanted to figure out a good way forward before rewriting the block template to pull out the tool type into a common table. 08:34, 13 March 2011 (UTC)


 * I've added an edit button to the block template that links to and I'll add a link on  aswell. I don't really think you need anything else.  – ( at 09:28, 13 March 2011 (UTC)


 * After pouring through the MediaWiki docs, I've found an elegant solution that has all the good properties and none of the bad. I'll be updating the invocation of on the individual block pages to look like this:  . When you view the page, there is no first parameter so the argument substitution falls through to the default of "Block", and thus invokes the Block template over the infobox parameters. But we can also include the page itself and pass a getter function like  as the first argument, which evaluates in this example (after all transclusions) to "blah."  This means that all the data values will be set on the block page, where people expect them to be. Even better, transclusion follows redirects, so when a block page is moved it won't break the data tables that are including it. (Unless it gets moved twice, but then you need to deal with the double-redirects anyway.) Also, this method is more efficient than having long switch statement templates. It's a win-win-win-win all around!  19:59, 13 March 2011 (UTC)


 * At that point, wouldn't it be better then to have that infobox code in the same page name, but in the Template namespace? That way, future invocations won't have to be as namespace aware. -- 20:53, 13 March 2011 (UTC)


 * I'm not sure what you mean? My goal was to keep all the data in the infobox template, so that it'd be easier for the average user to find and edit. If there's a way to do that that's clearer than the system I've half-layed in, then I'm all ears. 00:26, 14 March 2011 (UTC)


 * I'm personally not that pleased with these changes. There has been virtually zero discussion before you just did it, and in my opinion, it simply makes it more difficult for average users to edit. Why is everything on this wiki so friggin complex? --   21:03, 13 March 2011 (UTC)


 * You're right that I was too eager/impatient in making these changes, and I'm sorry for that. I think I've documented stuff pretty well at Block now, let me know if it makes sense. I am trying my very hardest to not make things harder to edit; I'd much rather have a hairy template (that's well-documented but no one ever needs to look at) than put up roadblocks to doing the simple things. However, I also want to make it possible for people to do complex things with the block data if they want to. After all, Minecraft is a deceptively complicated game, so it attracts people who like to do deceptively complicated things on the wiki. :) 00:26, 14 March 2011 (UTC)

I've also added a note to, but basically I'm doing what I should have done in the first place and waiting to see what people think. I've documented my (proposed) scheme at, I think it's pretty easy-to-use but of course I'm biased. :) 00:50, 14 March 2011 (UTC)


 * As I mentioned on your talk page, D0sboots, at this point perhaps it'd be better to try and get support for installing SMW. It would ultimately require at most, very minor changes to infoboxes on articles, but once proper support is added to the infobox templates, the values could be reused pretty much anywhere. If you want to get a look at it in action, the relies heavily on SMW;, , and  are good examples of what can be done with SMW (though they only barely scratch the surface; SMW is an incredibly powerful and deep MediaWiki extension ;) ). 「」· 01:15, 14 March 2011 (UTC)


 * I'd love that; it would certainly be a lot cleaner and simpler. I was under the impression that new extensions are a "not-going-to-happen" sort of thing, but if SMW is a possibility I'd be very happy to wait for it. 01:22, 14 March 2011 (UTC)


 * Rather unusually for me, I'm not terribly deeply involved in the more technical aspects of this wiki; there could well be a "no to new extensions" attitude here, and I'm just not aware of it. However, it would never hurt to ask (especially since SMW would ultimately allow for so much more really neat stuff than just this; we're still coming up with crazy cool uses on the YGO Wikia (and, probably, stressing the Wikia staff appropriately as we continue to see just what we can get away with)). ;) 「」· 01:29, 14 March 2011 (UTC)


 * I'm highly against this odd safe get nonsense. You say you want to consolidate the information into one place, which you did fine by keeping it all in one template; but now you've gone and split it back up onto separate pages again, using heaps of complicated templates that make no sense to me. I vote keeping them all in one template; it was easy to edit, and anyone can do it. – ( at 01:59, 14 March 2011 (UTC)


 * It's a different type of consolidation. You can think of the block data as a big matrix (or a big table): Each row represents a block, and each column is a specific property. My proposal "consolidates" along the rows: all the information for a particular block is together in one place. The other way of doing it is to have all the information for one property in one place, storing it as some kind of array. If we only needed one property, I'd agree that that's totally the way to go: just have an array and be done with it. But some things require a lot more than that. For instance, I'd like to make completely dynamic. And it's totally doable, although the template for it will be pretty ugly, but to do it you need access to the hardness, tool, and toollevel properties. (Toollevel indicating how good of a tool is required to harvest the block - it only needs to be specified for a few blocks, the way things are right now.) Setting that up would involve making 3 more data arrays, and moving more stuff out of the Block template. The real kicker is that if you ever decide to rename a page, now you have to hunt through 4 templates and manually fix up the references there. In some ways it's cleaner, but overall it seemed like a worse solution to me.  03:56, 14 March 2011 (UTC)

Header Tabs
If you don't know what header tabs are, head. Header tabs would add more than "Page, Discussion" tabs at the top. This could allow us to make multiply versions of pages for each version of minecraft. Use; if the tag is on the page anywhere, then any level one headers (normally not seen, page title) will become a new tag at the top of the page ie; "Pig, Pig Alpha, Pig Infdev, Pig Indev, Pig Survival, Discussion". I am calling a vote on whether we use these or not, if we get enough votes, Wynthyst will add the addon. MoonBeans (--) 14:28, 15 March 2011 (UTC)
 * Oops, heres a link;
 * - MoonBeans (--) 14:39, 15 March 2011 (UTC)
 * No, that's not at all what HeaderTabs does. It allows you to "stack" information on a page turning level 1 headers into tabs. And we don't vote, we discuss. I wish someone would delete those stupid "voting" templates. --   19:03, 15 March 2011 (UTC)
 * 20:57, 17 March 2011 (UTC)

Wanted Pages
In the wanted pages the vast majority are pages that need to be translated. I am not and most of us are not bilingual. So I propose that we have a separate page for pages that need to be translated. This would make it much easier.-- 23:29, 15 March 2011 (UTC)7cardcha
 * Those will all be resolved by the various translations that are dealing with them. No need to even address them. The "Wanted pages" is a built in function of the software, there is no way to "filter" it. --    07:33, 16 March 2011 (UTC)

Few Pixels of Margin Below the Footer
The site could do with a few pixels of margin below the footer, right now the footer text touches the very bottom of the page which doesn't quite look right. –The preceding unsigned comment was added by ( 00:53, 18 March 2011. Please sign your posts with  !
 * I have a whole mouse-sized margin at the bottom of the pages. Could you provide a screenshot of the problem? –  00:24, 18 March 2011 (UTC)

A couple of changes
Due to the spam posters that have been hitting MCW lately, we have made a couple of configuration changes. New pages can now only be created by users who have also met the requirements as Autoconfirmed. You can verify your status by clicking on My preferences and checking what groups you are a member of. This should have little affect on most legitimate users. Thank you for your understanding. --   00:02, 19 March 2011 (UTC)
 * Well, it seems it hasn't done much. We're still getting a lot of spam pages. 01:50, 28 March 2011 (UTC)
 * Well, it seems it hasn't been done yet. This week, I swear! --    02:07, 28 March 2011 (UTC)
 * This has now been implemented. To become a member of the Autoconfirmed usergroup, you must have 10 edits and 3 days from the time you register your account. This should not be too much of an inconvenience to legitimate editors. Thanks for your understanding! --   12:33, 1 April 2011 (UTC)

Favicon, still
I made a favicon (tiny address bar logo) for this site. I don't have the permissions / know where to put the file in, so asked someone else to do it. That was nearly 5 months ago, so here's a reminder. The original topic is in the Discussion Archive here, and the favicon in question is hosted here. 12:50, 19 March 2011 (UTC)


 * Why would we want a blurrier version of our current favicon? – ( at 12:57, 19 March 2011 (UTC)

Pigs
Pigs are 1.1 blocks high but they can get through a one block hole in my wall. How is this possible? Pigs can't 'crouch' or whatever so are they shredding their head going through the hole?

By the way do pigs and other animals catch on fire?

 undefined undefined  01:45, 20 March 2011 (UTC)


 * They may look that tall but they can get through probably because their hitbox is shorter. Also all entities can catch fire.
 * I'm quite sure they take damage at the same rate as the player character NNOYING  09:49, 21 March 2011 (UTC)

Influx of Spam Pages
Recently we have been experiencing an influx of new spam pages. If you see a non-minecraft related page, report the page and user who created it here:
 * Kalaredf for creating the page
 * No, report them on the that's what it's for. --    17:12, 27 March 2011 (UTC)

Custom Maps
Like with what were doing the Mods page, can we make on for custom maps? 22:32, 27 March 2011 (UTC)

The wiki's name
Originally the wiki was called "Minepedia", a great name as this is, the domain http://minepedia.net is owned by another wiki, who shamelessly copied the name (and a lot of pages) off us.

After the move to Curse, the wiki was re-named to the "Minecraft Wiki", as seen in the Minecraft Wiki: namespace (originally Minepedia: The Minecraft Wiki!:) and the main page name.

Now it is often referred to by both names, and considering the logo and namespace are different, no "official" name has been set.

So the question is, what should the wiki be officially called? The "Minecraft Wiki", or "Minepedia"?

If "Minecraft Wiki" is chosen, should the logo be changed? It could be simply changing the text, or even an entire new logo (although aside from the text, I personally quite like the current one). – ( at 03:52, 29 March 2011 (UTC)


 * I agree, Ultradude25. -- 23:35, 29 March 2011 (UTC)
 * maybe instead we could name it Wikicraft -- 16:30 1 april 2011 (UTC)


 * someping, as good as your suggestion was, I reckon that MineCraft Wiki and Minepedia are better. Also, it will be an extremely large pain to move the website to wikicrafti.net or whatever.
 * Anyway, I agree with Ultradude25. I think we need a better logo, though. Perhaps the real MineCraft logo, with a snazzy 'wiki!' splash. 07:00, 1 April 2011 (UTC)
 * I'm all for MinecraftWiki, shortened to MCWiki. Its a shame that an other wiki with low-quality content and a really rude attitude gets to have the name we had in the first place, but whatever, they'll die eventually anyways. MinecraftWiki (MCWiki) it is, if you ask me.-- -  MCWiki Administrator  11:23, 6 April 2011 (UTC)
 * I'm glad you guys were discussing this. Legal issues have come up and we can no longer use the Minepedia name. I have changed the logo, of course you guys can make adjustments... however.. this is something we want standard on ALL the wikis, so.. feel free to discuss here, but it's up to the directors to implement changes across the board. --   16:58, 5 April 2011 (UTC)
 * I hope no one finds the word Minepedia at the german wiki any more. -- -  de.Wiki Admin  17:03, 5 April 2011 (UTC)

Hour
When we do the signature, a hour shows up. The problem is that the hour is not good.

-- 23:37, 29 March 2011 (UTC) Please expand this article!
 * You can set your time zone in your preferences, and choose the format it's displayed in. --   23:48, 29 March 2011 (UTC)

Thanks! -- 14:50, 1 April 2011 (UTC)

Random Page in multiple languages
Sorry if this isn't where this belongs. But when I hit "random page" it brings me to pages in other languages (randomizing...it's super effective!). Is there any way to code it so that random pages stay within the same language? Not that I don't appreciate the translation efforts, obviously, but I'm not well versed in korean :D
 * If you're in the wrong wiki, you can switch so easily -- -  German Wiki Admin  18:44, 31 March 2011 (UTC)
 * Unfortunately, the Random page feature is built into the software. We have no control over it. As long as we have active translation projects, landing on a foreign language page is always going to be a possibility when you use it. --   19:14, 31 March 2011 (UTC)
 * Ah, I see. Well thanks for the heads up then, I wasn't sure how that was working. :) -izzie

Publicity
Publicity on this site is driving me crazyyyyyyyyyy! Please remove all the publicity!!! -- 14:56, 1 April 2011 (UTC)
 * Publicity ? You mean the TWO ads on each page? Sorry, but they aren't going anywhere, they are how Curse pays it's bills. --   18:18, 1 April 2011 (UTC)
 * I think he means the spambots who were posting links. 16:50, 2 April 2011 (UTC)
 * Well, that issue has been dealt with, and should not be a problem any longer. --   16:56, 2 April 2011 (UTC)

Do wolves spawn in worlds created before beta?
The title sort of explains it, but my favourite world I always play on was generated before beta and I really want a wolfie to keep me company and chickens/ other animals don't work for me. And don't ask if a creeper is a good pet for me to keep. ~MeYouAndTheRadio


 * Wolves usually only spawn in the Forest and Taiga s (though apparently they can rarely spawn elsewhere). They should spawn even on pre-beta saves, but you'll have to travel until one of these biomes is generated to have a good chance of one spawning. 「」· 16:27, 2 April 2011 (UTC)

Ok, thanks. How many trees per chunk are in the forest biome? -- 06:27, 3 April 2011 (UTC)
 * You'll probably get a better answer on the actual biome page, but I'm pretty sure the tree size ranges from medium to large. NNOYING  08:54, 3 April 2011 (UTC)


 * Ten trees per chunk (16x16) -- 12:14, 4 April 2011 (UTC)

Thanks! Its going to take forever for me to find a taiga or forest biome cause my whole world is basically rain forest and desert >.< -- 20:06, 9 April 2011 (UTC)

Altering land biomes
I found my wolves in a flat paddock and they just keep spawning. According to the biomes article, the biome my wolves are spawning in is Plains, even though they are only supposed to spawn in a Taiga or Forst biome. However, There used to be a Forest biome here and I burnt it down. Do biomes stay in the same location or will they change? This incident will back up biomes not changing locations or switching. -- 12:12, 4 April 2011 (UTC)


 * I'm guessing it's in the code as forest, even though it's been modified. 12:17, 4 April 2011 (UTC)


 * Biomes never change. Burning down a forest biome makes it a forest biome with no tress in it. Removing all the snow from a taiga biome makes it a taiga biome with no snow in it. Either way, they're still the original biome, they just look different because you've changed them. This will be proven better once taiga is fixed to have snowfall, as no matter what you do to the area (aside from lighting it all up so all the snow melts) snow will continue to generate there. – ( at 22:47, 4 April 2011 (UTC)


 * Thanks. -- 06:53, 6 April 2011 (UTC)

Minecraft Wiki logo
In past I has already written about that, but I will try again with fixed version...

This logo is IMO much better than current logo [=

How do you think? PL (/ # /)  22:19, 5 April 2011 (UTC)


 * Its a default render of a grass block with some text and added glow. Sorry, but I don't really like it.-- -  MCWiki Administrator  23:09, 5 April 2011 (UTC)


 * Have to agree there. It's not even isometric or centred correctly. – ( at 00:18, 6 April 2011 (UTC)


 * Also, I remember seeing a clone of this wiki have something similar. I just don't remember where because it was a long time ago. 01:47, 6 April 2011 (UTC)


 * Indeed, too much similar to this one :  –   07:04, 6 April 2011 (UTC)

Would weather and Achievements/Stats work for worlds generated pre-beta?
I'd like to have weather and achievements/stats in my pre-beta generated world. I'm deeply interested in them and would like them in my world :) -- 20:14, 9 April 2011 (UTC)

I see absolutely no technical reason why not. Plus, there's A LOT of pre beta maps out there, it'd be ridiculous to think they would do that. -- 21:01, 9 April 2011 (UTC)


 * As far as I know, there really isn't any way (other than statistical analysis) to tell the difference between pre- and post-beta worlds anyways. Weather may or may not act weirdly on pre-biome maps (my money's on "not", by the way), but achievements and stats shouldn't be affected in any way by the map's age. 「」· 05:11, 10 April 2011 (UTC)

Using images from Minecraft Wiki
Hi there,

I have a growing interest in Minecraft and programming so I decided to make a block and item identifier (an information program). Now this program would be completely useless without all the images so would it be possible for me to get permission to use images found on Minecraft Wiki?

Header bars

 * Moved to 

locked chest mod
maybe if possible someone could make the locked chests return but have no screamer or sezure mode. im asking if someone can do that

02:37, 12 April 2011 (UTC)

Romanian Language
I know this would be useless, but I would like a Romanian Minecraft Wiki. I would be in charge of it, you only have to create one. –The preceding unsigned comment was added by ( 10:38, 12 April 2011. Please sign your posts with  !
 * You have to start a, and if the translation is going nicely, there will be an Romanian domain created. –  09:12, 12 April 2011 (UTC)

Abandoned Projects
I've noticed that the Welcome project, and the Mob research project haven't really had anything happening (this is based on the project page/discussion page, so I could be wrong). What happens to an abandoned project? Is there a precedent of some sort? Are they just deleted and forgotten? 01:19, 13 April 2011 (UTC)
 * We can move them into an inactive status if it's a problem, but leaving them listed allows new people to pick them up if they wish. There's no harm in them remaining. --   01:43, 14 April 2011 (UTC)

How to create a new page?
I came from China, however, now I live in the UK therefore I'm good with both Chinese and English. I am willingly to contribute and translate some of the wiki articles into Chinese as I am sure this would help a lot for the Chinese players. I have a problem here as I cannot create pages (subpages), I followed exactly as how it's instructed in the project page but I just can't create a new page. Don't I have the privilege? What do I need to do in order to create new pages and start translating for Minecraft Wiki? Thanks a lot for anyone who helps. 10:21, 13 April 2011 (UTC)


 * Just specify the nme of the page you want to create in the address bar, then click "edit this page". Also, confirm your email address, may help. <font color="Blue">C <font color="Orange">ali <font color="Purple">nou - ×  » 09:56, 13 April 2011 (UTC)


 * I did confirm my email address, also I've specified the name of the page that I want to create in the address bar, it says there isn't any content in this page, but it doesn't give me any option at all to either edit or create this page. What do I do noe... 10:21, 13 April 2011 (UTC)


 * I can create a page for me... I don't know why you can't. <font color="Blue">C <font color="Orange">ali <font color="Purple">nou - ×  » 10:28, 13 April 2011 (UTC)


 * That's the problem... I don't know why I can't...I tried to edit an existing page and change the address to a non existing page, and it says I don't have the permission to edit this page because I don't have the permission to create new pages. And yes, this happen on any pages I want to create, so it can't be to do with the page is protected. So, why... 11:09, 13 April 2011 (UTC)


 * Look here:, you must wait 3 days and have 10 edits. –  12:14, 13 April 2011 (UTC)


 * Is this real? so do I just wait for 3 days and make 10 edits and then everything will be fine? 12:47, 13 April 2011 (UTC)


 * Why would it be fake? – ( at 12:48, 13 April 2011 (UTC)


 * Thanks so much for all your helps, I hope our Minecraft Wiki will become better and better! 12:55, 13 April 2011 (UTC)

Naming of pages vs. official names
I propose that certain pages be renamed to correspond to the actual in-game names, since they are distinct. I did this once for one page and it was reverted for consistency with the others, so I want to propose this as a bulk change before actually doing it everywhere. The most notable such pages are: And so on. (I haven't finished reviewing all the names; I'll see if the idea is liked before refining it and making sure I've got all the names exactly right per the in-game tooltips.) Besides the improvement in consistency, I believe this will also simplify the wiki by having fewer piped links ( and so on). Does anyone object to this plan or have suggestions? — 12:06, 13 April 2011 (UTC)
 * → Redstone Dust (Item)
 * → Redstone Dust (Block)
 * → Redstone Torch
 * Redstone (Ore) → Redstone Ore
 * → Block of Iron
 * → Block of Gold
 * → Block of Diamond
 * → Iron Ingot
 * → Gold Ingot

I partially object: Block of iron, gold and diamod should change, buthe resst should stay put. -- 12:24, 13 April 2011 (UTC)
 * Do you have a specific rationale for leaving them as is? You've just pretty much proposed the opposite set of changes than Ultradude25 did. — 12:42, 13 April 2011 (UTC)

The Block of <> pages I don't like as it sounds rather stupid. I personally think the redstone dust and wire pages should be merged, they're the same thing. – ( at 12:32, 13 April 2011 (UTC)
 * It is a tad clunky, but I'm mainly proposing that we have a policy of sticking to the official names. I agree about the redstone, actually; the fact that the wire and dust have different IDs is not actually useful to most players. — 12:42, 13 April 2011 (UTC)


 * I think it'd be better to bug Jeb about changing the name to <> Block so it matches the ingots... – ( at 12:48, 13 April 2011 (UTC)

Given what feedback I've received here, I will rename the ingot pages and any other ones that aren't as complicated situations as Block Of and the redstone pages, and see how it works out. I'm a bit busy right now so I'll do it later. — 13:30, 15 April 2011 (UTC)

I've noticed that renaming items raises the issue of renaming the images used in crafting grids. Will a move-with-redirect work here too? I'm not touching those for now because I don't know about the details of all the template workings. — 19:33, 15 April 2011 (UTC)


 * As I mentioned on your talkpage, you shouldn't just go ahead after less than two days of discussion - give people time to notice your proposal, discuss, and give more feedback.
 * I object, simply because we've used this kind of naming since the very beginning and its just works. Moving everything is unnecessary and requires a lot of fixing, for example the grids you mentioned.-- -  MCWiki Administrator  19:43, 15 April 2011 (UTC)


 * As best as I understand it, the on-wiki naming is a relic of the fact that tooltips weren't implemented in Minecraft when these item articles were created. Now that we have official item names, wouldn't it make more sense to actually fix the templates to use the right names? Sure, there's work, but the disruption would be minimal if edits are queued properly and all land around the same time. -- 23:53, 24 April 2011 (UTC)


 * Another reason why I object is because the current naming is more encyclopedia-friendly and looks more professional. Besides, we have redirects in place for those who search on the in-game names, so its not even a problem for those searching.-- -  MCWiki Administrator  02:10, 25 April 2011 (UTC)


 * Encyclopedia-friendly? I'm not sure I understand what you're trying to say there. I would strongly argue that having parentheses everywhere is less professional and lends itself into looking like the editors are too worried about getting down into implementation details rather than presenting an accessible overview of how things work. Disambiguated article titles should be the exception, not the rule, especially in cases where the items in question have different names. Not that I can find a anywhere, either... Let's go to some examples:
 * Clay: Since the block and the item are both called Clay (or they were the last time I checked), they can be found at and . "Clay" would be a dabpage pointing to those two. Clay blocks are dug into clay items, which can be turned back into blocks or smelted into s, of which four can be crafted into placeable . Assuming the #3 case is called Clay Brick &mdash; I don't seem to have any of those lying around to check and I'm not about to go searching for more clay. If the #3 case is called "Brick", then the Brick article belongs to #3 with a hatnote to "Bricks" for #4, and a similar hatnote in reverse.
 * Iron and Gold: covers both the natural block and the item mined from it, an  is smelted from #1, and a  is crafted from nine of #2. "" would be a dabpage pointing to the three items, though I suspect that when people search for iron they're looking for the ingot case. Gold would be analogous. Diamond and Lapis would only need the first and third articles ( and, respectively), since there is no intermediate smelted version. "Glowstone Dust" and "Glowstone" work too, now that I think about it.
 * Redstone: "" should supersede whatever is in and  and cover where to find redstone in the depths and the basic tenets of how wiring works. Torches and repeaters are linked from the crafting section, not a hatnote, since they have their own names. More advanced circuitry is in  (or somewhere else), linked via a hatnote and a  link in the "Wiring properties" section. I would probably split (read: disambiguate) the pressure plates, since they share a name but have different mechanics. Doors are named differently and probably should be split as well.
 * I can't think of any other cases off-hand that couldn't be handled in a similar way. So is there a reason other than inertia as to why we should stick with the status quo? -- 05:59, 26 April 2011 (UTC)

Status
Done/no further action:
 * / — both have the in-game name "Clay", so leaving these
 * / — both have the in-game name "Clay", so leaving these

Moved, but needs text edits to the :

To do:

Leaving alone for now pending consensus:
 * — in-game name is "Redstone"

Needs research on naming:
 * Clay brick vs brick block - probably another name conflict
 * Slabs
 * Glowstone (dust and block)

Creating a "Minecraft" Page
As noted in the page where this discussion is taking place, there isn't a page about Minecraft itself, even though this wiki is about Minecraft. I have found out that this isn't currently possible because if you put Minecraft in the wiki searchbar the main page will come up. Nobody other than a moderator can't fix this. Until this is fixed, this desired page cannot exist on this wiki! --JSan 00:16, 14 April 2011 (UTC)

The minecraft page will be created by administrators when they feel it's necessary. Don't worry about it. 00:31, 14 April 2011 (UTC)


 * That is not true. You simply have to overwrite the redirect that's currently on the page . Anyone can do this. --   01:04, 14 April 2011 (UTC)


 * Wasn't that easy? --   05:44, 14 April 2011 (UTC)


 * Yes, actually, it was. It's expanding it with well-written, well-sourced prose that's hard. =D <span style="white-space:nowrap">「」· 07:16, 14 April 2011 (UTC)

Pretty embarrassing, but...
I can't create pages. Do I have to do a certain number of edits before? When I click a non-existing link on the wiki it tells me to search, no option for creating a new page.
 * You have to be part of the Autoconfirmed usergroup. Mean, having an email registered, be registered for 3 days, and have 10 edits. --   05:53, 15 April 2011 (UTC)

Need an image for your article?
I can help. Write a message to me on my talkpage, and I'll try to get the image for you. Thanks! -- 23:43, 18 April 2011 (UTC)

How do I remove pages in my namespace?
I have an article in my namespace and I don't wish to make this tutorial anymore. Can someone remove it, or tell me how to remove it? Thanks. -- 00:09, 19 April 2011 (UTC)
 * Tag it with delete and an admin will delete it. --   00:16, 19 April 2011 (UTC)


 * Thank you. -- 02:38, 19 April 2011 (UTC)


 * Alternately, with such pages, you could just add a note to the top of the page that you are no longer interested in developing it, but with an offer that if someone else wants to take over, you'll move it to their userspace (or something to that effect). <span style="white-space:nowrap">「」· 03:27, 19 April 2011 (UTC)

New Blocks

 * We need someone capable of editing the templates (that's not so easy) to add these images to their right places: to  and  and  to . Thank you. (sorry if this is in the wrong place, found no better one...) <span style="font-variant: small-caps; border-style: double;"> 17:16, 19 April 2011 (UTC)


 * Thanks for the images! I got the Detector Rail put in the right place. I also got the saplings in after a bit of work.  Feel free to fix what I've done if you have a better way of doing it.  -- 17:19, 19 April 2011 (UTC)
 * We need someone to upload the new spritesheet at Template:BlockSprite. Careful with this; it's easy to break a lot of stuff.  If you post the image somewhere I'll do the rest.  -- 17:41, 19 April 2011 (UTC)
 * Please do not discuss on the portal itself. This discussion belongs at: --    17:50, 19 April 2011 (UTC)
 * Sorry. Thanks Wyn! -- 17:55, 19 April 2011 (UTC)

Power.png
Someone knows what is the file in the armor directory? Was it here before 1.5? –  18:37, 19 April 2011 (UTC)


 * Moved from :
 * Hey I was making a new texture pack when i noticed that there was a new armor texture in the armor file in the bin folder. Its called "Power.png". is this old or is there a new armor coming.
 * Would someone please upload this image somewhere? Thanks.  A thread on the forums claims that it's from when a creeper gets struck by lightning... but no other details were provided.  Man, I'm curious.  -- 18:30, 19 April 2011 (UTC)
 * There's been some discussion. The currently accepted belief is that it's the effect the surrounds a mob that is struck by lightning.  It's probably under "armor" because it surrounds the mob like armor does (from a code standpoint).  -- 19:24, 19 April 2011 (UTC)
 * Seems possible. I had this subject removed from the rain page, as there is no actual evidence. Feel free to put it back there if we get any. We need to find out whether this is just speculation or the real deal. --<span style="font-variant: small-caps; border-style: double;"> 16:26, 20 April 2011 (UTC)

Neutral color default theme to reduce contrast with block images
Shouldn't be too hard to comprehend. A nice neutral color would make all of the light-colored block images (snow, iron block, etc) show up better, and allow dark-colored block images (obsidian) to be discernable as more than just a black square. -- 02:33, 20 April 2011 (UTC)

F3
Should f3 have its own page? Because I think none of the pages explain it enough. –The preceding unsigned comment was added by ( . Please sign your posts with


 * mentions it. -- 19:42, 20 April 2011 (UTC)

Isometric block images: how are you folks doing it?
I've actually been wondering how these isometric images have been created. Are you guys using a special tool? Some sort of fancy algorithm? Burma Shave? -- 22:14, 20 April 2011 (UTC)
 * Blender, orthographic camera. – ( at 01:49, 21 April 2011 (UTC)
 * Fair enough. -- 01:56, 21 April 2011 (UTC)

New discussion system
I'm currently in the process of coding a forum system, to make discussions easier to find and take part in. Unless anyone has any objections, I'll put it into effect later. —   13:06, 21 April 2011 (UTC)
 * We already have one. – ( at 13:18, 21 April 2011 (UTC)
 * I mean one specially for discussing wiki content, like page deletions, usergroup changes, and substantial changes to how the wiki is run. —   13:35, 21 April 2011 (UTC)
 * That's what this page is for. If you really need a forum, you can use the one above. – ( at 14:34, 21 April 2011 (UTC)
 * Sort of the point, it's to replace this. Those with slower connections will have problems loading this huge talk page, whereas making individual pages for discussions eliminates the need to do that. The idea would be to have a main page as a directory for active discussions, and then link to discussions from there. Have a look at Harry Potter Wiki's Wizengamot for an example of how it would work. 16:17, 21 April 2011 (UTC)
 * Or just archive more often? And currently, if something really needed to be separate, there are . -- 16:34, 21 April 2011 (UTC)
 * When several discussions are still ongoing, especially when they are high-traffic, you can't fix that by archiving. I can see far more good than harm coming from this. What negatives would a less cluttered discussion system bring?  16:48, 21 April 2011 (UTC)
 * Off the top of my head: watchlists. And generally, there aren't numerous, large discussions going on simultaneously, and at that point they are either going in circles or need to be moved somewhere else. -- 16:57, 21 April 2011 (UTC)-- 16:57, 21 April 2011 (UTC)
 * I'm sorry, you forgot to give a reason why this harms the wiki. 17:08, 21 April 2011 (UTC)
 * You are aware of what watchlists are, right? Well, in case you don't, it is a single page where you can get updates for pages you watch, in this case, the community portal. Splitting up new topics won't trigger the watchlist, so users who are involved but don't stalk RC won't be informed. -- 17:14, 21 April 2011 (UTC)

I know precisely how a watchlist works. Don't treat me like an idiot. Did you not consider that you could follow the individual topics in a watchlist? Or did you completely ignore the link to HPW's system above, and just baselessly oppose? 18:06, 21 April 2011 (UTC)
 * "Splitting up new topics won't trigger the watchlist" should have been "splitting up/adding new topics..." but the point still stands. also, fuck wikia. -- 18:26, 21 April 2011 (UTC)
 * So you're opposing because a Wikia site does the same thing? Great reasoning. FYI the main directory would show whether topics had changed recently, as well as the last user to edit it, so it would just be a reorganisation to make it easier for older computers, and would barely affect newer ones - it's just a new link to put in the sidebar. 1 click to see whether anything changed. —    18:35, 21 April 2011 (UTC)
 * No, I'm opposing it b/c this is a wiki, not a forum. We already have an associated forum and tools we can use to keep this page manageable. -- 18:43, 21 April 2011 (UTC)
 * You didn't read the comments before you joined this discussion. The new system would be for wiki content, like page deletions, usergroup changes, and substantial changes to how the wiki is run. NOT for general Minecraft discussion. Keep this page for people asking about the system requirements, whether locked chests can be used, and the height of pigs. Move real discussion, like allowing unregistered users to edit, and whether to allow templated signatures or not, to the new system. Hope that got through to you. 20:50, 21 April 2011 (UTC)
 * Page deletion discussions occur on those pages or project pages for wide-scale deletion or are simply handled through the category. Usergroup changes can be brought up at the admin noticeboard or here (they're infrequent enough). And big changes to the wiki should be run by the most people: here. I do see a little of what you're getting at; this wiki could use a "Ask wiki/game questions" page, but it doesn't need a forum-like system. -- 21:09, 21 April 2011 (UTC)
 * I see your point on page deletions, that can be kept separate. BUT. Wouldn't it make more sense to have all the major discussions in one place? That way, there's one place to see all changes, without needing to go through several different pages. By the way, watchlist won't always help, as it shows the latest change, there's no way of telling if a certain topic has been changed before the last edit. 21:16, 21 April 2011 (UTC)
 * Wait, do you want to retain this page as is and move the "height of pigs" questions to another page? And you can actually see all the changes in your watchlist if you use the expanded watchlist under your preferences. -- 21:21, 21 April 2011 (UTC)
 * Sigh. This would be the page for height of pigs. Serious business would fall into the new thread system. 21:26, 21 April 2011 (UTC)
 * Ok, "all the major discussions in one place" confused me, since a thread system doesn't seem like "one place". I still think having an additional page for "height of pigs"-like questions would alleviate some of this page's content. However, at this point, we need more community involvement. -- 21:28, 21 April 2011 (UTC)
 * They would be monitored in one place, by a watchlist-style system showing threads which had changes since the user's last view. We may not be getting much traffic here because this is not the easiest page to find, whereas linking to the new discussion hub in the sidebar could draw people towards it. 21:38, 21 April 2011 (UTC)

While we do need more archiving (maybe get a bot for this or something?) your argument "Those with slower connections will have problems loading this huge talk page" is hardly valid unless you got a wooden modem of some sorts. This page, for example, is barely 45 kilobytes big. And I doubt a forum system would be smaller in filesize, if not bigger. Either way, I really just don't see why we shouldn't keep using this. Talkpages work fine and I have no issue working with them, and I doubt many others don't. Archiving is something that should be looked at, nothing more.-- -  MCWiki Administrator  21:42, 21 April 2011 (UTC)
 * Topics should be discussed on the relative article talk page especially discussions regarding a page deletion. This is not a system we are interested in, nor is it one that will be supported here. As has been mentioned several times, we have a forum, with a wiki specific section, and we have the wiki itself. And no, I dont' believe that all the major discussions in one place is a very good model for a wiki. That's just not how wiki's work. There is a reason that each article has it's own talk page. If you have a topic you wish to draw more attention to simply link it on the Community portal, either under Hot discussions, or Requests for comment. This community is large, and people have varied areas of interest. They pay attention to those areas, and that is how it should be. For the record, Curse will not support any additional "forum" system. You are welcome to use the forum's already in place as linked above, or you can use the wiki as it's intended to be used. --   22:45, 21 April 2011 (UTC)
 * When I said coding, I meant I was designing one. It would be a network of pages on-site, not PHP. I should have been clearer on that. Still, it really wouldn't hurt just to click the example link I provided, just to see what it would be like. Or perhaps you're just reluctant to change. In case you can't see the link, it's HERE. 13:02, 22 April 2011 (UTC)

pictures
I'm still pretty new too the wiki, and i have some pictures i might like to add and im confused of how to do it you do this

then what!?!?--"_"oyster"_" 16:56, 21 April 2011 (UTC)

nvm answered It myself :D --"_"oyster"_" 16:56, 21 April 2011 (UTC)

Remove 3-day wait from Autoconfirmed requirements
I have absolutely no idea why that's a requirement. Surely providing a legitimate email and confirming it would prove you're not a bot? Plus, this inhibits new users -
 * A new user may find something ingame that's article-worthy. If they can't make an article about it, they're probably going to hold onto that information until they can add it themselves, and take credit for it. In those 3 days, thousands of readers could have benefitted from it.
 * Redlinks are scattered all over the place where users can't create a userpage, and there's no need for them.
 * Some experienced users ingame may wish to add tutorials to the wiki. Sadly, they can't, and autoconfirmed users would have to act as proxies for them, which is an inconvenience for both parties.
 * New translators can't add information in other languages for 3 days. 3 days wasted sitting around doing nothing, which could've been spent completing translations and clearing the.
 * If people want to add pages, they probably won't want to wait 3 days to do it, preferring to get it done soon as possible, and going to a different wiki, without a 3 day wait for the CreatePage right, costing this wiki contributors (which are not as numerous as they could be, thanks to the block on all anonymous users)
 * If a 1-day old user wants to use their signature from another wiki, they can't, without adding code to the page. (I am well aware of the discussion regarding this, but have a look here for the amount of code some people may want for their signature.)
 * Assuming anyone creating an account is going to jump in with spampage creation is horribly bad-faith. I know this isn't Wikipedia, but WP:FAITH is a brilliant rule, and I think it should be applied here too.

Discussion
Support - As nominator. 21:03, 21 April 2011 (UTC)
 * Part of the issue is the balance between getting more content and getting more contributors that fit. The later is relatively easy to get, but the former is harder; getting users that understand what's going on around here and the rules and are invested in the site is not easy. The 3 day period helps to promote that. Given that, I don't strongly care either way. -- 21:38, 21 April 2011 (UTC)
 * Unfortunately providing an email address is simply not enough. We experienced I fairly high number of new users registering only to create spam pages linking to all sorts of nonsense. The waiting period allows new users to make other contributions to existing articles (which is also a requirement for gaining autoconfirmed status). If a user is committed to contribute to a translation project, there are many pages in all of them that have been started that they can contribute to. As for userpages... those weren't being created before this change was made, I don't see it as a huge issue. As for that signature, it would not be allowed regardless since we do not allow the use of non subst signature templates. Bottom line, I don't see this being changed any time soon. --   22:24, 21 April 2011 (UTC)
 * Unfortunately providing an email address is simply not enough...
 * A spammer will not go to the trouble of creating multiple email accounts just to vandalise a wiki, and have it removed in seconds.
 * ...we experienced a fairly high number of new users registering only to create spam pages linking to all sorts of nonsense...
 * That's those users. Not everyone. There's always some bad apples, but the basket is mostly fresh and healthy.
 * ...the waiting period allows new users to make other contributions to existing articles (which is also a requirement for gaining autoconfirmed status)...
 * Finding 10 articles needing an edit takes longer than you may expect. Spammers won't go to that trouble, just to make an easily-deleted page. If you don't have enough active sysops to watch RC and deal with that, you need to appoint more ASAP.
 * ''...if a user is committed to contribute to a translation project, there are many pages in all of them that have been started that they can contribute to...
 * says that out of the first 50 redlinks, 43 of them are to foreign language articles. Apparently more translators are needed.
 * ...as for that signature, it would not be allowed regardless since we do not allow the use of non subst signature templates...
 * So you don't mind me adding 42 lines of code every time I edit a discussion? OK then.
 * Bottom line, I don't see this being changed any time soon.
 * K, it's your opinion. Just suggesting a helpful change. 10:23, 22 April 2011 (UTC)
 * There is nothing saying that you have to find 10 different articles to edit, and as stated before, there are plenty of pages that are in the being translated stages that willing translators can work on that will at the same time meet their 10 edit requirement while they wait the 3 days. The signature issue is pretty much a no brainer... 42 lines of code for a signature will not be allowed. I'm sorry I did not make that clear in either my earlier post, or in my comments on Darkid's talk page. Should you try, you will find your editing privileges suspended. And while, yes, you may see this as simply my opinion, in some matters, my opinion is the one that counts. --   10:38, 22 April 2011 (UTC)
 * Your opinion counts, but mine doesn't? That's a pretty bad policy to go by. 11:40, 22 April 2011 (UTC)
 * If non-subst-templates aren't allowed, then you can't have your desired sig. Tough luck. And only 43 wanted foreign language articles? Seems low. But that means that there are a lot more that can be improved first. But that ultimately goes back to easing people into the wiki. -- 12:30, 22 April 2011 (UTC)
 * I'm not bitching about not being allowed the signature, I'm pointing out that Wynthyst seems to think being Curse staff makes him better than me. Also, if you could read, you would see that I said 43 out of the first 50 wanted pages. Not 43 wanted translations total. 12:57, 22 April 2011 (UTC)

On a side note, Wynthyst, we should probably add the requirement to the page that appears when trying to create a new page/upload a new file before meeting the requirements. Helps minimizing the amount of people asking on IRC and talkpages.-- -  MCWiki Administrator  12:13, 22 April 2011 (UTC)
 * Real Not Pure, I'm sorry if you think my approach is heavy handed, but there are some things that are determined by server issues where the general community can have opinions, but will have little impact on the end result. The spam issues that brought about the change to page creation was a mixture of the two... the community wanted the spam to stop... when 3 out of every 5 new users were creating spam pages. The three day waiting period is a minor inconvenience to someone who really wishes to make positive contributions to the wiki. As for the signatures, the policy against using templates is a server one as the potential server load caused by changes to a signature of a very active user could slow down the entire wiki. The no 42 lines of code in a signature is just common sense, given your signature code would be larger than the majority of the talk pages in their entirety.... Quatro, I will get a note added to that message if you haven't already. --   14:16, 22 April 2011 (UTC)

Mobile!
Hi all!

I'm currently busy making a mobile Minecraft Wiki!

It's still in Beta, but a preview (current status) can be found here!

I'll also add a 'Contact' page so you can mail me about anything. 11:25, 23 April 2011 (UTC)


 * I don't see the point in that, you won't be allowed to use any content from here unless the mobile site is run by Curse. – ( at 12:46, 23 April 2011 (UTC)


 * Is that really true? Because I'd think of it as a fun project to do when I have spare time. 19:59, 23 April 2011 (UTC)


 * Everything on the wiki comes under the Curse ToS unless otherwise stated, so unless what you're doing fits within that then you can't use the content. – ( at 20:28, 23 April 2011 (UTC)


 * Every editor agrees to it every time they click on the Save page button. You can contact DDuncan@curse.com if you have questions. --   20:40, 23 April 2011 (UTC)


 * Good news! DDuncan may be interested in the mobile site. Going with him in discussion over e-mail. 16:32, 25 April 2011 (UTC)

Issue with snow pages
So we have the information about the snow weather affect kind of split up between, and. Ideally, I'd like to have all information about the weather affect on Snow and all information about the old winter mode limited to the winter mode page. However, this brings up the issue of page naming.

I can't move the information about the snow block modifier to as that is about the full block of snow, I could move it to  but that seems to break off a bit from the naming scheme, as the snowfall block is technically just a non-solid block which changes the side textures of any grass blocks it's on and probably shouldn't be called a "Modifier".

The best resolve I can think of is to have information about the weather on, but I'd like people's ideas and opinions on the idea before taking any action. – ( at 05:43, 25 April 2011 (UTC)


 * Not really part of the subject, but als about weather pages: Isn't it a little stupid we have a redirect page? It's about the same phenomenon (which redirects to ) and it isn't very useful to type a slash (unlees you're looking for a translation page of course).  16:35, 25 April 2011 (UTC)

New Category? Canceled Plans
Some ideas were speculated to be placed in by the developers, but were later chosen not to. Crying Obsidian and the Arrow Quiver are prime examples of these. I see that people want to delete them, but to me, as a new (less than one week) Minecraft player, knowing about these additions and removals is valuable. As such, why not place them into a new category possibly called Canceled Plans. Personally I dislike the name of the category, but cannot think of a better one right now, but the existence of a category for such articles would assist in the encyclopedic quality of the wiki. -- 01:32, 26 April 2011 (UTC)


 * I thought we already had one called 'Removed'? If the ideas were not implemented, as such not added, then they must have been removed. Isn't that logical? -- 04:08, 26 April 2011 (UTC)


 * Alright, that category looks like it will work, but since it wasn't linked on the pages I was thinking about, I couldn't find it. "Removed" has quivers which were only in there as a sprite.  As such, why are pages being requested for deletion if this category exists?


 * And I notice that the Quiver is in both "Removed" and "Removed Items". Should it only be in "Removed Items"?.  Or should all the mobs in "Removed Mobs" also be in "Removed"?


 * -- 05:00, 26 April 2011 (UTC)


 * Maybe some troll made these confusing 'removed' templates. I suggest one simple 'removed' template. -- 11:28, 27 April 2011 (UTC)


 * I would doubt a troll would make a more specific category. I say the categories be kept, and to have themselves be subcategories of Removed.  But maybe there aren't enough removed features for that to be needed yet. -- 13:48, 27 April 2011 (UTC)


 * They're up for deletion because we don't need an entire article on 1 removed item. I agree with this and suggest we move all removed items to one 'removed items' page. -- 21:25, 28 April 2011 (UTC)

New icons for the main page
Hi! I just made some new icons we are using on the french wiki:. What about using them here too? Here is the icon pack: MCWikiIcons.zip -- 09:24, 30 April 2011 (UTC)