Minecraft Wiki talk:Community portal/Archive 13

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? -- 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. – ᐸ  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, before it was deleted. --  10:26, 31 March 2013 (UTC)


 * Dunno then. I don't use emails. – ᐸ  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? -- 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? //  17:14, 2 April 2013 (UTC)


 * To get a mobile site, we'd have to install . 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. – ᐸ  17:47, 2 April 2013 (UTC)


 * Okay, thanks for the quick reply! //  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. -- 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. --   11:46, 3 April 2013 (UTC)


 * Great! I'll be looking forward to it! //  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? -- 01:32, 4 April 2013 (UTC)


 * Also, would the wiki require internet to acess, or would it be a download that requres internet to edit pages?-- 01:50, 6 June 2013 (UTC)

News? MediaWiki will be updated soon? 11:14, 29 July 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! 01:32, 4 April 2013 (UTC)


 * Since noone has replied, might as well.

The wiki got a makeover only a few months ago. Atleast, from my knowlage, it did. - 19:24, 18 July 2013 (UTC)
 * Meh, it's fine as it is. And no bribing.  —  undefined 21:57, 18 July 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; &middot;  &middot; 07:16, 4 April 2013 (UTC)

wither skeletons
Why dont Wither skeletons ever spawn in the Overworld? 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; &middot;  &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? -- 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. -- 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? -- 02:33, 14 April 2013 (UTC)


 * 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, even tho its incomplete at the moment. Does anyone have any comments on it? -- 04:05, 21 April 2013 (UTC)
 * The headers look good, but I'm not wild about that centering of the titles. -- 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!!!!

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


 * Interesting result. However, this would be better if you put it on the - 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 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. -- 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. - 21:59, 8 May 2013 (UTC)

Delete page
I think should be deleted. It's orphan and talks about almost 4-years-old things. Useless page.-- 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. --   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, 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? --   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? -- 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. 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 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; &middot;   &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? -  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., 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? -- 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 -- 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? --undefined 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. -  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. -- 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; &middot;  &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. --undefined 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. -- 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  written for this purpose. &mdash; &middot;   &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. – ᐸ  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. --   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?  17:01, 14 May 2013 (UTC)


 * (edit conflict) What are you talking about "no viable page loader"? It's right and we've already got the navbox  without needing any modification to the script or navbox template; we just need to actually apply it to the navbox pages. – ᐸ   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). -- 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.  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. 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. --    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 <span class="plainlinks">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. &mdash; &middot;  &middot; 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 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.  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! --   11:02, 17 May 2013 (UTC)

Is there any update on this? is everything updated and implemented? I'm interested if whatever trickery you did works! --<font color="blue" style="text-shadow: 0px 0px 8px #00FF00;"> 20:50, 28 May 2013 (UTC)


 * Quite a few templates have been converted for a few days now. All content of these templates are not transcluded anywhere, so updates to the content no longer cause any server problems. There are still high use sprite templates, but I do believe the issue was the cascading effect of everything used in a nav template being reparsed for every change. Sprite usage now is just direct transclusions such as simple item/block linking. As far as I understand, I believe the problem is fixed, or at least severely lessened for the purpose of stability in order to upgrade the wiki. I would imagine that an lua solution would further reduce the issue.  09:53, 29 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 in the see also section of anything that was "introduced" in that version, but then actually added. Since '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. 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 -- 11:33, 3 May 2013 (UTC)


 * That didn't work. -- 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.  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. -- 02:08, 5 May 2013 (UTC)


 * - Sounds like a good idea. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   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? - 16:05, 9 May 2013 (UTC)

I also have some snips of this occuring, if that's helpful. - 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 :

div.atflb { display: none !important; }


 * &mdash; &middot;  &middot; 17:37, 9 May 2013 (UTC)


 * Thanks! - 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! 20:07, 15 May 2013 (UTC)


 * <span class="nowrap">– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 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. 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: 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. 11:22, 18 May 2013 (UTC)
 * 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!  -- 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. --   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. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   08:20, 19 May 2013 (UTC)
 * Me neither, but I like the idea. . -- <span class="nowrap">undefinedundefined 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 awhile ago, as well? <span class="nowrap">– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  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., ) could be redirected to the appropriate part of the major version article (, as in Kanegasi's example); this would work around the issues with Version link, allowing us to split the overly-long 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. -- 09:11, 19 May 2013 (UTC)


 * Again, I'm not seeing the benefit of the namespace. Why can't we have a article that redirects to ? 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). <span class="nowrap">– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  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.  23:54, 19 May 2013 (UTC)


 * in principle, particulary for version namespaces. We've recently been reviewing our extensive use of namespaces over at the Unofficial Elder Scrolls Pages (uesp.net) wiki and have come across some issues that weren't expected when the namespaces were initially set up. For instance, you cannot guarantee that the developers will be consistent when naming their updates. I see already that with Minecraft there are two different ways of naming the version: by version number, and by Title Update. What happens when the naming schema is changed by the developers? Do we change the namespaces to make them consistent with the new schema? A whole heap of effort for very little return, in my honest opinion. <font color="#703931">&mdash;  19:00, 6 July 2013 (UTC)


 * I took a quick look over at your wiki, and I understand your thought process, but that's not what I was going for. Your wiki makes a whole new namespace for a specific version, my idea is just one namespace called "Version". All the articles in this namespace would be the version number, so there would be a Version:1.6 article that contains all snapshots and pre-releases for that version. I'm not sure this space would be implemented though due to mixed thoughts here.  20:32, 6 July 2013 (UTC)


 * Thanks for the further explanation. I'm still of the opinion that additional namespaces add additional complexity that can be detrimental in the long term. My objection still stands. <font color="#703931">&mdash; 07:37, 7 July 2013 (UTC)


 * Custom namespaces are something you have to be careful about adding, because once a custom namespace is added and becomes used, it is very difficult to change or remove it. Certainly, if used judiciously and with careful consideration, custom namespaces can be a powerful organizational tool, but I can attest from personal experience that adding custom namespaces for their own sake, or without due consideration, can end up quite ugly.
 * In this particular case, I can definitely see the argument for custom "Mod" and "Tutorial" namespaces (with the singular names, not the plural ones; I can elaborate on this if requested), considering we already treat them as separate namespaces for all intents and purposes. I do not, however, see any compelling need for a "Version" namespace: pages should either be "Version/" subpages, or (preferably, I think) should stand on their own, e.g. "1.6.1" (at the very least, we should have redirects in place, I think). <span style="white-space:nowrap">「」· 17:01, 7 July 2013 (UTC)

Picture usage in quote
Currently, it seems there is no consistency with pictures in quotes. We continue to maintain Twitter profile pictures for some reason and it just seems all the Mojangster pictures are random, like Lydia's face, C418's stuff, etc. I propose we have a full set of official Mojang avatars, cropped to the face (which we do have for a few Mojangsters) and quote will only use those. I really don't see the reason to plaster the wiki with random Twitter profile pictures. To enforce this, we should code the quote template similar to what we have for the crafting templates, so instead of the "Grid" prefix, all the Mojang avatars will be prefixed with "Mojang-" and using the Mojangster's name in the quote template will automatically display the correct picture. 22:56, 21 May 2013 (UTC)


 * I like the idea. -- <span class="nowrap">undefinedundefined 09:02, 22 May 2013 (UTC)


 * I don't have an issue with that, although I'd prefer the prefix to be Mojavatar. <span class="nowrap">– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 03:29, 23 May 2013 (UTC)

Wiki header text contrast
I think the contrast between the black text and dark blue background on the wiki's header isn't the best. <div class="mcwiki-header" style="display:table">It's readable, but not so great. Even with bold font, which is commonly used What do people think about using white text instead? <div class="mcwiki-header" style="display:table;color:#FFF">It's more readable with standard font and bold font, and still looks nice. <span class="nowrap">– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 03:28, 23 May 2013 (UTC)


 * . I thought the same thing a while ago, I just never did anything about it. It is hard to read, especially on small devices like my phone. -- <span class="nowrap">undefinedundefined 07:09, 23 May 2013 (UTC)


 * - 19:20, 24 May 2013 (UTC)


 * . Even I agree with this, and I'm anonymous... -- 01:19, 27 May 2013 (UTC)


 * . The black text is completely readable for me, while the white text version is not. If you need contrast, it's also possible to change the background color. -- 05:38, 27 May 2013 (UTC)


 * Hmm, GreenStone has a point. The white font is readable for me, but we can change the background color also, so it would be completely readable for everyone. -- 13:05, 31 May 2013 (UTC)


 * Rephrase: We can always change the background color instead. -- 03:35, 1 June 2013 (UTC)


 * The blue color kind of matches the wiki. I do really think it should be white. –- <span class="nowrap">undefinedundefined 07:21, 9 June 2013 (UTC)


 * You're right. But maybe if we put the white text, and made the blue a little bit darker... -- 14:36, 9 June 2013 (UTC)

That could work. –- <span class="nowrap">undefinedundefined 01:05, 10 June 2013 (UTC)


 * I agree with 70.181.68.226. -- 14:45, 11 June 2013 (UTC)

( is the current color)

One of these, perhaps? -- 15:19, 11 June 2013 (UTC)


 * Probably the darkest one will work best. -- 16:38, 11 June 2013 (UTC)


 * I favor the bottom one. - 00:15, 12 June 2013 (UTC)


 * I like 1e75cc. –- <span class="nowrap">undefinedundefined 05:30, 12 June 2013 (UTC)


 * I was trying to say what both of you are saying! -- 05:35, 12 June 2013 (UTC)

Help?
How do I create a User Talk page? -Fred071202 01:52, 24 May 2013 (UTC)


 * Generally, IPs don't have talk pages. If you plan on being an active user with a talk page AND a user page, might I suggest creating an account? (Ok, I am going against my own words :P. I might create an account... someday... preferably in the near future...) Happy editing! :) -- 03:41, 24 May 2013 (UTC)


 * Thanks for the help! -Fred071202 15:21, 24 May 2013 (UTC)
 * EDIT: By the way, does it cost money, and if so, how much? -Fred071202 15:48, 24 May 2013 (UTC)


 * It's free. -- 17:38, 24 May 2013 (UTC)


 * Just to clarify, anyone can have a talk page. It's just the userpage that wasn't accepted. For you, "Fred071202", click your own IP link, then click "talk" in the top left mini navigation under the "User contributions" title. I highly suggest you get an account first. <span class="plainlinks">Click here to create one . No email required and completely free.  20:05, 24 May 2013 (UTC)


 * Yes. I said that generally, IPs don't have talk pages. -- 21:00, 24 May 2013 (UTC)


 * You're the biggest exception. O_O -- <span class="nowrap">undefinedundefined 01:31, 25 May 2013 (UTC)


 * Yes. Yes I am. -- 02:42, 25 May 2013 (UTC)

Sponge
First of all, the Minecraft Wiki states that if you want to talk about Minecraft, you should use this Talk Page (the Community Portal). Anyway, how come doesn't soak up  anymore? Maybe after you break a block of Sponge that has Water in it, it would release all the water? -Fred071202 18:41, 24 May 2013 (UTC)


 * First off, it meant the wiki itself, not the game. Two, suggestions should go to the fourms or twitter.. - 19:19, 24 May 2013 (UTC)


 * It does not state anywhere on this wiki that talk about Minecraft occurs here. All talk pages are wiki-related. Normally, they are only for the page they are attached to (named after) with exception to this page, which is for wiki-wide general topics or stuff affecting more than one page, and the Admin noticeboard talk, which is for any discussion requiring admin attention. As Creeper has stated above my reply, all general Minecraft discussion goes on the forums. There is a link on the left side menu on every page to the forums. Clicking "Minecraft discussions, ideas, and suggestions" in the yellow box while editing any talk page will also take you to the forums.  20:12, 24 May 2013 (UTC)

Licensing: mod images
Which license is correct for images of items/blocks added by mods and why? (example: — Mojang license;  — unlicensed.) --  09:27, 29 May 2013 (UTC)


 * Both are just tinted versions of the minecraft textures, so fall under Mojang's license. <span class="nowrap">– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 09:42, 29 May 2013 (UTC)


 * Obvious recolors of default textures (compare Aether Dirt with ) should have the Mojang license – "derivative of copyrighted Mojang artwork and content". If it's actually original artwork, licensing is up to the creator. Files using license haven't had a license assigned yet, usually because the correct license couldn't be determined, or simply because no one has gotten around to it. -- undefined 09:44, 29 May 2013 (UTC)


 * The "recolors -> Mojang license" was my assumption before I posted the first message. However, what about original work? Does the algorithm look like this:

if the image is an obvious recolor of a default texture: put the Mojang license template else: search for any information on the mod's forums, contact the creator if the license is now determined: put the corresponding license template else: put the "Unlicensed" template
 * The problem is in the "Unlicensed" template. "Please set a license by using the appropriate option on the drop down list or applying the correct license template." is not very appropriate because the correct license could not be determined. (and likely will not; if asking the creator didn't work, then nothing will, unless there is a "default license") -- 10:09, 29 May 2013 (UTC)
 * The problem is in the "Unlicensed" template. "Please set a license by using the appropriate option on the drop down list or applying the correct license template." is not very appropriate because the correct license could not be determined. (and likely will not; if asking the creator didn't work, then nothing will, unless there is a "default license") -- 10:09, 29 May 2013 (UTC)


 * The unlicensed template is just there to categorise. I don't know much about copyright (does anyone, really?), but I seem to remember reading that if you don't set a specific license on something, it is automatically copyright to you. So not having a license is actually more restrictive than having say, a public domain license.
 * Any page without an unlicensed template (every file should have a license template, even if it's just the base license) should be assumed copyright of the uploader. <span class="nowrap">– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 11:25, 29 May 2013 (UTC)
 * Anything that does not have an existing license falls under the CC by nc sa 3.0 license if it is uploaded here on the wiki whether it is tagged or not. --   02:14, 12 June 2013 (UTC)

Language categories
On blocks, the "type" automatically puts it in that category. This is a problem for pages in other languages. On those pages, there are categories that don't exist. There is also this problem with dyes. -----undefined undefined 22:04, 12 June 2013 (UTC)

Trick with Redstone Comparators
If you place redstone to connect the front of a redstone comparator to the side, turn the redstone comparator on, then add a lever/redstone torch/pressure plate etc. it will cause the redstone current to flash. You can connect this current to a dispenser to make it shoot items at about 5 times a second. This is very useful for getting rid of many mobs with tons of arrows or fire charges. I was playing around with redstone when I found this out and I thought it would be nice to put it on this page since I couldn't find anything about it in the "Redstone Curcuits" section. Sincerely, ERBPOWOR –Preceding unsigned comment was added by  at 02:56, 22 June 2013 (UTC). Please sign your posts with


 * . Anything that generates pulses one after another is a.
 * &mdash; &middot;  &middot; 03:01, 22 June 2013 (UTC)

There will be something like that in dylan luper you tuber redstone tips episode 2 But it's not your idea it's comepletely different. 19:07, 8 July 2013 (UTC)

How do u join worlds in the new update of the pe?
What the topic says

Enchanted Golden Apple
We need a grid image for his. I got confused when it seemed that both crafting recipes on gave the same result. <span class=nowrap> — undefined undefined 09:24, 2 July 2013 (UTC)


 * The enchanted golden apple looks identical (aside from the enchantment glowyness) and has the same name. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:32, 2 July 2013 (UTC)
 * Ah, ok. It just that they both looked identical in the crafting grid. <span class=nowrap> — undefined undefined 23:51, 2 July 2013 (UTC)


 * As they do in the game, aside from the minor enchantment effect (which we can't really do) and different tooltip text colour (could make custom tooltips though). <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 01:49, 3 July 2013 (UTC)


 * Whatever. You're the design man :D <span class=nowrap> — undefined undefined 02:14, 3 July 2013 (UTC)
 * 'Enchanted' effect needs more than 256 colors, so we cannot use GIF format. This image uses format, but most browsers don't support it. -- 10:06, 6 July 2013 (UTC)
 * Or like this? <span class="nowrap"> <font face="Ubuntu"> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> -  de.Wiki Admin  13:43, 6 July 2013 (UTC)

Bug descriptions
The previous summary says that we have to use the original name at all times, even if it contains wrong spelling or other flaws. I do not see any logic in that. In my opinion, bug entries in changelogs have two purposes: 1) Provide a brief description of the bug; 2) Provide a link to the page which contains more details.

What if the name is not a sufficient description of the bug? (Example: "Critical server error" instead of "Server crashes when %s".) What if it contains confusing spelling errors? ?

-- 09:46, 6 July 2013 (UTC)


 * I only copy, edit in wiki format and paste the bug list. There will be numbers of issues, and I cannot edit each of them. How about posting only bug queries? Mojang started bug tracker, we don't need to file each issues. If there are crashful or fatal bugs, we can mention them in 'Notable bugs'. -- 10:01, 6 July 2013 (UTC)


 * Chances are I might be in the wrong here. A similar thing happened before where a bug's title was fixed for spelling errors, then undone because that is how it is actually spelt in the report. So what's the "rule" on this? <span class=nowrap> — undefined undefined 10:38, 6 July 2013 (UTC)


 * I don't think there is any real rule yet. I suspect, however, that the current practice actually started with me (see my edits to on January 12, where other editors were removing the links to the bug tracker in favor of hand-curated lists and I was reverting without bothering to keep the edited bug descriptions). I never intended that we should only use the descriptions exactly as worded on the bug tracker, though; see my comment in . My feelings haven't changed since then; personally, I don't see any reason to insist on using the descriptions exactly as presented in the bug tracker, so long as the descriptions we *do* use are not inaccurate or misleading. <span style="white-space:nowrap">「」· 10:51, 6 July 2013 (UTC)


 * So does that mean minor things such as modifying spelling erros are acceptable? <span class=nowrap> — undefined undefined 11:32, 6 July 2013 (UTC)


 * Certainly, at least in my opinion (this is a community discussion, after all, so it should probably be decided by more than just one editor ;) ), but I would go farther and say that rewording or even an entirely different description is all right so long as the description we have accurately describes the bug (I alluded to this in my previous comment, but being explicit never hurts). <span style="white-space:nowrap">「」· 11:48, 6 July 2013 (UTC)


 * (edit conflict) Why would we preserve the bug titles? Just write whatever is fitting... <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 11:51, 6 July 2013 (UTC)

RFC: Identifying Xbox 360-specific info
Please discuss here a proposed new project to rationalize and clearly identify information that is only pertinent to the of Minecraft. This project will address the issue raised in the section of the CP, which states...
 * It would be nice if variations in the Xbox version were called out whenever relevant instead of just on one page. For example, in the page on bookshelves, I added a parenthetical note that there's no leather requirement on Xbox.

To resolve this, I propose making a template to add a small and optionally the Title Update that introduced / fixed the particular issue that is so marked. It would end up looking something like this, which may appear on the page, for instance...
 * <span style="font-size:75%;">(Since ): Nether Brick is a renewable resource, via use of the Reset Nether option.

Another idea is to review the template, with a view to adding XBox 360 content to the history section of each block or item's wiki page. I see that there is already the capability to include this information within the template, it just doesn't seem to be implemented extensively yet on the wiki.

Please add any other suggestions, comments, or ideas about this proposed new project. I'm keen to get some feedback before I create the project page and get the ball rolling. <font color="#703931">&mdash; 17:55, 6 July 2013 (UTC)


 * The project should be for adding missing info specific to any edition of minecraft, not just Xbox. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 04:21, 7 July 2013 (UTC)


 * The same technique can be used for any edition of Minecraft, sure. Personally, I only play Minecraft on Xbox 360, so I can't really contribute anything for other editions, but the same idea applies. Other editors who have access to the other editions are welcome to create parallel projects for their favourite edition, no doubt. Any templates I make for this project will be easily adapted to the other editions. Oh, and this project isn't really about adding "missing information" as such, it is more about highlighting existing information for easier consumption by those searching for edition-specific info.   <font color="#703931">&mdash;  04:40, 7 July 2013 (UTC)


 * If you only want to work on the xbox part of the project that's fine, but I don't think a separate project for each edition is necessary. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 05:09, 7 July 2013 (UTC)


 * Fair enough comment. Thanks for the input. When I start the project, it will be broader in scope, to include all editions, but my own contributions will mostly be for the XBox 360 Edition. I'll make the icon template either reusable for all editions (using the  parser function), or seperate templates for each edition. Any objection to the project being called "Highlighting Edition-Specific Information"? <font color="#703931">&mdash;  07:24, 7 July 2013 (UTC)

I've launched the project,. I have noticed a couple of existing projects that would probably now come under the purview of this new project, as they are Edition-specific projects as well. Notably, the project and the  project. Should these two projects now be merged under the (HESI) project? <font color="#703931">&mdash; 09:01, 9 July 2013 (UTC)

End of game
A roommate and I have been building a town in creative mode, cheats for a while now. We had crops, villagers, multiple homes, etc. We did not use that world for anything else. Another roommate came along used that same world to transport(?) somewhere and defeat some dragon(?). We're not sure what happened, but whatever he did, the game was completed. He told us that the credits rolled by on the computer screen and then a selection screen came up. He selected respawn(?) and our character appeared in some location that we've never seen before. What did he actually do in our world and how do to we get back to the town we spent weeks building? -- 12:26, 8 July 2013 (UTC)


 * H's obviously gone and killed the to finish the game. If you had ever saved the coordinates of your building, you could /tp there, otherwise I'm not too sure. <span class=nowrap> — undefined  undefined 12:31, 8 July 2013 (UTC)
 * We did not know anything about coordinates. We've had the game only a short while and have not done much other than build the town. Is there another way to find the town, such as move around in the land? -- 12:42, 8 July 2013 (UTC)


 * It does seem that your roommate has ended your game by killing the Ender Dragon, as numbermaniac mentioned above. However, I don't believe it will be possible to return your village to the way it was, I'm afraid. Once your game has "respawned", the world is reset back to how it appeared right at the beginning, without any of your modifications to it. The coordinates mentioned above may get you back to the village, but it would be the village as it was before you had done anything to it. This is, of course, assuming that your roommate selected to respawn with the exact same seed. If a different seed were used for the respawn, then even if you did have the coordinates for your village, they wouldn't help you anyway. The only other thing I can think of that might help is if you have made a backup of your world at some time before your roommate defeated the Ender Dragon. Sorry I can't offer any better advice or hope for you. Enjoy the new world, and make it bigger and better than ever. Keep the other roommate at bay, and backup your savegame file. <font color="#703931">&mdash; 16:22, 8 July 2013 (UTC)


 * What? Since when does killing the ender dragon reset the world? You just go back to your spawn point. If you remember where you went when you first created the world to get to the town, you can retrace those steps. Or open the world in a map editor and search around the loaded chunks for your town. You can then use the editor to set your spawn point to your town, or if it gives you coordinates use them to teleport to it, or just use it to know which direction to travel from spawn.
 * Also this belongs on the forums. This topic has nothing to do with the wiki. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 16:46, 8 July 2013 (UTC)

If you slept in any of your homes type /kill I know what it will do and so will you but thats all you can do. 19:05, 8 July 2013 (UTC)