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 [[Image:User Wynthyst sig icon.png ]] 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. &mdash;Munin295 &middot;  &middot; 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. &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 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.  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.  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  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&#39;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)

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 [[Image:User Wynthyst sig icon.png ]] 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). &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 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.  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.  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.  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. &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 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  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. &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 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 " 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)