Minecraft Wiki talk:Community portal

This is the community's main discussion page.
Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.

Error in emails

When admins delete pages, why does the email that a user receives usually say this page has been created, when it has in fact been deleted? -- Numbermaniac - T - C 06:58, 31 March 2013 (UTC)

Because the majority of deleted pages are deleted soon after creation. The e-mail was sent before it was deleted, but you didn't read it until after. –ultradude25 ᐸ Talk
Contribs 07:55, 31 March 2013 (UTC)

It definitely isn't that. Multiple times, I have been online when I got an email saying it has been deleted. Sometimes pages have been there for days, such as Talk:OCELOT, before it was deleted. -- Numbermaniac - T - C 10:26, 31 March 2013 (UTC)

Dunno then. I don't use emails. –ultradude25 ᐸ Talk
Contribs 12:56, 31 March 2013 (UTC)

That's alright. It also applies to my own user pages. Hower64 kindly deleted 4 user pages I didn't need, and it said that he created them, when he in fact deleted them. Should I perhaps ask Wynthust? -- Numbermaniac - T - C 00:22, 1 April 2013 (UTC)

Mobile version of the wiki

Just wondering, is it possible to use a mobile version of this wiki, just like Wikipedia? // Spitz (Talk) 17:14, 2 April 2013 (UTC)

To get a mobile site, we'd have to install MobileFrontend. The current version of that extension requires a newer version of mediawiki than we're using, so unless we could find an old version lying around, it's impossible until we can update. –ultradude25 ᐸ Talk
Contribs 17:47, 2 April 2013 (UTC)

Okay, thanks for the quick reply! // Spitz (Talk) 18:01, 2 April 2013 (UTC)

This wiki has version 1.18.6 of MediaWiki, and apparently there is a version for 1.17.5 and 1.18, called MobileFrontend 0.5.77. But I never really clicked on the link, or anything like that. -- Numbermaniac - T - C 02:38, 3 April 2013 (UTC)

We are in the process of migrating our wiki network to our Gamepedia platform. I anticipate MCW will be the last wiki to migrate, and hopefully we will have this all done by the end of June (no promises...). At that time, the Mobile Frontend will be available. -- Wynthyst talk 11:46, 3 April 2013 (UTC)

Great! I'll be looking forward to it! // Spitz (Talk) 20:08, 3 April 2013 (UTC)

That would be brilliant! When it is changed to the Gamepedia platform, will our accounts be moved there as well? -- Numbermaniac - T - C 01:32, 4 April 2013 (UTC)

Makeover Time!

Hey guys,

I think it is time for Minecraft Wiki to lose the current look and get some serious cosmetic changes. We have some really smart people in this community, lets have a contest to see who can create the best proto-type website. Then we can bribe... uh... I mean ask (:-P) ultradude and his pals to accept it! SpamTheClicker 01:32, 4 April 2013 (UTC)

Platform differences

Is there a style guide for how to explain platform differences in articles? For example, every time we talk about right-clicking on something should we parenthetically describe what to do in the xbox or PE versions too? Or is the PC version considered the primary version and other platforms describe their differences in sections after the main article? It seems a little haphazard at the moment. —Munin295 · · 07:16, 4 April 2013 (UTC)

wither skeletons

Why dont Wither skeletons ever spawn in the Overworld? 70.181.68.226 14:32, 10 April 2013 (UTC)

This page is for talking about the wiki (articles, templates, conventions, etc.). Use the forums to talk about Minecraft. —Munin295 · · 17:41, 10 April 2013 (UTC)

Watching subpages?

When you place a page on your watch list, does that automatically watch all subpages of that page? -- Numbermaniac - T - C 01:55, 14 April 2013 (UTC)

No, but watching a page automatically watches its talk page and vice-versa. —Kanegasi ☺C 01:56, 14 April 2013 (UTC)

That was a fast reply. Anyway, interesting... Your talk page is on my watchlist, and when you created archive2 of your talk page, I actually got an email for that. Weird. -- Numbermaniac - T - C 02:02, 14 April 2013 (UTC)

That's because I moved my talk page instead of just copy/pasting. When one of your watched pages is moved, the new page is automatically watched. I did what is called a "history split" where I delete a page, restore only the revisions I want to move, move suppressing a redirect, then restore the rest of the page where it was. Also, my reply was fast because when I'm on the wiki or generally browsing the Internet, my windows are arranged so that I see the minecraftwikichanges channel. I see things as they happen here. —Kanegasi ☺C 02:10, 14 April 2013 (UTC)

Oh. What do you mean by minecraftwiki changes channel? Just the recent changes? Or something else? -- Numbermaniac - T - C 02:33, 14 April 2013 (UTC)

Minecraft Wiki:IRC —Kanegasi ☺C 02:34, 14 April 2013 (UTC)

Tutorials Page

I was thinking the tutorials Page was a bit off, and that it could do with a couple of tables, like I did here, even tho its incomplete at the moment. Does anyone have any comments on it? --Extreme 04:05, 21 April 2013 (UTC)

The headers look good, but I'm not wild about that centering of the titles. --Mental Mouse 15:19, 21 April 2013 (UTC)

Minecraft Creative Fly Speed

HOW TO WORK OUT HOW FAST YOU FLY IN MINECRAFT Hey there after mucking around with a redstone repeater circuit and flying above the redtsone current i found that i was flying at the exact same speed as the current. all the repeaters had just the default 1 tick delay and after a little research someone had said that 1 redstone tick equals one tenth of a second delay in other words ten ticks equals a second.and as a redstone repeater covers 1 block that means the current travels at 10 blocks per second. if this is correct then that means we travel at 10 blocks per second aswell. i did a little more research after this and found that 1 block is 1x1x1 meters. so that means the current is travelling 10 meters per second and that means we fly at 10 meters per second aka 36 km/hour. WOW. buuut... if we travel 10 meters per second whilst flying and we fly 100 meters we would do it in 10 seconds fast right. but usain bolt can SPRINT it in 9.58 seconds... so in conclusion usain bolt is the fastest person on earth and in the minecraft world to.. disapointing isnt it we still are those nerds that arnt quite the fastest...

SPEED minecraft flying speed is 1 meter per 0.1 seconds = 10 meters per second = 100 meters per 10 seconds = 36 km per hour

CONCLUSION USAIN BOLT IS STILL FASTER!!!!

--TheDwarvenJaffa 13:50, 26 April 2013 (UTC)TheDwarvenJaffa--TheDwarvenJaffa 13:50, 26 April 2013 (UTC)

Interesting result. However, this would be better if you put it on the talk page for flying. -Creepers explode, don'tcha know? 15:41, 26 April 2013 (UTC)

minecraft P.E

i'm wondering in the update to come version 6.2 you know how it says you will need a mojang account does this mean we will need a account like the one you buy to get minecraft on the P.C what i mean is will we need to buy a account or will we get one because we already bought the game please coment or add or whatever this is my first topic (sorry if this is hard to read some times i am a messy writer)if you can help thx Liamperry10 12:09, 1 May 2013 (UTC)

I am not entirely sure, but Mojang accounts are free. You can register accounts for free, but getting Minecraft for the computer will cost about $26.95 USD. -- Numbermaniac - T - C 06:32, 2 May 2013 (UTC)

As far as I know, you don't need to pay for an account on Pocket Edition of Minecraft. The game itself, yes. Account, no. -Creepers explode, don'tcha know? 21:59, 8 May 2013 (UTC)

Delete page

I think this page should be deleted. It's orphan and talks about almost 4-years-old things. Useless page.--94.101.51.28 14:55, 2 May 2013 (UTC)

No, we don't delete things just because they are old. If it is no long an available feature in the game, it should be marked as historical content. -- Wynthyst talk 18:06, 2 May 2013 (UTC)

Wiki Server issues

You may have noticed occasional outages on the wiki. We have identified the cause of a lot of these blips in service to be the editing of Template:Blocks, Template:Items and all the sprite templates, and others that go along with them. Each time any one of the templates involved in these two nav boxes gets edited, it creates such a spike on serverload that it destabilizes the server for just long enough to create a service blip. We need to find an alternative solution. My current suggestion is to remove the images from the nav boxes completely. Are they really necessary given the consequences of keeping them? Or... is there some other way we can break those templates into smaller chunks so that changes would not create such a widespread impact? -- Wynthyst talk 18:06, 2 May 2013 (UTC)

whatever is done, I'd strongly vote against removing the images.

as a user of the wiki, I do not really read the template. I find the image, and click it.

I believe, due to the vast amount of blocks in Minecraft, that these templates would suffer greatly if the images were removed, and that we should look for an alternate solution.

that said, which templates are causing issues, exactly? how severe are the outages? is it only when they're all edited, like during a new update? or can a single template edit do it? is there any way to ease the strain through other means, like locking the pages? --Kizzycocoa 19:30, 2 May 2013 (UTC)

We do not believe removing sprites is a solution of the issue as some other complex templates that do not include images still create major lag spikes for MediaWiki while being edited. This would also remove part of usefulness of navboxes, part of their illustrative abilities. How long actually wiki doesn't work on editing? On ru. section we experience downtime of about a minute, that doesn't hurt much. And once again, Wynthyst, please, look into issue with image revert. Sincerely, ru.wiki team. Norrius 19:32, 2 May 2013 (UTC)

I would probably use the search function before I tried to read through a navbox without images. What if the content of the navboxes were not automatically loaded, but could be loaded with a LoadPage mechanic? (not necessarily that template, just something like it) Changes would then propagate to very few pages, but a load request would be pretty quick for users, I think (one or two seconds). —Munin295 · · 19:58, 2 May 2013 (UTC)

LoadPage makes it easier for server to handle editing, but every user request to the template would be followed by delay of several seconds. Minute (am I right? or it is half an hour?) downtime once when editing template or tiny but still annoying delay every time when using template? Norrius - ru.Wiki Admin 20:19, 2 May 2013 (UTC)

Us admins have been discussing the practicality of this issue, as opposed to the functionality of the template. so, I'll translate the IT department's issues here.

1)the wiki is experiencing a few seconds downtime every time these navboxes get updated. even if it's just to fix a typo
2)the templates are on many, many pages. when one is updated, all the pages using the template are automatically rewritten. this causes the downtime. (every single in-game block's page use the block template. that's 364 pages, and they all need to be rewritten every time someone edits template:blocks!)
3)this automatically sends an email to the Curse IT department. they're complaining due to the volume of times this is edited.
4)the size of the templates are very large.
5)this can be a serious vandalism concern. if a vandal came in and added 50 images to the template, the wiki would crash. no ifs, no buts. it would just, die, and may take down other parts of Curse with it. it could be a large disaster.

So, there are a few options on the table at the moment.
1)we remove the images. this solves issues 1, 2, 3 and 4
2)we split the templates (blocks would become "natural", "manufactured", "ore" etc). this would solve all 5 issues, but would make ease of use
slightly worse. we can keep the large templates for the overview pages, such as the Blocks page.
3)we get another option. Munin295 suggested some "loadpage" option. no idea how it'd work, but it's worth discussing.

The template will most likely be changed. there's no other way we can see to fix this. either we inconvenience users by removing images, or we keep the images, but cut down on the content so the general catagories (natural, manufactured, ore etc) are templates. this means on an ore page, the template would only contain ores. on a redstone page, only redstone etc.

as said before, if we were to remove the images, we would lose most of the functionality. but if we split them, we lose the ability to do any "wikihopping" (like how you get from "cats" to "motorbikes" purely by related links).
Thoughts on this? any other solutions you could offer? --Kizzycocoa 20:26, 2 May 2013 (UTC)

Something that I have yet to understand about using bits of one image, like the CSS images these templates use, is the image loaded once and positioned accordingly, or are these templates loading the image for every single icon? If the latter, I would like to think MW is reloading every icon when a template edit occurs and is re-parsing the image several times per page for the tons of pages it's on due to an edit causing a reload of the css code it uses from the sprite position template. We already have grid images for everything, would using a separate image for each icon help? If my assumption of MW's internal workings is correct, it shouldn't re-parse each individual image for a template change.

If I'm completely wrong, and just the fact that it's a large template is the issue, I agree with Kizzycocoa's suggestion we split the templates into the sections it already has, like a Template:Manufactured, Template:Natural, etc. It is also possible to maintain "wikihopping" since a few blocks and items would fit in more than one of these separate categories, we just keep them in one category since listing them more than once in one template is pointless. —Kanegasi ☺C 20:34, 2 May 2013 (UTC)

we used to do just that. the fact that a browser had to access 50+ images at once brought the MCwiki servers to it's knees back then. if we undid our decision to do CSS trickery, we'd be in a much worse place :P --Kizzycocoa 20:38, 2 May 2013 (UTC)

Issue 5: Isn't this why all these templates are fully protected? And are these measures worth it? The images are critical to templates because they are navigation templates, and images allow much better navigation. The pageload thing looks good, but it's few seconds downtime once per template versus ~800 milliseconds on each page load? Is it an "it's better for our server xor it's better for users" kind of choice? And have you even read our previous messages? --GreenStone^(cont) 20:48, 2 May 2013 (UTC)

If you have to make an unnecessary comparison between the people that use a site and the ability for the site to exist for that people, the server always wins. You can't just do everything that's "better for users" and ignore hardware and software limitations. There HAS to be a balance and if the server has issues, those issues have to be rectified. This very discussion is "better for users" since it's discussing the balance we need to strike. Also, the full protection just occurred today. They've been editable by autoconfirmed users for a long time. As for your off-topic mention, that's uncalled for. —Kanegasi ☺C 21:00, 2 May 2013 (UTC)

Then let's remove images from all wiki pages for further optimisation and freeing disk space. Are those few seconds downtime real issue? Only serious problem seems security reasons like vandalizm and general Curse Network stability, and that's what we should think how to solve. The wiki exists not for the server but for users. Norrius - ru.Wiki Admin 21:15, 2 May 2013 (UTC)

The potential for vandalism is far too great in my opinion. if all it takes to cripple the wiki is for a spammer to register an account, then add fifty images to this one template, we need to change this. I personally do not want to see the images go, as they are vital for navigating. that said, we cannot allow this security flaw to stay. I think removing images is reduntant and a non-issue. it would solve the server load issues, but wouldn't solve the dangers of keeping this template untouched. --Kizzycocoa 21:22, 2 May 2013 (UTC)

@Norrius: Normal operations of the wiki, such as images, editing, etc. are easily handled by the server. Disk space is (I assume) not an issue. Optimization is also not the issue. The abnormally large templates are the issue. Because it's a "we need to recover from a stability issue" problem and not a "Curse wants to cut stuff" problem, this isn't a question of will we change things, it's how will we change them. You are correct that the wiki is for users, but you are using that concept incorrectly. Wiki editors exist to better the wiki they edit, which includes everything from a one byte grammar change to ensuring the wiki operates within the limits of its server. If the server has problems, things have to change.

To add to my comment, take Wikipedia's pure donation-fueled existence. If, for some reason, they weren't able to raise their annual cost one year, they would have to sacrifice. Cut on some server costs, change some policies, etc. This is a similar situation. Even though Curse does not run on donations, they are still just as limited as Wikipedia. If they aren't able to provide a super server where we could do anything, then we have to strike a balance, as I stated. The performance of the wiki is just as important as the wiki itself. —Kanegasi ☺C 21:40, 2 May 2013 (UTC)

"few seconds downtime once per template versus ~800 milliseconds on each page load?" -- That extra time would only be added when the user requests it (which will surely result in the navbox content being requested at a tiny fraction of the rate it is now: automatically loaded on hundreds of popular pages). Otherwise the article's load time (and the server's overall load) has been reduced by some similar amount from what it is now. —Munin295 · · 22:13, 2 May 2013 (UTC)

I understand what you want. It's a problem of "making better without making worse", a very serious one due to possible unforeseen consequences. In this case, it's clear that the instability is a serious issue, possibly even critical, however, it must be resolved with minimal losses. You aren't interpreting this discussion as "Lower the server load at all costs!", right? There's the problem, losses have to be minimal, as I stated above. If you cut the templates' images, it may cause less server load, but it will slow user navigation down. And by "user" I do not only mean "editor", but "reader" as well. Is it worth it? Are there no other solutions? Pageload seems a valid solution now: the only inconvenience caused is slowdown when opening these templates. However, there may be a better solution, problems with pageload... It's clear that more experienced users should join the discussion. --GreenStone^(cont) 22:16, 2 May 2013 (UTC)

I like the idea of trying the LoadPage mechanism. If these templates aren't transcluded, editing them won't cause hundreds of page rewrites, which should solve the problem. Users can still load the navboxes when they want to, so there's no real loss of functionality. As for implementing this, I think the easiest method would be to move Template:Blocks (etc.) to a new page, then recreate it as a template that loads the actual navbox. That way we won't have to update every block and item page individually. -- Orthotope 01:51, 3 May 2013 (UTC)

I believe the LoadPage template can only be used to create headline elements (h2, h3, etc. -- specifically, anything that gets the .mw-headline class) which probably isn't appropriate for this purpose (thus, mechanism, not template). It would either have to be generalized, or some new javascript written for this purpose. —Munin295 · · 03:16, 3 May 2013 (UTC)

I would expect this to be a null issue once we have lua, but for now I think the page loader would be the best option. We could have a "<Category> navigation" section for each navbox so that the page loader can be used without modification (all that would need to be changed is the navbox pages to have the noinclude class around documentation). To get the page loader to work in the navbox itself would be tricky, since the border that would always be shown is part of the navbox, so the navbox template would need to be modified to only output the border, and then the page loader would either have to remove the frame from the content on loading, or the content would have to be on a separate page to the frame. –ultradude25 ᐸ Talk
Contribs 04:27, 3 May 2013 (UTC)

This is an issue that needs to be resolved. I have checked with our tech team and there is no viable page loader option available to us, so this comes back to modifying the templates. Just to be clear, this is not just about the nav box templates themselves, but also the sprite templates. If you insist that the images must remain in the nav boxes, then both the sprite templates, and the nav templates have to be modified. Breaking them into smaller, more manageable sections, with a sprite image, and display template for each is what it is going to take. This is going to make them much less user friendly to use and edit. I guess I'm not sure what the importance of keeping the images if the nav boxes are smaller, more specific. Bottom line, either the community comes up with a solution that resolves the instability problem, or our tech team will impose limits on the number of pages any single template can be used on. -- Wynthyst talk 16:38, 14 May 2013 (UTC)

I don't understand how the page loader script won't work. The way I understand it is we modify the main template to put in a bunch of page load links and all the content is in separate pages or subpages. This way, the main template doesn't need to be modified for any change or the hundreds of pages it's in doesn't need the template changed and the template itself stays protected. After that, the only reason to edit the template would be to add a new category of blocks/items. Is there a detailed explanation as to why this won't work? —Kanegasi ☺C 17:01, 14 May 2013 (UTC)

(edit conflict) What are you talking about "no viable page loader"? It's right here and we've already got the navbox working with the script without needing any modification to the script or navbox template; we just need to actually apply it to the navbox pages. –ultradude25 ᐸ Talk
Contribs 17:05, 14 May 2013 (UTC)

(double edit conflict) Analyzing structure "navboxSplit":

Possible result output: for example, take items. "Items" will have an item class template at the bottom (by item classes I mean, for instance, food, equipment (armor/weapons/tools)... All class pages will have 2 navigation templates: All Classes and Class Items. All item articles will only have corresponding class templates (may be more than 1 template if the item belongs to multiple classes?)

This will only result in server load decrease if sprites are removed, however, as Wynthyst said, there may be no reason to keep them if the navigation templates are split.

And it's not clear why the page loader won't work.

Analyzing structure "navboxPageLoad":

If the page loader works, this will only lag when templates are loaded: less likely to cause direct server-side issues, if the internal interpretation is correct.

Part of this analysis may be incorrect (reason: conflicting information was provided). --GreenStone (0x54; 0x43) 17:28, 14 May 2013 (UTC)

To my understanding, the loading of the template itself, with the sprites, on normal page viewing is not the issue. There is no noticeable difference in server load if the templates weren't there versus now. The issue is editing the templates. When something transcluded gets edited, the server has to scrap the cache of each page it's transcluded to and rebuild it. Every time someone edits these high use templates, the server hiccups. The load page solution takes the editing problem out and any edits to the content does not affect the template at all, which is why I am stating my confusion that the tech team says it won't work. In fact, my assumption about categories in my last post is wrong. I have not seen the progress that ultradude25 linked to and it's even better than what I thought. Once that is introduced, there will be zero need to edit the actual template and the server blips will go away.

This also has the side effect of essentially having the templates collapsed, shortening some pages. I brought up the suggestion to auto collapse these nav templates when we introduced the redstone template due to the excessive bottom length of some articles, but they used to be that way and someone complained the opposite in the past. This load page solution brings this back, albeit unintentionally. —Kanegasi ☺C 17:41, 14 May 2013 (UTC)

Ok.. I see where this is going, however, it's not the root of the problem. The root of the problem is the fact that each of these templates use a whole bunch of additional templates that are also used in other places and other ways. Template:BlockSprite is used in over 2000 places, so any edit made to this template, parses out 2000+ times, any change to any of the 6 sprite templates that are included in the navbox does the same. So even if the navbox is only loading when someone asks for it, the changes to all the transcluded templates are parsed out with each change to each template. -- Wynthyst talk 04:05, 15 May 2013 (UTC)

Including the translation project articles on www, I wouldn't be surprised if the navboxes' use of BlockSprite accounted for most of that 2000 (english articles with navboxes alone account for about 400 or 20% of that, and there's how many translation articles?). Most of the templates that use BlockSprite look like navboxes, so once their content is offloaded we can take a look at the few others and see if something can be done. Let's get the navbox content offloaded and see where that puts us. —Munin295 · · 06:17, 15 May 2013 (UTC)

Actually, this loadbox configuration will not just knock out the amount of direct transclusions of the main templates, the same will happen with the support templates. The vast majority of the 1619 pages the BlockSprite template is on is indirectly through the navboxes. Orthotope made a suggestion on Template talk:LoadBox#Blocks and Items Template that we should use this method on every navbox template for consistency, but with you bringing attention to the even higher use support templates, using this loadbox method on everything, including the translation templates, may just be a requirement to ensure anything that may need to be edited on a semi-regular basis isn't directly transcluded everywhere. Refitting {{Blocks}} and {{Items}} alone will knock about 700 pages off of BlockSprite's usage.

As an afterthought, while composing this reply, I was wondering why you said over 2000 pages when the current count is 1619. I assumed you were vaguely rounding, but then I realized Orthotope has already converted {{Environment}} and {{Gameplay}}. That's already 400-some pages off BlockSprite's usage. —Kanegasi ☺C 05:36, 15 May 2013 (UTC)

Ok, I'm obviously not grasping the technicalities of this solution, so I'm taking it on faith that you guys do. Since you have already started implementing it, I have asked our sysops team to monitor server performance and alert me to any instabilities caused by any of these templates. If they find none, solution found. If they find some, we will need to revisit this issue. I'm cautiously optimistic since they have not reported any issues while you've started making changes. Good job guys! -- Wynthyst talk 11:02, 17 May 2013 (UTC)

Minecraft 2.0 mentions

I continue to agree with ensuring that no info about this version gets documented outside of its article, but because of the "double trolling" nature of this version, as in joking about some of the jokes and actually adding some things, I would like to propose placing a simple link to Minecraft 2.0 in the see also section of anything that was "introduced" in that version, but then actually added. Since Block of Coal's creation yesterday, there's been at least four reverts of 2.0 info and I think a see also link will be sufficient enough to satisfy people wanting to put down something. —Kanegasi ☺C 11:26, 3 May 2013 (UTC)

That sounds like a great idea! 4 reverts already? Wow. I think it's better you put the link there :D -- Numbermaniac - T - C 11:33, 3 May 2013 (UTC)

That didn't work. --GreenStone (0x54; 0x43) 16:18, 4 May 2013 (UTC)

When I put this topic here, Numbermaniac, I wanted the thoughts of others. If I wanted to put that in already, I would've done it before saying anything. When someone brings up an idea on this page, it's probably a bit controversial. Just add your opinion and don't run off to implement the idea for them. As for the page, I threw in a wikinote. I didn't expect anything to work 100% though. Many visitors have proven that they can somehow type without being able to read. —Kanegasi ☺C 18:31, 4 May 2013 (UTC)

Sorry about that. I guess I was just getting a bit infuriated by the amount of people mentioning Minecraft 2.0. -- Numbermaniac - T - C 02:08, 5 May 2013 (UTC)

 Agreed - Sounds like a good idea. –Goandgoo ᐸ Talk
Contribs
Edit count 04:25, 5 May 2013 (UTC)

Lowered page?

I noticed that the pages of the wiki have been slid down...I cleared my cache, didn't help. Anyone else have this? -Creepers explode, don'tcha know? 16:05, 9 May 2013 (UTC)

I also have some snips of this occuring, if that's helpful. -Creepers explode, don'tcha know? 16:16, 9 May 2013 (UTC)

There's a new box above the article title which is supposed to hold ads (maybe you have an ad-blocking browser extension making it invisible?). You can get rid of it by placing the following in your css style sheet:

div.atflb { display: none !important; }

—Munin295 · · 17:37, 9 May 2013 (UTC)

Thanks! -Creepers explode, don'tcha know? 18:19, 9 May 2013 (UTC)

Item hotbar

Sort of a newb here... Can someone make a template that is a hotbar with items in it you can choose? thanks! Twkkrkt 20:07, 15 May 2013 (UTC)

 Done Template:Hotbar –ultradude25 ᐸ Talk
Contribs 21:39, 15 May 2013 (UTC)

Custom namespaces (requires Curse)

While composing a comment on the style guide talk page, an idea came to me. What if we had some extra namespaces to help clean up some of the big subpage articles we have? I think it wouldn't be a bad idea to make Mod and Tutorial namespaces. Those would be obvious to organize, but what if we go as far as making a Version namespace? Every major version could get an article, not just the named ones, like Version:1.6. For development versions, we could have sections within these "main" version articles that maintain the same table we do on that massive development versions page, but it would also have the official release changes on the same page, and once the official release happens, we could collapse the snapshots. Any history links would point to a snapshot like this: Version:1.6#13w19a and within the article, we could have a basic layout of all the changes in article format along with any relevant social media from Mojang about the version, like the quotes for the snapshots. Now, I'm not sure about the version namespace, even though that idea was pretty interesting to me, but I would love to see a Mod and Tutorial namespace. If anyone is not sure what I mean by custom namespaces, think of the "Forum" namespace on Wowpedia, or the five extra namespaces on Wikipedia. —Kanegasi ☺C 11:22, 18 May 2013 (UTC)

 Disagree The first issue that occurs to me is that it multiplies the places that articles "could be". Already, if a page is in Tutorials, much less a user space, it's significantly more difficult to search for.

More basically, the namespaces represent divisions of wiki function: The Minecraft Wiki space itself (apparently aka Help) for central pages such as the front page and noticeboard, one for MediaWiki (the software we run on), and the main namespace for ordinary topic pages... but then you're on to Template, Category, File, and User. Each represents a basically different type of material, not just a different topic or category. If we had a Forum, that might well qualify for a namespace, but we don't -- and the "extra" namespaces on WP are similarly fundamental divisions of their mission. The closest we have for that is the tutorials, and those naturally blur into the topic articles. The mods are not even close, and few mods have enough editors to even finish their own pages. And versions are a small and specific topic -- we totally don't want people doing separate copies of item or mob pages for every version! --Mental Mouse 20:13, 18 May 2013 (UTC)

I personally disagree with Mental Mouse, as I see namespace functionality differently. I agree a Tutorial and Mod namespace would not be a bad idea, especially the Mod namespace. The Mainspace is for articles documenting the vanilla Minecraft as it actually exists, so while the argument could be made that Tutorials fall loosely into that area, Mods are definitely outside it. We did have a discussion when Curse initially took over the wiki whether it was something we wanted to do, and at that time, it was decided to simply have a strict naming convention for Mod pages. If there is enough belief that we have outgrown that method, then a custom namespace would be the way to go. As for searching, we simply set the new namespaces as part of all initial searches (not having to specify it in Advanced Search). Either way, it's a relatively easy thing to implement, it would be up to the community to get all the existing pages moved appropriately. -- Wynthyst talk 07:48, 19 May 2013 (UTC)

What about a Version namespace though (as Kanegasi suggested)? Sounds like a good idea but ultimately i have not much say in the decision. –Goandgoo ᐸ Talk
Contribs
Edit count 08:20, 19 May 2013 (UTC)

Me neither, but I like the idea.  Support. -- ^(T) Numbermaniac _(C) 08:22, 19 May 2013 (UTC)

I'd be fine with the mod and tutorial namespaces, not so sure about version though. Why is a namespace beneficial for that? If we just had the versions in the mainspace it'd be easy to link to them, without needing redirects.

If we do add these namespaces Wyn, could you get the namespace aliases added that I requested awhile ago, as well? –ultradude25 ᐸ Talk
Contribs 08:37, 19 May 2013 (UTC)

I don't see much use for a Mods namespace at this point. Most of the existing mod pages are unmaintaned, and many describe mods that are no longer being updated. Of course, this could be a chicken-and-egg problem: if the wiki was more supportive of mod pages, perhaps they'd be maintained more actively.

A Version namespace would be more useful. Every minor version and snapshot (e.g., Version:13w19a) could be redirected to the appropriate part of the major version article (Version:1.6#13w19a, as in Kanegasi's example); this would work around the issues with {{Version link}}, allowing us to split the overly-long Version history/Development versions without needing to wait for a MediaWiki upgrade. Maybe not the most elegant solution, but it would be easy to implement. The old bug list/issues pages could be moved into this namespace as well.

As for a Tutorials namespace, I'm indifferent: I don't see a big advantage to it, but I don't have an argument against it either. -- Orthotope 09:11, 19 May 2013 (UTC)

Again, I'm not seeing the benefit of the namespace. Why can't we have a 13w19a article that redirects to 1.6#13w19a? It's easier for linking, since you don't have to pipe out the namespace every time or use a redirect (and the 1.6 article would exist either way, it'd just be a redirect instead). –ultradude25 ᐸ Talk
Contribs 20:10, 19 May 2013 (UTC)

Some thoughts: For Mental Mouse, Wikipedia may be the pioneer of wikis and a great example to follow, but we don't have to follow them. I agree that every custom namespace I've seen has some sort of special functionality, but they don't have to be like that. Any wiki can use the functions of MediaWiki as they see fit. I also don't understand what you meant by "separate copies of item or mod pages for every version".

For Wynthyst, that's my general thought process. I think that the main space, with exception to the main page, should have nothing but vanilla articles in it, but we've made exceptions by organizing large subpage trees and every once in a while, we get a random page creation that was supposed to be in these subpage trees. Tutorials normally explain vanilla concepts, but organizing them into their own space sounds nice and it would be a little harder to accidentally or ignorantly make a main space page when you were supposed to be in the Tutorial namespace. Mods, of course, need a place of their own.

For the version namespace, I don't see piping the links every time that much of an issue, and it would be the same organizational concept as Tutorials or Mods. Just simply a dedicated namespace to version history. If it still feels unnecessary, we can still follow the idea of making main version articles vice clumping changes in one big page. This namespace was mostly an idea to split that dev history page. We could still have a main history page, but not centralize all the history links to it and have it be more of a navigational thing. —Kanegasi ☺C 23:54, 19 May 2013 (UTC)