Talkpage archives
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)
- 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. --Wookieking9 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 Tools, ie. One animated grid? The more I think about it though, it starts to feel too complicated. JaffaCakeLover 12:54, 19 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. --Wookieking9 02:27, 16 March 2011 (UTC)
- I agree completely, as long as its done right. TTorres896 02:17, 2 March 2011 (UTC)
- Different items need different articles, so concur. - Cilibinarii 13:34, 6 February 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 concur. --Gnu32 09:40, 28 January 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|C) 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
talk 23:39, 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
- 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|C) at 00:53, 4 March 2011 (UTC)
- That was a joke. –ultradude25 (T|C) 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)
- 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. ANNOYING 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). SellymeTalk 13:48, 10 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. ANNOYING 23:39, 7 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)
- 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)
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.--TalkpageEl_Nazgir 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. -- Wynthyst
talk 01:34, 19 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
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)
- It can be added as long as it's tagged properly as is Trap Block. -- Wynthyst
- "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)
- I'd say no, don't speculate; wait until shelves are actually added. Fischertechniklas 06:21, 5 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
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. ANNOYING 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
talk 23:28, 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
- 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
talk 23:52, 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
- 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
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. ANNOYING 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
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
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)
- Agree 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) - Agree –ultradude25 (T|C) at 00:55, 13 March 2011 (UTC)
- Agree 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)
- Agree -- Ephemeris 02:49, 15 March 2011 (UTC)
- Agree MoonBeans (u-t-c) 14:38, 15 March 2011 (UTC)
- Agree 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." --Jonnay 22:03, 15 March 2011 (UTC)
- Agree Domi Digger 20:54, 17 March 2011 (UTC)
- Agree 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. — Scythe 3:39, 19 Mar 2011 (UTC)
- Agree 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.
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.--Quatroking - MCWiki Administrator 08:57, 21 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#Blast_Resistance 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#Blocks_by_hardness, 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#Blast Resistance aswell. I don't really think you need anything else. –ultradude25 (T|C) 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: <onlyinclude>{{ {{{1|Block}}} | light=blah | tntres=blah | ... }}</onlyinclude>. 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)
- 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)
- 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
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#Transcluding_block_pages, 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|C) 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#Blocks_by_hardness 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)
- 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#Blocks_by_hardness 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
Header Tabs
If you don't know what header tabs are, head here. 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 <headertabs/> 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 (u-t-c) 14:28, 15 March 2011 (UTC)
- Oops, heres a link; [1]
- 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. -- Wynthyst
talk 19:03, 15 March 2011 (UTC)
- Disagree Domi Digger 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.--7cardca 23:29, 15 March 2011 (UTC)7cardcha
- Those will all be resolved by the various translations projects 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. -- Wynthyst
talk 07:33, 16 March 2011 (UTC)
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 Unillogical (Talk|Contribs) 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? – Scaler (t) 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. -- Wynthyst
talk 00:02, 19 March 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. JaffaCakeLover 12:50, 19 March 2011 (UTC)
- Why would we want a blurrier version of our current favicon? –ultradude25 (T|C) 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?