Minecraft Wiki talk:Community portal

This is the community's main discussion page. Talk about just anything here!

 Talkpage archives
 * July - Oct 2010
 * Nov - Dec 2010
 * Jan - Feb 2011

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?--Quatroking - Garble Garble! 21:45, 13 January 2011 (UTC)
 * I would support this move, as one of the people keeping an eye on the Wool Page. -St. Fenix (User•Talk) 16:46, 15 January 2011 (UTC)
 * I concur. --Gnu32 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. --Miner Key 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.--Kizzycocoa 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.-- RockBreaker 10: 03, 04 February 2011 (UTC)
 * Different items need different articles, so concur. - Cilibinarii 13:34, 6 February 2011 (UTC)
 * I agree completely, as long as its done right. TTorres896 02:17, 2 March 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 preferences 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.--Quatroking -  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. – ultradude25 ( T 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. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  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. --JonTheMon 00:49, 4 March 2011 (UTC)


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


 * All captchas have been broken by bots. I prefer the forced preview. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  05:49, 4 March 2011 (UTC)


 * That was a joke. – ultradude25 ( T 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. IKJames 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. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  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. --Gnu32 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. Fischertechniklas 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. Drenay 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.  A 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). Sellyme Talk 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. D0sboots 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. Drenay 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) 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 01:40, 14 March 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 Shelf now? That Canadian Guy 05:00, 5 March 2011 (UTC)
 * I'd say no, don't speculate; wait until shelves are actually added. Fischertechniklas 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. ;) That Canadian Guy 06:32, 5 March 2011 (UTC)
 * It can be added as long as it's tagged properly as is Trap Block. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  06:50, 5 March 2011 (UTC)
 * Well I didn't create these pages... I still think speculation should be kept to the forums. Fischertechniklas 12:56, 7 March 2011 (UTC)

Ideas for Minecraft
I love minecraft but I think that there should be much more features. Here are a few i can think of that are MUSTS:

- Repairing tools (eg. to repair a stone pickaxe it costs 1 cobble stone next to the broken pickaxe in crafting rather than totally breaking it)

- Spotlights (used to burn zombies and skeletons using reflection of a torch ect)

- Different types of bows (eg normal dsoes 1 damage, oak does 2 damage, finch does 3 damage whatever)

- MORE MELEE WEAPONS! Such as daggers and katanas

- Much more ore types such as tin, silver, emerald etc+ there should be much more iron and coal, I have only received 5 ores of iron from a 20x20x30 quarry (complete).

- Customisable clothing

- shields what regenerate damage over time - poison arrows

- Include Lapis Lazuli ore (or whateer it is) as a metal to make armor

- More monsters, such as tank zombies, zombies in carts, warlocks. wizards etc.

- Perhaps an evolving age (maybe 100 days in you research guns, 200 days you resarch hand grenades, 300 days you research cars and vehicles etc)

I know most of these are very hard to make but they are pretty much musts. R0cketor 21:43, 5 March 2011 (UTC)


 * This is not a "Suggestion" page. The forums are a more appropriate place for this kind of thing. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  00:05, 6 March 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)? -Wulfenbach (not on fire for once) 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 MediaWiki:Welcomecreation 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.  A 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?--Quatroking -  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. -Wulfenbach (not on fire for once) 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 Recent Changes log, 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. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  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 here) 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. --Gnu32 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..... -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  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 (Welcome), and I'll be copy-pasting this to the talk page there for reference reasons. -Wulfenbach (not on fire for once) 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). Tyteen4a03 13:30, 9 March 2011 (UTC)
 * Already started Minecraft Wiki:Projects/Chinese translation -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  13:36, 9 March 2011 (UTC)

Oh, I'm sorry. Gonna remove this in the RFC section now. Tyteen4a03 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 Hidan Santai 02:37, 10 March 2011 (UTC)
 * here 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.  A NNOYING  10:32, 10 March 2011 (UTC)

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. Drenay 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. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  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 Mod and Tutorial 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.--Quatroking -  MCWiki Administrator  22:47, 12 March 2011 (UTC)
 * I would support this idea for all pages except mod pages :D -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  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. -Wulfenbach (not on fire for once) 23:33, 12 March 2011 (UTC)


 * – ultradude25 ( T 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. Drenay 00:33, 14 March 2011 (UTC)
 * -- Ephemeris 02:49, 15 March 2011 (UTC)

Consolidating block information in one place
I've created Template:Blast Resistance Values and Template:Hardness Values to hold data that is defined for every block, but used in multiple places. For instance Template:Blast Resistance Values is used in Template:Block to fetch the Blast Resistance for the block, but its also used in Explosion 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 Digging, 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. D0sboots 08:34, 13 March 2011 (UTC)


 * I've added an edit button to the block template that links to Template:Blast Resistance Values and I'll add a link on Explosion aswell. I don't really think you need anything else. – ultradude25  ( T 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 Template:Block 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 Template:Get tntres 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! D0sboots 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. --JonTheMon 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. D0sboots 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? -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  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. :) D0sboots 00:26, 14 March 2011 (UTC)

I've also added a note to Template_talk:Block, 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 Template:Block, I think it's pretty easy-to-use but of course I'm biased. :) D0sboots 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 Yu-Gi-Oh! Wikia relies heavily on SMW; Dark Magician, Storm of Ragnarok, and Illegal 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 ;) ). 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 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. D0sboots 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)). ;) 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 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. – ultradude25 ( T 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 Digging 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. D0sboots 03:56, 14 March 2011 (UTC)