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.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the forums.

Autoconfirmed permission on all pages

Note: Some of the text seen below has been intentionally copied from an eariler discussion regarding anonymous users creating pages, seen here.

Can we just disable anonymous users editing pages? Sure, I have seen some "useful" contributions by anonymous users (mostly just grammar fixes), but most of the edits by anonymous users are just blatant vandalism, spam and advertising. We should still let them edit talk pages, but require making an account to edit pages, as if a user cares enough about the wiki to make an account, they are that much more likely to care about our policies.

I know a change like this has to be made by Curse, but I figure the community should decide before I suggest it. BDJP ^(t|c) 17:01, 8 July 2015 (UTC)

This is very unlikely to happen. You underestimate the value added by drive-by fixes from anon editors. Why do you think Wikipedia allows it, when they are such a huge target for vandalism?

Small wikis which can't keep up are the only cases where I could see this happening, of which we are not. This is better handled by better abuse filters, rather than preventing editing entirely. –Majr ᐸ Talk
Contribs 17:24, 8 July 2015 (UTC)

Curse requests

Please direct requests requiring Curse's attention (such as configuration changes) to me first to assess, and I will then pass them on. Thanks! –Majr ᐸ Talk
Contribs 17:14, 8 July 2015 (UTC)

Accepted, although I may still prefer contacting Game widow directly. Make sure to add her talk page into the watchlist if needed. — Agent NickTheRed37 (talk) 17:28, 8 July 2015 (UTC)

Notified Russian users. — Agent NickTheRed37 (talk) 17:39, 8 July 2015 (UTC)

Ouh, and does it apply to other wikis (like Terraria one) by chance? — Agent NickTheRed37 (talk) 17:42, 8 July 2015 (UTC)

Nope, only here. –Majr ᐸ Talk
Contribs 15:54, 11 July 2015 (UTC)

Nick, this has nothing to do with your preferences. Majr is an employee of Curse, and, presumably in that role, has stated that requests for Curse need to go through him. Unless he or another Curse employee clarifies otherwise, this means all requests need to go through him, regardless of your feelings on the matter. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 02:34, 9 July 2015 (UTC)

FYI, the reason that I should be contacted is I know the community better, so I am in a better position to vet the requests before passing them on. –Majr ᐸ Talk
Contribs 15:54, 11 July 2015 (UTC)

I will keep that in mind. Sorry if I overstepped a bit with contacting Game widow directly. –KnightMiner · (t) 03:48, 9 July 2015 (UTC)

No problem. I hadn't formed a strong opinion on the subject yet, so I hadn't replied, and so you didn't know. –Majr ᐸ Talk
Contribs 15:54, 11 July 2015 (UTC)

Sprite editor ready for testing

I have finally gotten this project in a state ready for testing. A page is available here, which you can feel free to play with. To get started hit the "Edit sprite" tab.

My main areas of interest are browser compatibility and bugs, but comments on performance and usability are useful too. I have created a repository here to keep track of bugs and feature improvements, which you may report to directly if you wish.

I haven't created any documentation on how to use it yet, as I'd like to first see if it is easy enough for people to figure most things out without requiring a manual. :)

–Majr ᐸ Talk
Contribs 16:48, 11 July 2015 (UTC)

Firefox 39.0. Works fine when editing, but nothing seems to happen when the Save button is clicked (except that the button changes its graphics; I have been waiting for at least 3 minutes). --GreenStone (talk) 17:20, 11 July 2015 (UTC)

Same browser here, unable to make it fail as you describe; can you provide steps we can follow? Maybe also hit F12, and report anything that happens in the network tab or console tab. – Sealbudsman (Aaron)

^T/_C 18:41, 11 July 2015 (UTC)

All I get is sections of sprites, no editor. I use Firefox 39.0 but with a lot of things blocked. What was this supposed to run in (javascript, flash, etc.)? —munin ·

· 20:09, 11 July 2015 (UTC)

If you don't see the tab at all, you have JS disabled. If you do see the tab, but clicking it doesn't load the editor, then maybe you're blocking particular scripts. –Majr ᐸ Talk
Contribs 06:25, 12 July 2015 (UTC)

Reply to Sealbudsman: I added a new section and an entirely new sprite into that section. The sprite was loaded from a 16x16 .png image. --GreenStone (talk) 06:52, 12 July 2015 (UTC)

If it was an API error, a message would be displayed, so it sounds like you managed a JS error. Have your console open while editing and see if any errors come up. –Majr ᐸ Talk
Contribs 06:25, 12 July 2015 (UTC)

Reply to Majr: This is what I get in the console when opening the page (thought you might be interested in that as well) and when saving. The first four lines appear when loading the page in View mode, nothing new appears when switching to Edit sprites mode, and the last line appears when clicking Save after performing the changes described above. --GreenStone (talk) 06:52, 12 July 2015 (UTC)

Ah yeah, that's a problem. Curse keeps images on a different domain, so it is impossible to load the sprite sheet due to the same origin policy. I've disabled image editing for now. Maybe if CORS was enabled, it would allow it to work. –Majr ᐸ Talk
Contribs 10:05, 12 July 2015 (UTC)

CORS is now enabled (it was actually already enabled on the server side), so image editing should work now. –Majr ᐸ Talk
Contribs 11:48, 16 July 2015 (UTC)

Image editing seems to work now, but I am unable to view this diff properly. This is the entire returned page. --GreenStone (talk) 12:44, 16 July 2015 (UTC)

That's caused by the wiki not handling large diffs well. Because you added a new section, that incremented the section number for all the below sections, causing all 774 lines to be updated with the new section number. I could fix this by using a unique ID for each section, rather than a positional number. This would also make tidier diffs when re-arranging sections, as the section number for all images in those sections wouldn't need to be updated. –Majr ᐸ Talk
Contribs 17:07, 18 July 2015 (UTC)

If you click to edit the sprites, navigate away from the page without saving, and use your browser's back button to return to the edit sprite page, you don't return to the actual edit mode until you click "Edit sprite" again (in Chrome 45). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 22:40, 11 July 2015 (UTC)

Can't reproduce. Either from navigating to a different page, or fake navigating to the view page. Does the tab actually get selected, but the editor doesn't load? –Majr ᐸ Talk
Contribs 06:25, 12 July 2015 (UTC)

It's working for me now, must've been my browser being stupid (as is its wont). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:54, 12 July 2015 (UTC)

I think it might have been due to a race condition caused be mw.Api being called before it was loaded, which is why it only happened sometimes. –Majr ᐸ Talk
Contribs 10:05, 12 July 2015 (UTC)

Everything works fine for me on Chromium. The only issue I see is deleting sprites could be a bit more obvious, such as by having a little X button.

Now a question: is this ultimately intended for the sprite extension, or the sprite module? –KnightMiner · (t) 13:10, 12 July 2015 (UTC)

Normally you can click on an image to bring up the option to replace/delete it, however that is removed entirely when image editing is disabled. I probably did that because I was thinking deleting an image required removing it from the sprite sheet, but that doesn't happen anyway, so I could keep that option and just disable the replace button.

This is intended for the module. The extension doesn't have any benefit over the module aside from slightly easier name adding (which is now solved with the editor), and is lacking in features and sane HTML to be a replacement for the module. However, there is no particular reason (with some modifications) that the editor couldn't also be compatible with the extension. –Majr ᐸ Talk
Contribs 11:48, 16 July 2015 (UTC)

Works fine for me on Safari on iOS. The only issue that I have is that I can't see the snowfall sprite. Either its an issue with my brightness, or the background behind the sprite is too bright. :P -BDJP ^(t|c) 03:13, 14 July 2015 (UTC)

So you were able to use it on a phone? That is quite surprising, although I highly doubt the interface was at all optimal for a touch screen, correct? –Majr ᐸ Talk
Contribs 11:48, 16 July 2015 (UTC)

It’s working fine on my Firefox 30.0 (adding and removing (I assume) names, adding, replacing and removing images), but I still have to understand: what realization will we use in the end? I’m mostly sure the SpriteSheet wiki extension can offer more possibilities if made correctly, and it probably doesn’t use JS, which can be disallowed on one’s browser for obvious reasons or not supported altogether. — Agent NickTheRed37 (talk) 15:20, 16 July 2015 (UTC)

While supporting no JS for basic functionality and browsing is highly recommended, for more advanced features it is quite acceptable to require JS, especially since this is not going to be used by readers, and you still have the option to manually edit the sprite sheet and data module, just like with the VE and source editing situation. Anyway, the sprite sheet extension requires JS as well.

The extension just handles basic assigning of names to images in the sprite sheet. It does not handle the most difficult part of sprites, and that is the creation of the sprite sheet itself. The sprite editor is intended to handle sprites as if they were separate images, and you just assign names to those images and categorise them. Yes you could certainly develop an extension that handles constructing the sprite sheet from individual images, and I may indeed do that at some point to improve browser compatibility and performance (as well as providing a more convenient back-end for the editor to work with), but using JS was easier for me as I am more familiar with it, and I generally hate PHP. –Majr ᐸ Talk
Contribs 17:07, 18 July 2015 (UTC)

Moving transcludable metadata, video etc into their own namespaces

These transcludables (examples 1, 2) for now are named as Main article/Name, as subpages, in main namespace. It was a long time since subarticles are now counted as normal articles (note the article count jumping at around February 4–5), and as such these transcludables also go under their definition and, including but not limited to, mess up the shown amount of articles.

Thus I propose introducing new namespaces for these pages (like Metadata:, Video:) to fix all of that. I anticipate a wave of opposes due to being a huge change with probable little benefits, but anyway...

— Agent NickTheRed37 (talk) 18:16, 15 July 2015 (UTC)

Both methods have pros and cons. The multiple-namespace approach has been used for years on the Yu-Gi-Oh! wiki for such things as galleries and rulings, but in spite of that, I don't have much of an opinion on which I prefer. I will point out, though, that one of the cons for that approach is that renaming an article doesn't provide the option to automatically rename the related pages, since they are no longer subpages of that article, though this probably isn't a significant concern here given that pages are so infrequently renamed. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 19:06, 15 July 2015 (UTC)

Agree. Even though I'm okay with it, the Video namespace is already used in Wikia. --MCPEplayer2

^{Talk to me!} 22:48, 15 July 2015 (UTC)

The Video: namespace on Wikia was deprecated a little while back and no longer works; all videos uploaded to Wikia are instead in the File: namespace (as they were originally). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 08:07, 16 July 2015 (UTC)

Keeping data pages in an alternate namespace makes some sense (though it should really be "data" rather than "metadata", mainly since shorter is usually better). The video namespace could also be helpful, especially if we set the namespace to only allow administrator edits (like "MediaWiki" does, and "Project" accidentally did for a bit.)

The main issue I see with this is loss of convenience: not only the moving of pages stuff, but also the convenience of transclusion. Subpage templates (or templates only used on a single page) would basically lose their purpose if they are moved into another namespace, as they no longer have a quick way to be called (thus, they might as well be in the "template" namespace).

I am mostly neutral on this topic, basically I am against it as it seems like a lot of work for seemingly little gain (yep, as said above), but like it for the idea of a namespace to contain all extra page data, basically to keep the main namespace for articles. Though for one last thought, if the main point of this is to fix errors with them acting as articles, wouldn't it be easier to develop a simple extension to get the root article count instead? Most related problems can be solved in a similar way, such as using something like mw:Extension:Randomrootpage to solve related issues with the random button. –KnightMiner · (t) 04:08, 16 July 2015 (UTC)

There are “subarticles” that are actually articles, most notably tutorials and ones about game modifications. Oh wait, can we rather implement a __NOTARTICLE__ “magic word”? If yes, then the idea can be scrapped in favor of that. — Agent NickTheRed37 (talk) 05:50, 16 July 2015 (UTC)

The tutorials have generally been considered as poor quality non-articles (I like to pretend the whole tutorial section doesn't exist), and mods are not officially supported by the wiki, so those sections not being considered "real" articles would be kind-of fitting. However, the quality of tutorials has been improving a lot, so maybe we could consider them real articles and give them their own namespace, or include our pseudo-namespace subpages in our article definition.

As for the magic word, it is likely the easiest solution (and an extension may already exist for it), but feels messy to me. –Majr ᐸ Talk
Contribs 17:51, 18 July 2015 (UTC)

I feel that sub-pages are a good way to associate data with a page, which really should be on the page itself, but only isn't to avoid duplicating the data on other pages. With single-page templates, it is just to avoid wikitext clutter in the article, so those could just be moved the template namespace. And for videos it is just for protection reasons.

I don't see it at all being worthwhile to lose the convenience of these pages being associated with their parent pages just for more accurate statistics. I would rather do as KnightMiner says and try to fix the definition of "article". –Majr ᐸ Talk
Contribs 17:51, 18 July 2015 (UTC)

Template:Grid/Dispenser

There should be a template for the dispenser GUI. The Blobs 15:54, 22 July 2015 (UTC)

Why? There's no difference between the dispenser and the player's inventory or a chest, as far as item interaction mechanics go. There's nothing that would require using a template for that that couldn't be served with a simple screenshot. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 16:47, 22 July 2015 (UTC)

Well, the dispenser can store LESS items than the inventory or chest. --MCPEplayer2

^{Talk to me!} 18:27, 22 July 2015 (UTC)

Okay? How does it storing less items make it be required as a template? The reason there is no chest or inventory template is it is not needed, not there are too many slots.–KnightMiner · (t) 19:05, 22 July 2015 (UTC)

The purpose of the grid templates is to provide a simple, modular, and easily extendable method of displaying interfaces that interact with items, or that enable items to interact with each other, without requiring a separate image uploaded for each possible interaction. The player's inventory, chests, dispensers, and other such interfaces do not interact with items stored in them, nor do they enable those items to interact with each other; they are purely storage interfaces, distinguished from each other in the way they interact with the player and the environment rather than items. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 02:43, 23 July 2015 (UTC)

By using a template, it is easier to create GUI's because you don't have to upload a new image each time. The Blobs 15:33, 23 July 2015 (UTC)

That doesn't say why one is needed for dispensers. What exactly are you trying to do that requires a template instead of being able to just take a screenshot? 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:25, 23 July 2015 (UTC)

I don't know, though it could be created later (if necessary) The Blobs 18:04, 24 July 2015 (UTC)

This is true, but my entire argument is that it is not necessary, and no one else has been able to present an argument as to why it actually is. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 21:07, 24 July 2015 (UTC)

Splitting Windows 10 only updates into their separate pages.

I know this has been brought up a few times, and I know Win10 is MCPE, but for consistency and avoiding confusion, why can't we just create separate version pages for the Windows 10 Edition? We can just add a note saying:

This would settle down the argument about the 0.12.0/0.12.1 page order in the version Nav template. --MarioProtIV (talk) 15:55, 4 August 2015 (UTC)

If anything we should do the opposite and merge 0.12.0 into .1 (since that is the majority), with a note about it being released early as 0.12.0 on Windows 10. –Majr ᐸ Talk
Contribs 16:09, 4 August 2015 (UTC)

That seems like a good idea. --MarioProtIV (talk) 16:12, 4 August 2015 (UTC)

I've written up a sample in my workbench to display (see below). Opinions/suggestions are welcome.

Draft #1

--MarioProtIV (talk) 18:04, 4 August 2015 (UTC)

It's good. --MCPEplayer2 File:Wolf (Wild).png ^{Talk to me!} 21:51, 4 August 2015 (UTC)

@Goandgoo @Dinoguy1000 thoughts? Would like to know soon, so the argument on the 0.12.0/0.12.1 labeling stops (it's also being argued about on Alpha 0.11.0). --MarioProtIV (talk) 23:29, 4 August 2015 (UTC)

I do agree with Majr's proposal that 0.12.0 should be merged into 0.12.1. Seeing that 0.12.0 was never released for the Pocket Editions, and all the features from 0.12.0 are being implemented as part of 0.12.1, it makes sense for the 0.12.1 should be the main version. 0.12.0 was essentially 0.12.1 released early for Windows 10. –Goandgoo ᐸ Talk
Contribs 01:52, 5 August 2015 (UTC)

Portal blocks

The result of the discussion was split respective portal blocks.

Recently a page was created for the end gateway portal block itself. The end portal and nether portal blocks were removed from the technical blocks page and made as a section of their respective page (end portal and nether portal). In the interests of consistency, I propose that the end portal and nether portal blocks themselves should have their own page at End Portal (block) and Nether Portal (block) respectively, with the existing page at End Portal (block) being moved to End Portal (frame). –Goandgoo ᐸ Talk
Contribs 13:16, 5 August 2015 (UTC)

Agree –KnightMiner · (t) 13:42, 5 August 2015 (UTC)

Agree – Sealbudsman (Aaron)

^T/_C 14:45, 5 August 2015 (UTC)

Also support, although I thought it may get better to rename to End Portal Frame, not End Portal (frame). We should really use the “rename” term alongside “move” — Agent NickTheRed37 (talk) 15:10, 5 August 2015 (UTC)

The problem with that however is that it is only officially called the End Portal Frame in the console edition, however the name in the PC version is simply End Portal. However, the in-game name is end_portal_frame so I'm on the fence with this one. –Goandgoo ᐸ Talk
Contribs 11:52, 6 August 2015 (UTC)

The name was reported as a bug for Pocket Edition in MCPE-7948, and subsequently confirmed and assigned by Daniel Wustenhoff. --Illidicia (t+c) 14:59, 6 August 2015 (UTC)

Agree. -Mikazukinoyaiba 16:47, 5 August 2015 (UTC)

Would it be any better to just merge the gateway block article into the gateway structure article, the same as was done with the nether and end portal blocks, into their structure's articles? They don't appear in gameplay independent of their structures, and their structures don't function without them, and the correlation of portalblocktype-to-structure is one-to-one. – Sealbudsman (Aaron)

^T/_C 18:25, 5 August 2015 (UTC)

While the structures don't function without the blocks, the blocks do function independent of their structures. While the nether and end portal blocks simply take players to the Nether/End respectively, the gateway block can be used as a custom teleportation block, and detailing the information on the custom teleportation is completely separate to the survival function of going to the other islands. Therefore I still think there is enough content on the block themselves, which can be placed using /setblock, to have their own respective pages. –Goandgoo ᐸ Talk
Contribs 11:52, 6 August 2015 (UTC)

Ah ok, fair enough. I still support the split as proposed. – Sealbudsman (Aaron)

^T/_C 12:58, 6 August 2015 (UTC)

I Agree. --MCPEplayer2 File:Wolf (Wild).png ^{Talk to me!} 01:15, 7 August 2015 (UTC)

Error on mobile w/ desktop view on?

Apparently I cannot view the desktop view of the entire wiki on my phone, instead, it links to the main Gamepedia page.. Is this an error/bug/data failure or something? MarioProtIV (talk) 16:44, 5 August 2015 (UTC)

I would really appreciate any response if this is a bug or not D: MarioProtIV (talk) 20:39, 5 August 2015 (UTC)

@Majr, can you try and see if this occurs on your mobile device? I'm not sure if it's just me that's having the issue. MarioProtIV (talk) 01:11, 6 August 2015 (UTC)

I don't have one. –Majr ᐸ Talk
Contribs 04:25, 6 August 2015 (UTC)

Seems to be working fine for me (Chrome on Android). -- Orthotope^talk 04:45, 6 August 2015 (UTC)

Works on Wikipedia (Safari on iOS). The Blobs 22:38, 15 September 2015 (UTC)

Beta 1.9 page

I think it may be a good idea to add more info to the Beta 1.9 article to make it more consistent with the other pages. It will also include some info on why it was never released. I've written a draft here. --MarioProtIV (talk) 21:08, 7 August 2015 (UTC)

It was released, it was just called 1.0.0. Any other content you can add is either redundant or states that first sentence. Your draft article only proves this, with all its content either being fan nicknames (a forum thread is not a valid source for a name) or stuff that can easily be described on 1.0.0. It would also be less consistent to split it, as all other updates which changed their number are covered on the new number (for example, 1.7 on 1.7.2). –KnightMiner · (t) 21:24, 7 August 2015 (UTC)

Ah ok. I'll just add a trivia note to the 1.0.0 article saying that it was originally planned to be released as Beta 1.9. --MarioProtIV (talk) 22:01, 7 August 2015 (UTC)

Module:LoadArchives

On talk pages with more than one archive, it is impractical to manually create archive boxes for each talk page. There should be a module that creates archives for you. Parameters would be stored in Module:LoadArchives/Discussions. The code would be as follows:

local p={}
p.archives=expandTemplate{title='Archive box',args=mw.loadData('Module:LoadArchives/Discussions')[mw.getCurrentTitle().prefinedText:gsub('/Archive %d+$',)]}
return p

The Blobs 00:45, 10 August 2015 (UTC)

You don't need to create an archive box for each page if one is required on the archive pages, just create a subpage and transclude it (see my talk page for an example). Usually though we only add the box on the main talk page. –KnightMiner · (t) 01:47, 10 August 2015 (UTC)

Phasing away from Mojang avatars to real life pictures + Expanding biographies on current and former employees

I feel like these are the stupidest ideas I've ever conceived, but here goes nothing... (I literally had to rethink this about 20 times before finally getting an idea)

I think that the Mojang avatars on Mojang AB need to be replaced by real life pictures of the employees (in fact, the last avatar ever made by Jnkboy was almost three years ago). A perfect example would be this picture of Daniel Wustenhoff. To me, I feel like these pictures look cleaner and more "professional" than the official avatars.

The biographies of the employees at Mojang clearly need some major expanding, and I feel like using LinkedIn would be a fine choice, as no one has even bothered to touch those pages (except for Tomas Alaeus of course) when it comes to information about where they graduated, what they graduated for, what jobs did they have before joining Mojang, etc. -BDJP ^(t|c) 01:39, 10 August 2015 (UTC)

While I do like the Mojang avatars, I do agree the real life pictures often look better when available, though I am not so sure such pictures are required on the Mojang article anyways (if one is required, I am neutral on which to use).

As for LinkedIn, that seems like a pretty good source for information on the users, though I am currently having issues getting the site to display in English. (I take it the subdomain made the site think I am Swedish...). I think it looks like a reliable enough source to start adding to articles, though it couldn't hurt to make sure the profiles were made by the actual employees. –KnightMiner · (t) 02:37, 10 August 2015 (UTC)

I don't have much of an opinion on using the Mojavatars versus actual photos, but would like to point out that getting new Mojavatars is a simple matter of asking Jnkboy for them (assuming he still works with Mojang); this is literally the method I used to get the last version of them.

Of course, now that I think about it, it would be really awesome if we could get photos of the Mojangstas all wearing shirts with their Mojavatars printed on them, though that would probably be hard as hell to have done for several reasons. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:10, 10 August 2015 (UTC)

As for expanding their articles with more details of their lives and careers, two important factors need to be kept in mind: verifiability and desire for privacy. Verifiability should be simple enough; either ask each Mojangsta for some details to flesh out their article, or ask them to confirm if a given source has it right. Desire for privacy is a bit trickier but just as important; if a given Mojangsta prefers some detail not be included in their article here, we should respect that (note we made this concession for ez). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:22, 10 August 2015 (UTC)

Welp, I just got confirmation that Jnkboy is going to get back to making Mojang avatars; didn't say when though, so that takes the phasing away part out of the picture. Don't even read the rest of the tweets I sent him. Its very hush-hush. -BDJP ^(t|c) 11:58, 10 August 2015 (UTC)

Pocket Edition Alpha 0.12

Can we please decide what we're actually doing with these versions already? I've lost track of the various pagemoves and redirects by this point, and the situation doesn't seem to be getting any simpler from the perspective of the releases themselves; these are also part of what resulted in the editing restrictions currently in place on several editors.

This is my understanding of the version situation as it stands (note that I am pointedly ignoring the hot mess that is our article(s)):

Pocket Edition Alpha 0.12.0 was released exclusively for Windows 10, with the version number "0.12.0"
Pocket Edition Alpha 0.12.1 was released for mobile devices, incorporating the changes and bugfixes from 0.12.0, and adding/fixing a few more things (?)
Windows 10 devices received 0.12.0.1

(If I missed anything or am mistaken in any details, please call me on it, or feel free to fix the summary directly.) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:16, 12 August 2015 (UTC)

Just to be clear, this is what I want out of this discussion:

A clear and concise summary of the version/release situation
A summary, with links, of any relevant statements by the developers
Summaries of any relevant discussions that have already taken place, with links to those discussions
- Where necessary, harmonization of the results of those discussions, and extension of those results to cover any details that weren't already handled
A single, central location for any and all further discussion on this topic (meaning any currently-in-progress discussions should be summarized here and then pointers to this topic should be posted on them)

I don't care about the minutiae of implementing the decisions; that can be left to new discussions on the article talk pages themselves; what I want to see is a final decision on what those articles will be in the first place. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:27, 12 August 2015 (UTC)

You are correct, but 0.12.1 on mobile also adds the additions from 0.12.0. Here is my theory on what I want to do with these pages:

Split them into separate articles, and while I know Win10 is MCPE, it can prevent this from happening again if 0.13 happens to be 0.13.0 (then 0.13.0.1 and so on) on Win10, then 0.13.1 on mobile devices. I've also discussed how the template for MCPE versions can be sorted out here.
We can keep the pages as is and just add the template that I explained before.

--MarioProtIV (talk) 00:41, 12 August 2015 (UTC)

The current situation is basically Windows 10 got 0.12.0 released early, and now got a bug fix update called 0.12.0.1 (which is likely to fix incompatibilities with the new platform). The rest of the editions meanwhile are developing 0.12.1, which contains basically the same feature set.

As for developer statements, Tommaso says it is the same edition, and that most exclusive features are planned for the other MCPE versions, along with supporting co-op play between the two. He also stated that they will be developed together.

As for relevant past discussions: There is the first discussion, which was about merging the windows 10 edition article with the pocket edition article, which end undecided, leading to no action. The second discussion about splitting Windows 10 to its own articles, which ended with 0.12.0 being merged into 0.12.1. The last discussion I know of was about dealing with the later bug fix updates for the windows 10 edition, which lead to MarioProtIV moving all the articles, despite Illidicia disagreeing with separating the two editions.

As for a final solution, I suggest the Windows 10 Edition should be treated as another platform for the Pocket Edition. This means it will share a spot in the history section, the same version articles, same navigation templates, and same features articles (mentioned, removed, etc.). We have all the other pocket editions merged already, and have merged all the console editions, so I see no reason to split the windows 10 edition. (And a response to the likely argument of "they have slightly different features", I will say so do current and next gen console when it comes to the console edition, and I do not see that split.)

@MarioProtIV: I highly doubt the developers are going to not release the same builds on Windows 10 in future update, those have proven a much more stable method of releasing updates. In any case, I don't think we should completely split everything based on an assumption of the developer's plans. If it actually happens, then I might agree to split. –KnightMiner · (t) 20:09, 12 August 2015 (UTC)

For the template, this may be a good example: [snip] --MarioProtIV (talk) 20:36, 12 August 2015 (UTC)

@MarioProtIV Agree I agree, except I believe the top should be like this: [snip] Note Windows 10 being under AlphaTySkyo (talk) 21:12, 12 August 2015 (UTC)

To quote Dinoguy above: "I don't care about the minutiae of implementing the decisions; that can be left to new discussions on the article talk pages themselves; what I want to see is a final decision on what those articles will be in the first place." This discussion is only about whether we should treat windows 10 as a separate edition. If and only if we agree to treat it as a separate version should we start discussing how we perform the split.

You both have already stated what you think should be done, but for the sake of a resolution, instead state why you think it should be done, give me direct reasons as to why we should split. As it stands, I still disagree with the split, and showing me another way to implement it will not change my mind. –KnightMiner · (t) 21:44, 12 August 2015 (UTC)

I think they should be split because of the following:

Splitting would prevent a huge clutter on the version pages (this is for my sake apparently). It would also make the original 0.12.1 page more consistent with the other major update pages for the original MCPE.
Splitting would also make it consistent with the other editions of Minecraft, just like how Pi Edition has its versions split into separate pages, even though it is based/built of off PE Alpha 0.5.0.
It would create less clutter in the template as well, as listing the Windows 10 Edition versions in the original MCPE versions template, which just creates arguments/confusion.

Alas, if we decide not to split at all, we could do the following:

Pocket Edition Alpha 0.12.0 would be restored to the revision before it was merged with the 0.12.1 page.
Pocket Edition Alpha 0.12.1 would remain unchanged, just with the removal of the 0.12.0 release early for Win10 and the removal of the Windows 10 stuff.
Pocket Edition Alpha 0.12.0.1 can be recreated.
The template I explained above could be implemented.

Keep in mind if we decide to do the second option, on the 0.11.0 page (and sub-pages), it should still be necessary to have the nextparent thing link to 0.12.1 as it is the next major update to the original MCPE platform. But this is where people say "0.12.0 comes before 0.12.1 so it should be the parent version instead of 0.12.1." I have a solution for this. We can treat 0.12.0 and 0.12.0.1 as "pre-releases" (NOT OFFICIAL ONES), and we could add that to the version navbox. --MarioProtIV (talk) 22:16, 12 August 2015 (UTC)

As for the clutter on version pages, I think the only case of that would be on 0.12.1, which I agree should have the Windows 10 exclusive updates split from, basically as it was before 0.12.0 and 0.12.1 were merged.

As for the consistency part, I will point out that we have all the console editions merged, along with all the other pocket editions. The pi edition is an exception, as when it was released, it was never stated as part of the pocket edition, and did not contain all features from PE. In contrast, the console editions and all other pocket editions always received an exact or slightly better version of the relevant edition, and the Windows 10 edition is no exception.

With the navbox, it is not really cluttered from two exclusive versions; clutter would more likely be five to seven exclusive versions with no common releases. I would agree to split if 0.13.x/beta 1.0 keep the same format, but overall I think it would be easier to split at a later date if the update format changes, then to merge it the versions again if it does not.

Lastly, as a response to nextparent, it technically was an official release, but since most of the main update stuff would be covered on 0.12.1, I would agree to just linking 0.12.0 in the "next" field on 0.11.2 and calling 0.12.1 the next parent release. (I would still leave it first in the navbox though, as the parent release is already highlighted there pretty good.) –KnightMiner · (t) 00:01, 13 August 2015 (UTC)

I believe that Pocket Edition and Windows 10 Edition should be seperated and considered different versions as:

Mojang brands the Windows 10 Edition as a separate edition from Pocket Edition unlike Android, iOS, and Windows Phone
They already have different versions (ex: 0.12.0.1) and separating the versions would cause less confusion for readers and editors
While Windows 10 Edition is basically Pocket Edition is is still different in some ways:

Uses a Xbox Live/Microsoft Account
Has Multiplayer over Xbox Live
Multiple control schemes (Touch, Controller, Keyboard)
Has a built in GameDVR
Has a player feedback mechanism

This basically means that there would be a seperate template for the Windows 10 Edition versions, seperate version pages for Pocket Edition and Windows 10 Edition(even if there are some versions that are the same, others still might differ) a seperate box for the Windows 10 Edition on the main screen ect.

I also think this should apply for the future HoloLens Edition as it will have some differences from Pocket Edition and Windows 10 Edition and is branded as a seperate edition like the Windows 10 Edition. Wolffillms (talk) 20:26, 13 August 2015 (UTC)

While this is conceiving and a good reason, I feel I need to reiterate this again: Windows 10 is Pocket Edition, because they can play with PE players in the release that co-launches with 0.12.1 on mobile. Also, this should be in the discussion above, since it regards the 0.12 issue. --MarioProtIV (talk) 21:49, 13 August 2015 (UTC)

I am aware the two versions are pretty much the same, but it is still branded as a different version, has some different versions, and is slightly different in some ways. Wolffillms (talk) 22:55, 13 August 2015 (UTC)

Please read the discussion above and direct all discussion on this topic to it. There is no point in having the same discussion in multiple places. –KnightMiner · (t) 22:29, 13 August 2015 (UTC)

I have read the discussion above, however all it is, Is going back and forth if the version article 0.12.0 should be split or not. I am talking about how Pocket Edition and Windows 10 Edition should be split. Wolffillms (talk) 22:55, 13 August 2015 (UTC)

Then this should be added to the discussion above for precisely those reasons. No split has been decided upon, so it is pointless to add to the same controversy in a seperate section. -Illidicia (t+c) 03:08, 14 August 2015 (UTC)

I think just simply having it the way it is now, while a bit cluttered, is the best solution. Ultimately future versions are most likely to be the same as on the Pocket Edition, and I think separating out these two Windows 10 versions will lead to more confusion. –Goandgoo ᐸ Talk
Contribs 07:28, 14 August 2015 (UTC)

Agree, and those two pages (0.12.0 and 0.12.0.1) can be re-added if we go through with this. --MarioProtIV (talk) 13:07, 14 August 2015 (UTC)

Disagree While the major updates will probably be the same, they will probably have different bug fix/minor updates (ex: 0.12.0.1) and there is still a chance of major updates being released on different dates (ex: 0.12.0). Also all of the above still applies "it is branded as a different version, has some different versions, and is slightly different in some ways". Also I fail to see how having them separate will cause more confusion, wouldn't having it less clustered be less confusing? Wolffillms (talk) 13:45, 14 August 2015 (UTC)

Disagree 0.12.0 as well as 0.12.0.1 are separate updates from 0.12.1 and in the style guide it specifically says under article creation that each update gets a page. Also, this very similar to 0.11.2, and while this update was for only one platform it still got it's own page; this update is no different. Ergo, it should get it's own page.

File:Grid Spawn Shulker.png TySkyo (Talk•Contribs) 01:13, 15 August 2015 (UTC)

Would any other admins like to state their opinions on whether we're going through with splitting or keeping as is? --MarioProtIV (talk) 13:55, 16 August 2015 (UTC)

@MarioProtIV: Agree Admins should approve this. File:Grid Spawn Shulker.png TySkyo (Talk•Contribs) 22:18, 16 August 2015 (UTC)

I'm gonna take a guess everyone is siding with keeping as is now, if this is the case I can re-create the PE 0.12.0/0.12.0.1 pages. @Dinoguy1000: is this going to be the conclusion on what we're doing with the 0.12 pages? --MarioProtIV (talk) 17:29, 17 August 2015 (UTC)

Tagalog code

The Tagalog translation project currently uses the "ph" code. As stated on the project talk page, this is a bit... strange, as the Tagalog language uses the ISO 639-1 code of "tl", which is what is used on Wikipedia as well as my wiki, the Feed The Beast Wiki. Anyway, I'm proposing Tagalog translations should be moved to reflect the ISO standard, rather then what it is currently using (there aren't many Tagalog translations, so it should be easy to patch em' up without bots). -Xbony2 (talk) 00:46, 14 August 2015 (UTC)

Agree, assuming your information is correct. The Blobs 01:35, 14 August 2015 (UTC)

I'm guessing whoever started the project mistakenly used the ISO 3166 country code for the Philippines, whose official language, Filipino, is basically a formalized version of Tagalog. Needless to say, I Support this, and honestly don't think you need to wait to make sure there's consensus for this change, since it's a purely procedural one to bring the project into line with SOP. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:01, 14 August 2015 (UTC)

Welp, I'll give it a day unless anyone has objections to say, and start moving stuff then. -Xbony2 (talk) 21:03, 16 August 2015 (UTC)

Moving complete :) I left behind the redirects, just in case- since "ph" isn't used as a language code, it shouldn't be in the way of anything. -Xbony2 (talk) 16:15, 17 August 2015 (UTC)

Thank button

Hey neat, when did we get a 'thank' button on the revision-difference page? – Sealbudsman (Aaron) ^T/_C 19:24, 19 August 2015 (UTC)

ObelusPA2 requested it for the French wiki, and I also stated in that topic that I'd wanted to use it every once in a while. –KnightMiner · (t) 20:02, 19 August 2015 (UTC)

Well then thanks, you two! I always liked the atmosphere of friendliness that button can foster. – Sealbudsman (Aaron)

^T/_C 20:24, 19 August 2015 (UTC)

How does it even work? The Blobs 02:17, 21 August 2015 (UTC)

If you see an edit that you really appreciate, simply click the "Thank" button and it will notify the user that you appreciate their edit. See mw:Extension:Thanks for more information. –KnightMiner · (t) 02:25, 21 August 2015 (UTC)

I thanked Majr for this edit, it seemed appropriate. =D 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:36, 21 August 2015 (UTC)

Such a good idea, thanks:)-Swawesome75.76.97.188 23:47, 27 February 2016 (UTC)

Move pages to singular form titles

At the moment, the wiki is slightly inconsistent when it comes to pluralisation of page titles. The majority pages are singular (e.g. Redstone circuit, Attribute, Skin, Texture pack), however many are pluralised. I suggest changing the following: (pages with strikethrough have been moved)

Achievements --> Achievement
Languages --> Language
~~Status effects --> Status effect~~
Renewable resources --> Renewable resource
~~Chunks --> Chunk~~
~~Mobs --> Mob~~
~~Blocks --> Block~~
~~Items --> Item~~
Commands --> Command
Formatting codes --> Formatting code
Key codes --> Key code
~~Screenshots --> Screenshot~~
~~Models --> Model~~
~~Capes --> Cape~~
Mods --> Mod

I am currently unsure of the following:

Materials --> Material
Data values --> Data value
Statistics --> Statistic
Drops --> Drop

It would be great to get feedback and a community consensus for these changes. –Goandgoo ᐸ Talk
Contribs

I absolutely disagree. In some situations, referring to something in plural form as a whole in a title can be useful. — Agent NickTheRed37 (talk) 13:18, 21 August 2015 (UTC)

I understand where you're coming from, which is why there are pages in the "I'm currently unsure" category. However, the problem lies in that we have inconsistencies between certain pages being singular, and others that could equally be singular but are plural (e.g. why is attribute singular but status effects plural, why is skin singular but capes plural, etc). –Goandgoo ᐸ Talk
Contribs 13:24, 21 August 2015 (UTC)

Oppose per NickTheRed37. -BDJP ^(t|c) 13:29, 21 August 2015 (UTC)

#1, Is there precedent for this on other wikis?

#2, What about the opposite: moving them all to plural? Most of the ones you suggest seem more natural to state as plural. (personal opinion.) Do the other ones (you say most are singular) read well as plural? – Sealbudsman ^talk/_contr 14:36, 21 August 2015 (UTC)

I vehemently oppose any general proposal to move pages to plural names; it is wholly unnecessary and leads to increased complexity in linking, due to the inevitable impulse many editors have to avoid redirects where possible (and before anyone tries to say "that won't happen here", I have seen it happen on a wiki that decided to use plural page names; it continues to happen now, and every time I see an edit making that change, I cringe). And there absolutely is precedent for using singular page names: Wikipedia calls for singular page names as the norm, not the exception. Specifically, I support moving to a singular title the following pages: Status effects, Chunks, Mobs, Blocks, Items, Screenshots, Models, Capes, Mods; I am uncertain of Drops, but I feel the rest of them fall under one of the exceptions listed on Wikipedia's naming guideline, which I see no reason for us to diverge from (though if you think you have a compelling reason, you're welcome to try to persuade me). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:59, 21 August 2015 (UTC)

What you have listed makes sense to me. Several of the plural titles just sound odd as singular, and I think the reason is because they focus on the list rather than focusing on the title topic and simply providing a list.

As for Drops, I also am unsure about it, and even with my above definition it could go either way. –KnightMiner · (t) 01:41, 22 August 2015 (UTC)

What are the objections with moving renewable resources to its singular form? Also should particles stay plural or become singular? –Goandgoo ᐸ Talk
Contribs 02:56, 22 August 2015 (UTC)

With Renewable resources, my main issue is that the article is mainly about listing all the renewable resources, rather than describing to the player what is a renewable resource. It is sorta like a category in the end.

~~As for particles, while most of the article does contain the list of particles, its focus is describing a particle to the player, similarly to blocks.~~ I may be getting a little nit-picky here though, as my requirement is basically me attempting to explain why one title sounds weird to me as singular and others do not, so it could use improvements... –KnightMiner · (t) 03:57, 22 August 2015 (UTC)

If you read between the lines of Wikipedia's policy page, it's basically saying that nouns that are always used as plural or mass nouns should have a plural title. With that much more straightforward definition in mind, it doesn't make sense to move Particles to Particle, since they are always talked about in plural (no one ever talks about a single particle, because the game never produces one particle at a time). But that particular case is still a bit hairy, and I'm kind of expecting someone to disagree with me on it. =) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 05:18, 22 August 2015 (UTC)

Ok, seeing we are simply following wiki naming conventions, I think I can safely move those pages that you mentioned. We can continue to discuss some of the other pages which are slightly more contentious. I think drop should be singular as drop is often referred to as singular. –Goandgoo ᐸ Talk
Contribs 07:46, 22 August 2015 (UTC)

I've moved the pages suggested above with the exception of Mods, because it has around 1000 subarticles which would probably be a nightmare to move. –Goandgoo ᐸ Talk
Contribs 08:08, 22 August 2015 (UTC)

I should be able to get my bot to do that, but since it is such a major change (due to the thousands of articles, plus the style guide requiring mod articles as subpages of mods), I want to wait until we are sure people agree with the move, even if the move is to reflect naming conventions. As a start though, I agree with the move. –KnightMiner · (t) 14:33, 22 August 2015 (UTC)

That does sound more reasonable then what I had, and I don't disagree with keeping particles under the current title. –KnightMiner · (t) 14:33, 22 August 2015 (UTC)

Strong oppose These pages are about mechanics that have multiple types. Moving them would mislead. I think Renewable resource should be moved to Renewable resources. The Blobs 23:03, 22 August 2015 (UTC)

Can you specify which proposed moves you're opposed to, or whether you're opposed to all of them? 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:10, 23 August 2015 (UTC)

All of them. The Blobs 02:15, 25 August 2015 (UTC)

There honestly hasn't been any good counterarguments for these page moves. I think we should discuss whether Renewable resource should be moved to its plural title (I was unaware of it already being singular), whether we should move Mods to Mod and Drops to Drop. –Goandgoo ᐸ Talk
Contribs 08:12, 25 August 2015 (UTC)

@Blobs2: Before you disagree with all of them, please note the style guide requires all titles to be singular, so unless you have a proposed amendment to the style guide to cover a common trait of those pages, they are just going to have to be moved to a singular title later to comply with the style guide. That being said, I think the criteria that Dinoguy proposed of "nouns that are always used as plural or mass nouns should have a plural title" sounds good.

@Goandgoo: Renewable resource and Drops both make sense as plural since they are almost always referenced in plural; you rarely see reference to a renewable resource outside of the category of renewable resources, or a drop without other drops present. And I have already stated my opinion on the mods article above. –KnightMiner · (t) 14:20, 25 August 2015 (UTC)

There are some articles which refer to the item being a renewable resource, and while it may not appear often, it still does make sense when used in context. Therefore I still think Renewable resource should remain as is. Drops should definitely stay plural as it is basically always used in the plural form. –Goandgoo ᐸ Talk
Contribs 08:30, 28 August 2015 (UTC)

In that case, I would agree with keeping the current renewable resource title. –KnightMiner · (t) 14:40, 28 August 2015 (UTC)

Actually, I Agree because that is how it is done with other articles (such as Spider). The Blobs 22:01, 29 August 2015 (UTC)

Alex skin variations

Can someone please upload the variations of the Alex skin from the default skin pack onto Skin? - MinecraftPhotos4U (talk) 19:09, 2 September 2015 (UTC)

I'm pretty sure there's already an image called Alex.png. Also, I'm not sure what you mean by uploading a file to a page. The Blobs 14:21, 3 September 2015 (UTC)

The console edition has the default skin pack, which includes seven differently dressed variants of the default skin. They've been out for a while and have not been uploaded to the wiki. If you look at the skin page and lick Show next to Default Skin Pack you'll see what I mean. - MinecraftPhotos4U (talk) 19:56, 3 September 2015 (UTC)

Catalan Wiki

Hello,

I would like to open a Minecraft Wiki in catalan language. I know this project, but if we don't have an own wiki we won't get new contributors. My question is, what I have to do or how many pages must the catalan project have on this wiki to obtain the subdomain? Cheers, --NeoMahler (talk) 11:30, 8 September 2015 (UTC) edit: When I try to create a page in catalan, it appears a message that says:

An automated filter has detected that you are attempting to create a possibly unwanted page. As a new user, your action has been    disallowed.
If you believe your edit was constructive, please post a message on the admin noticeboard or notify an admin directly.

But I'm not doing anything wrong! --NeoMahler (talk) 11:42, 8 September 2015 (UTC)

There are a few requirements, but most notably is you must have a large enough community interest and create articles for redlinks from the main page and major navboxes. It is also worth mentioning that nearly all of the other languages started as a project here, and managed to get enough contributors before getting their subdomain.

Game widow could also likely offer a little more insight on getting a subdomain than I know.

As for that issue you are having, it means you are a non-autoconfirmed user adding things to a new article such as external links. After making a few edits (such as improving/updating earlier translated pages), that should stop. –KnightMiner · (t) 14:47, 8 September 2015 (UTC)

Well, now I was creating the Markus Persson page in catalan with only one sentence and no links, and I couldn't make it. Anyway, I will wat until I'm 4 days old and I have 10 edits. Thenks for commenting! --NeoMahler (talk) 10:50, 9 September 2015 (UTC)

There's not really enough Catalan translations to go independent, but it is possible to get that point in the future like many other projects have done. You'd probably need at least one other main editor with you as well, so if you disappeared there'd still be staff around to maintain the wiki. -Xbony2 (talk) 11:38, 9 September 2015 (UTC)

“Staff”? There’s no “editorial staff” as such on Minecraft Wiki, Xbony2! — Agent NickTheRed37 (talk) 16:35, 9 September 2015 (UTC)

"Directors", "Bureaucrats", "Administrators". Btw Nick, I can confirm mentioning via [[]] does work, as debated on my user talk page on the FTB Wiki. -Xbony2 (talk) 20:54, 9 September 2015 (UTC)

Importing data from other article

Hi. I have a some problem with one of templates, but on my other wiki about other game (non-gamepedia). I ask here, because many of you have enough experience (I hope so) to help me with my problem.

I have a 'translating' template. There is a main code http://pastebin.com/WzuDenxz, where {{{1}}} is word to translate. Translating can be bilateral (?duplex?) (it depends on second parameter in other piece of template). Example:

This is a tree, and this is a sky. This is a drzewo, and this is a niebo.

When cursor is hover bold words, translate is show up in formatted tooltip, e.g. for tree will display "pol. drzewo", and for drzewo will display "ang. tree". Everything allright? Not exactly. To add new words, you need to edit sensitive template. One small mistake = many big troubles for almost every articles.

So my question is: how I can import phrases from external source (other template/article or optionally other website)? What addon I need install? And how I can implement it to main template? Sorry for my bad English :/ Lewandowski^{pl.Wiki Admin} talk 19:19, 18 September 2015 (UTC)

Impossible. The Blobs 01:48, 19 September 2015 (UTC)

PE boats

There should be an image called Boats.gif. It would be used to show the boats in Pocket Edition on the boat page. The Blobs 17:19, 19 September 2015 (UTC)

An animated gif that cycles thru the boats like the crafting recipe on the boat page? – Sealbudsman ^talk/_contr 19:20, 19 September 2015 (UTC)

I mean in the infobox. The Blobs 22:17, 19 September 2015 (UTC)

Infoboxes support animation of multiple images, so GIF image is not necessary, all you need is just several separate images for each kind of boat. — Agent NickTheRed37 (talk) 14:51, 20 September 2015 (UTC)

We don't have all the images. It would be easier to upload one image than to upload six. The Blobs 15:05, 20 September 2015 (UTC)

What do you mean by “easier”? Do you mean quicker? Then we have MsUpload and patience. And, using separates can be more flexible, since when using a single GIF only, you would need to upload a separate image for a single kind of boat when it is needed. — Agent NickTheRed37 (talk) 15:16, 20 September 2015 (UTC)

And if another type of wood ever gets added, it is a lot harder to update as you need someone with both modeling and gif knowledge. Thus the easiest way is separate images animated like we have done almost all the other pages. –KnightMiner · (t) 20:42, 20 September 2015 (UTC)

What is the MsUpload? The Blobs 01:46, 22 September 2015 (UTC)

The "Drop files here" header on the editing screen. –KnightMiner · (t) 15:30, 22 September 2015 (UTC)

How do I make a list of pages in a category that the page is in?

I want to know how to make a list of pages in a category at the end of a page. What template would do that? Kivitoe (talk) –Preceding undated comment was added at 01:49, 21 September 2015‎ (UTC). Please sign your posts with ~~~~

{{#categorytree:Category|mode=all|hideroot}} –Majr ᐸ Talk
Contribs 03:09, 21 September 2015 (UTC)

How to make a template or make a list at the end of a page?

1). How do you make a template?

2). How do you make a list of pages in a category like at the end of this page, End City? –Preceding unsigned comment was added by Kivitoe (talk • contribs) at 3:12, 30 September 2015 (UTC). Please sign your posts with ~~~~

Writing a template can be complicated, depending on what you want it to do. wikipedia:Help:Template is a good place to start.
The list of categories a page belongs to is automatically added. See also wikipedia:Help:Category. -- Orthotope^talk 03:18, 30 September 2015 (UTC)

Replace File:Windows logo - 2012 (red).svg with

I believe that the red Windows logo should be replaced with the purple one, as the purple logo is for the Windows Phone in general, while the red logo is for a specific model, which changes all the time and all the other OS's logos are the general image, rather that the current model/OS version. Wolffillms (talk) 22:53, 6 October 2015 (UTC)

Agree Apparently, the red logo doesn't even exist. The Blobs 20:58, 7 October 2015 (UTC)

Agree Red logo was the Windows Phone 8 logo (going off of the wikipedia entry), but yes, they've retained the purple branding on the top of https://www.windowsphone.com/en-us and the bottom of https://www.microsoft.com/en-us/windows/phones – even though the current phone is the Windows 10 phone with sky blue branding. Is that where you are getting the idea for purple? The only thing I would add is that the purple logo is at slightly the wrong angle and doesn't match the angle from Microsoft; probably a new image should be captured. – Sealbudsman ^talk/_contr 21:42, 7 October 2015 (UTC)

I got the idea for the purple logo, as it is the general Windows Phone logo, rather than a specific model (red for Wondows 8 and blue for Windows 10). Also suppose a different version of the image would be better. Wolffillms (talk) 12:57, 9 October 2015 (UTC)

It requires Windows Phone 8.1, same as the Windows 10 edition require Windows 10. Should we change the windows 10 logo to a generic one too? –Majr ᐸ Talk
Contribs 13:01, 9 October 2015 (UTC)

I believe we shouldn't change the Windows 10 Edition logo, so it is not confused with the regular Windows version. Wolffillms (talk) 19:55, 9 October 2015 (UTC)

Nether Fortress in Minecraft PE

I have been looking for a fortress in the nether for over 3 weeks. Do the fortress's exist in PE?

Thanks, Garry –Preceding unsigned comment was added by Getw (talk • contribs) at 1:35, 10 October 2015 (UTC). Please sign your posts with ~~~~

Yes, they do. See Nether fortress. –KnightMiner · (t) 13:50, 10 October 2015 (UTC)

Try going east or west. You can figure out your direction in the overworked by the sun movement. Portals in the nether face the same direction as the version in the overworld. The Blobs 22:50, 15 October 2015 (UTC)

Recent guideline updates

I have noticed with the large amount of different pages on guidelines that there is no easy way for a user to keep track of what new guidelines are added, so I would like to propose adding a list of recent guideline changes to the community portal article. It would basically just be a brief summary of what changed, a link to the relevant discussion, a link to the guideline, and a timestamp, and it would contain the last five or so changes.

So the main thing I am wondering is if anyone would actually use this, or if this is just some random idea that isn't needed. –KnightMiner · (t) 22:24, 25 October 2015 (UTC)

Personally I would appreciate it. As it stands I am not usually aware of changes. – Sealbudsman ^talk/_contr 02:46, 26 October 2015 (UTC)

We can add a box for all wiki news altogether. Russian wiki has it, but it is not much used. — Agent NickTheRed37 (talk) 14:46, 27 October 2015 (UTC)

Stating historical information when a block/item is used in a new crafting recipe

Should historical information be stated for when existing blocks/items are used in a crafting recipe for a new block/item? I've noticed that the wiki is quite inconsistent in this regard, for example the iron ingot page's history table lists when iron was used to craft anvils, weighted pressure plates and iron trapdoors, but not any of the other other items/blocks listed in the Usage section. If we decide to ensure consistency, it would be a matter of looking at the Crafting ingredient subsection of Usage and ensuring that when those blocks/items received a crafting recipe, they are listed in the history table and add the relevant information to the history table. It may be worth setting up a project (just like the Rewrite for Style project) so that pages aren't missed.

I know it may seem like a minor thing, but I believe there should be consistency over the wiki's pages either way. Thoughts? Opinions? –Goandgoo ᐸ Talk
Contribs 01:40, 31 October 2015 (UTC)

I Support this. – Sealbudsman ^talk/_contr 03:43, 31 October 2015 (UTC)

Neutral I personally see it as somewhat useful information, but mainly for crafting ingredients, and overall a lot of effort would be required to add it. So overall I just vote for a consistent approach across articles, whether it be either way. –KnightMiner · (t) 03:11, 1 November 2015 (UTC)

Yeah I see you've been going to town on this. Any estimate on how far along you are? Good job by the way. – Sealbudsman ^talk/_contr 03:27, 1 November 2015 (UTC)

I've actually finished it all - I've gone through all blocks and items and it should all be up to date now. Some pages were certainly longer to do than others (e.g. wood plank, diamond, stick, redstone, iron ingot etc). But at least there's now consistency over the wiki on this though. –Goandgoo ᐸ Talk
Contribs 04:37, 1 November 2015 (UTC)

Applause! – Sealbudsman ^talk/_contr 16:42, 1 November 2015 (UTC)

Agree The Blobs 01:36, 6 November 2015 (UTC)

Quotes on snapshot pages

I was wondering what people's thoughts were on putting developer quotes on snapshot pages. For reference there's a project whose aim it is to put developer quotes on pages, and I personally like the idea. I know there was a matter of whether it was consistent or not, but I guess "consistent with what" is my question. Consistent with the status quo would lead you to remove quotes, whereas consistent with the project would lead you to add them. Depends how you look at it. I see it like the snapshot images: if there is one, put one, if not, don't put one. Same with quotes. What do you all think? – Sealbudsman ^talk/_contr 04:45, 31 October 2015 (UTC)

Agree I like the idea, it would certainly give some more interesting content to snapshots with are only bug fixes, and can help a few articles seem less like stubs. –KnightMiner · (t) 03:11, 1 November 2015 (UTC)

Agree, makes rather boring pages more interesting. –Majr ᐸ Talk
Contribs 12:53, 2 November 2015 (UTC)

Agree, added to the style guide. –Goandgoo ᐸ Talk
Contribs 07:06, 5 January 2016 (UTC)

Notch videos

We have some pages, like Version_history/Classic#References, that use youtube videos by Notch – but apparently he's recently removed minecraft videos from his account. I saw somewhere (reddit maybe?) that some other youtube user had mirrored them. What should we do; is it fine to link to the mirrored account, if we find it? – Sealbudsman ^talk/_contr 20:50, 13 November 2015 (UTC)

While a youtube account mirroring them can be useful for the references, we have no way to guarantee that they did not change any of the footage to add false references (thus every video would have to be independently checked by those who saw the original). I really don't know what the easiest way to go about doing that is, other than finding someone we know is trustworthy who uploads some of the videos, such as MCSpotlights who uploaded the first Cave Game video as an archive. (There also is the question of video copyright). –KnightMiner · (t) 00:57, 15 November 2015 (UTC)

Only use sources that are directly from Mojang (YouTube videos don't work). The Blobs 02:47, 17 November 2015 (UTC)

Bug descriptions "controversy" Part II

Well, what a nice day for a fresh start on this topic that layed dormant for over five months.

Renewing the "controversy-that's-still-eating-away-at-me-due-to-my-condition" discussion from the twenty-sixth section in archive sixteen, I'm still Opposed to changing the bug description in any shape or form. As what Munin said six months ago, rewriting titles are heavily subject to further and further rewriting by a generation of editors to this wiki. Keeping the titles as they should be can cause less edit wars and makes referencing easier. As they are quoted from mojang.com, they are immune to the grammar rules from the style guide, and per WP:MOSQUOTE, they should be quoted precisely. Those are the reasons why I opposed any changes to the bug description six months ago, with the exception of html formatting. -BDJP ^(t|c) 15:21, 14 November 2015 (UTC)

It is a nice day. What brings this up again? – Sealbudsman ^talk/_contr 15:31, 14 November 2015 (UTC)

1. Bug titles are no more subject to rewriting than many other types of wiki content, such as tutorials. If we make bug titles compliant with the style guide, we will either keep the revision as a better one, revert it for reduction of quality, or, which is less likely than the other two (and less likely than in tutorials or other places), have an edit war and a discussion about whether this edit is improvement or degradation.

2. Bug titles are no more official quotes than a Reddit post which is quoted by a developer when they write a reply to it. That this particular title is present as a quote on mojang.com does not mean (if we disregard implied rules) that we should use this particular spelling. Also, what if there is a bug fixed in this version but not written on mojang.com? Are you going to tell that an editor needs to figure out for each single title whether it can be rewritten?

3. Since when are Wikipedia manuals and rules in effect here without explicit references from local rules and guidelines (correct me if I am wrong, but I don't recall a reference to MOSQUOTE from MCW:STYLE)?

Also, if it will be decided that bug titles should not be changed, how are we going to reference that from articles which include bug fix lists? --GreenStone (judge me) 15:59, 14 November 2015 (UTC)

See the archived discussion, particularly Munin's response.
You clearly didn't read WP:MOSQUOTE, didn't you?
This edit.

-BDJP ^(t|c) 16:29, 14 November 2015 (UTC)

If we're treating the fixes as quotes, and applying WP:MOSQUOTE, that would require the use of attribution, sic for significant errors, quotation marks, "trivial spelling and typographic errors should simply be corrected without comment", and dispensing with typographical conformity – if that wiki rule is a rule we are explicitly applying in this case. MOSQUOTE doesn't seem to require as strict a character-for-character adherence as you have been advocating, if I understand you correctly, BDJP. For the record I think the standards of quoting in MOSQUOTE are better than a standard of precise quoting, as it would allow us to clean up garbage grammar, spelling, vagueness, etc. – though I'm not convinced that treating the fixes as quotes is the best idea. – Sealbudsman ^talk/_contr 17:01, 14 November 2015 (UTC)

Adding to User Greenstone's first point: there is no precedent on this wiki for locking down editing on a particular type of content with the purpose of pre-emptively preventing edit wars. Our method of preventing edit wars is the same as on all wikis, as UG alluded to.

Adding to UG's last point, I agree that if we're going to apply a new rule to lock down titles, we ought to have a disclaimer in the page itself: "Titles and bug lists are quoted from the bugtracker which has separate editorial standards and workflow, and are not to be taken as accurate lists or descriptions of what was actually fixed in this version the game" or some such. Because as it stands, I can easily imagine that a person could put an unwarranted level of trust in what the 'fixes' section says. A person who understands to what level to trust a wiki, that it is a self-improving collection of community-edited articles, is not going to immediately understand that we have chosen to not improve this content, and there is a danger there.

As for referenceability, no-one is going to change the actual reference number of the bug. Problem solved.

As for the discussion about quotations, I think that is probably the strongest point of BDJP's in my mind, because of the lack of relevant guidelines on this wiki, though my solution would be this: Put a disclaimer at the top of the fixes section that makes it explicit that the titles are descriptions and not quotes from mojang.com. That would make it easier to add explanatory comments like, "this was partially fixed but only for birch trees" or whatever. That would be a way of getting around the 'quotes' thing: declare them as not quotes. – Sealbudsman ^talk/_contr 16:33, 14 November 2015 (UTC)

Why is it bad for the wiki to be continually improved? If we lock down this, then why not just lock down the whole wiki from fixing grammar and spelling? That will really stop all those pesky edit wars we're apparently plagued with. This attitude seems generally anti-wiki.

Who says they're quoted from mojang.com anyway? There's no requirement to even use the issue tracker titles in the first place, they're just a good starting point and easier than writing your own. –Majr ᐸ Talk
Contribs 00:43, 15 November 2015 (UTC)

“	Who says they're quoted from mojang.com anyway?	„
	— Majr

Apparently, Munin.

“	@Sealbudsman, to put forth the argument you pointed out was missing: Bug titles should be immune to the normal grammar rules because they are quotes from an official website (even if the titles were originally proposed by random people, they appear now on a Mojang news post). Quotes should be quoted precisely	„
	— Munin295 on Minecraft_Wiki_talk:Community_portal/Archive_16#Bug_descriptions_controversy

-BDJP ^(t|c) 01:14, 15 November 2015 (UTC)

Well you did a good job of avoiding actually answering me. "Who says X?" is a rhetorical question. If you're going to take it as an actual question, it requires an authoritative source, of which Munin sadly isn't. –Majr ᐸ Talk
Contribs 11:34, 15 November 2015 (UTC)

No more than anyone else! Frankly, I assumed they were direct quotes because it boggles my mind that someone would not quote them precisely. On the other hand, while I stand by my previous argument, I don't actually care about this specific issue very much. —munin ·

· 21:03, 15 November 2015 (UTC)

(edit conflict)Snapshot posts often have a list of fixed bugs. However, we don't leave the rest of the release notes unedited, especially when they're unclear or nonsensical. The Mojang blog posts are a good basis for version articles, but I don't see any reason to treat that text as sacrosanct and uneditable; I'd rather have the wiki be as accurate, complete, and understandable as possible. If someone wants to see the text of the original blog post, there's a link in the references. -- Orthotope^talk 01:17, 15 November 2015 (UTC)

The majority of the users who change the title's after their addition are either new users or IPs, basically the type who would be discouraged from editing from a revert of them correcting grammar, or don't really have plans for editing beyond that quick fix. The main edit wars I do see over this topic always start with someone reverting grammar changes, then it being reverted back, each time with summaries that make no sense to a new user as they have no idea why worse grammar is preferred.

Other than that and beyond echoing what Sealbudsman or Orthotope said, I only have two other things to state. Firstly, the titles don't always properly respect the issue. A great example if this is 51447, where the title originally did not include "on smooth lighting", but was later changed as it was fixed on standard lighting. Then later it was closed in favor of separating the smooth lighting part to a separate issue, but the title never was reverted thus making it seem to a reader of the page that the smooth lighting issue was fixed.

Secondly, I think the titles are better off as a description than as a quote. A lot of times I read the snapshot pages wondering what was fixed, and I'd rather not have to click on every single bug report link just to understand what was actually fixed, instead just clicking on ones I want more information about. –KnightMiner · (t) 03:36, 15 November 2015 (UTC)

I don't believe that fixes need to be quotes. Some users (like me) notice features while playing and do not use additional research, in which case there would be no quote. The Blobs 02:54, 17 November 2015 (UTC)

GreenStone's analysis

As of now (15:25, 18 November 2015 (UTC)), I have analyzed the following approaches to the bug description problem:

Disallow any modifications to bug descriptions. Mark all sections containing bug fix lists with a template which says that bug descriptions should not be edited.
Advantages:
- This system requires minimal initial work for editors. Just copy the descriptions from the bug tracker or mojang.com, and mark the section with a "do not edit the descriptions" template.
- This system allows to immediately identify any edit which modifies any descriptions as a violation of the style guide and revert it. If my understanding of the term "edit war" is correct, this will exclude edit wars as correctness of an edit can be immediately determined.
Disadvantages:
- This system does not handle that bug descriptions on the bug tracker can be modified (they can be modified there, right?). Every edit which modifies descriptions must be verified by checking the bug tracker. See also: Rejected approaches, 1
- The descriptions on the bug tracker are of various quality, ranging from perfectly fine to garbage. If we implement this approach, we'd be essentially telling editors "These titles may be garbage, but even if that is the case, you mustn't edit them anyway". How is that a good resolution to the problem? Also note that bad bug descriptions may force a visitor to read the bug tracker page in order to get an idea of what's fixed.
Allow only minor edits to bug descriptions (such as trivial typo and spelling fixes as defined in MOSQUOTE), mark all significant errors with sic, and (probably) mark all sections containing bug fix lists with a template which says that major edits to bug descriptions should not be performed.
Advantages:
- As rules of a language are not as dynamic as generations of wiki editors, this system is capable to both require a rather small amount of work while creating little opportunity for edit warring.
Disadvantages:
- This still doesn't do much in cases of descriptions which are of very low quality and would in theory require major edits.
Allow minor edits to bug descriptions, also allow major edits if and only if the description contains an insufficient amount of information useful to editors (so, for instance, "Redstone BUg" [sic] would be edited, but "1.5 Odd Mob 'Magnetized Attraction' behavior" would not be). Also probably a message template (yes, again).
Advantages:
- This minimizes the number of major edits so that the edit war potential is minimal while the worst titles would be replaced.
Disadvantages:
- Some rather mediocre descriptions remain and cannot be edited. Potential problems may occur when interpreting "insufficient" (and I have trouble finding words that would be less ambiguous).
Full style guide compliance (so all minor edits are allowed and encouraged), and major edits may be performed whenever a description can be significantly improved. It may (not certain about this) be stated in the style guide that major edits are somewhat discouraged.
Advantages:
- This is the approach which is closest to how the wiki generally operates. This solution also does not require any templates in the top part of bug fix sections.
- This maximizes potential quality of bug fix descriptions.
Disadvantages:
- This solution also maximizes the edit warring potential. I do not find it to be a significant problem. After all, have there been any wording edit wars on this wiki within the last 2.5 years?
- This solution requires more work for editors than the other solutions.

My preferences are (in descending order) as follows: 4, 3, 2, 1.

Rejected approaches:

Same as approach 1, but without updating bug descriptions. While even easier for editors, this is far less constructive in terms of "garbage that shouldn't be edited".

Please do not edit this analysis (if it needs to be edited, I will do that myself) and post your feedback below the horizontal rule.

--GreenStone (judge me) 15:25, 18 November 2015 (UTC)

This doesn’t look as good as the final analysis of the Shulker problem, but I agree with the results. — Agent NickTheRed37 (talk) 17:13, 18 November 2015 (UTC)

Whether it looks as good as that discussion or not, thanks for linking it, it was enlightening and diverting. – Sealbudsman ^talk/_contr 18:16, 18 November 2015 (UTC)

Strongly agree with approach 1 and Strongly oppose approaches 2, 3 and 4. -BDJP ^(t|c) 17:52, 18 November 2015 (UTC)

Any specific reason why you agree with 1 and disagree with all others? Is it just based on the advantages of the first and disadvantages of the rest? –KnightMiner · (t) 23:27, 18 November 2015 (UTC)

"Is it just based on the advantages of the first and disadvantages of the rest?" Yes. -BDJP ^(t|c) 23:56, 18 November 2015 (UTC)

Per my above comment, I Agree with approach 4 (thus disagreeing with the rest). I see no reason the titles should be treated as quotes, as the only benefit to treating them as quotes is that they are the same as another website, of which the titles used on that site have no value as a quote (as said quotes are from members of the community just like the editors here). The titles may help slightly with identification, but that is really what the number should be used for. And yes, it is easier to start with the tracker's titles, but no one is forced to fix them when adding them, and there is no good reason to revert someone else's work if they decide to fix the titles up. This is a wiki after all, where the goal is to improve constantly.
On a couple more specific points, the typos and formatting used there serve no benefit to the issue, so why keep them the same? Why preserve the mistakes? Also, the title is suppose to be a description of the bug or a summary of the issue, and if the description fails to describe the issue, what is the point of adding the title here at all? –KnightMiner · (t) 23:27, 18 November 2015 (UTC)

Agree with 4. I don't see any reasons why the bugs should be immune from the style guide/general wiki convention in favour of correct capitalisation/readability. Titles like "minecart name lost" and "shulker collision box" are incredibly vague and would benefit from some proper rewording and explaining further what the bug actually is. –Goandgoo ᐸ Talk
Contribs 05:35, 19 November 2015 (UTC)

Agree completely with 4, for all the previously stated reasons. –Majr ᐸ Talk
Contribs 05:44, 19 November 2015 (UTC)

Agree with 4. –LauraFi - talk 19:05, 25 November 2015 (UTC)

Agree most with 4. I don't remember edit wars in this section ever having been a problem – people usually appreciate a constructive edit when they see it, and in case of difference of opinion there's no reason not to just figure it out on talk pages, that's always been the way. – Sealbudsman ^talk/_contr 07:30, 28 November 2015 (UTC)

Currently there are 5 people in agreement with approach 4 and BDJP007301 siding with approach 1. If there are no more responses opinions from new contributors, I think we can safely side with approach 4 at the start of the new month. BDJP007301, is your objection to approach 4 purely due to your condition rather than its merits? –Goandgoo ᐸ Talk
Contribs 03:53, 26 November 2015 (UTC)

Clearly, I would say it is due to the following disadvantages given in approach 2, 3, and 4:

Edit warring
Edit warring
Even more edit warring.

If you don't feel like you need to see my user page, let me just say that effective December 1, 2015, I will no longer be working on Fixes sections in protest of this unanimous decision to comply with the style guide in terms of "tracker titles". Personally, I feel like a couple of Mojang employees should also get involved in this discussion. I'll see if I can contact them on Friday. -BDJP ^(t|c) 04:28, 26 November 2015 (UTC)

Then, in turn, why are you worrying about edit warring? If you are tired of it, then it is just a personal matter. — Agent NickTheRed37 (talk) 16:32, 26 November 2015 (UTC)

The date is 2015-12-03. Do we need to wait a bit more? If not, can we start working on a draft? --GreenStone (judge me) 14:49, 3 December 2015 (UTC)

I feel like there is now adequate agreement among the majority of users. Would someone care to draft something for the style guide on this matter? –Goandgoo ᐸ Talk
Contribs 07:02, 5 January 2016 (UTC)

I've written up a draft below in #Proposed style guide addition. I figure it is best to be kept in the same discussion rather than branching off to a little seen talk page. –KnightMiner · (t) 15:38, 5 January 2016 (UTC)

Mojang's response

So, it appears Erik Broes has responded firsthand:

	“	I do not think we edit them a lot, we can shorten/make them 'understandable'. In reality only the ticketnumber matters.	„
		— Erik "Grum" Broes on rewriting bug descriptions

-BDJP ^(t|c) 05:56, 27 November 2015 (UTC)

A couple things in response to this:

I don't really see the need to get Mojang employees involved in this - the wiki is independent of Mojang and as such its editors should be the ones making the decisions. Other changes to the style guide have been made without Mojang intervention, so I don't really see why this needs to be an exception. Nonetheless, it is nice to see Mojangsters responding to the community and taking the time to potentially engage in wiki discussions.
Grum's response here essentially agrees with approach 4 - "In reality only the ticketnumber matters." This implies that as long as the ticket number is same, edits can be made to clear up confusion and to "make them "understandable". –Goandgoo ᐸ Talk
Contribs 00:36, 28 November 2015 (UTC)

Proposed style guide addition

Seeing as most people agreed with GreenStone's fourth approach, here is it written up as a style guide draft, with a few related things added from earlier discussions. Feel free to suggest improvements. This text would be added to MCW:Style guide/Versions#Fixes:

The titles on the bug tracker may be freely edited to comply with the style guide. While users are encouraged to fix the titles as they find them; fixing the titles is not required, specifically when first adding the issues. Editors may make major changes to the title (such as rewording the whole title), though this is discouraged unless the original title fails to adequately describe the issue.

It basically saying you don't need to go to every article and fix the issue titles or rewrite the titles as you add them, but don't stop someone else if they are doing it. It also says if you are rewriting to try and make the original wording work, but don't avoid rewording if the original title has problems. –KnightMiner · (t) 15:38, 5 January 2016 (UTC)

I support this addition. — Agent NickTheRed37 (talk) 15:56, 5 January 2016 (UTC)

Support. –LauraFi - talk 18:55, 5 January 2016 (UTC)

Support. – Sealbudsman ^talk/_contr 05:06, 6 January 2016 (UTC)

Support. –Goandgoo ᐸ Talk
Contribs 03:42, 18 January 2016 (UTC)

Sigh... Support. *Cries away in a corner* -BDJP ^(t|c) 01:07, 7 February 2016 (UTC)

Name over player's head

Is there an article that covers this, including at what range can you see the name, what affects its visibility, etc? It didn't seem to be in player. – Sealbudsman ^talk/_contr 18:09, 25 November 2015 (UTC)

I don't think any article covers this at the moment, perhaps it might be useful to state this on player. –Goandgoo ᐸ Talk
Contribs 03:49, 26 November 2015 (UTC)

It's mentioned briefly in sneaking, but a more thorough description would be worth adding. -- Orthotope^talk 04:22, 26 November 2015 (UTC)

Someone else would have to contribute the info; I don't have the opportunity to play multiplayer much, to figure it out myself. I remember being able to sneak to hide, but I don't remember all the fiddly details. – Sealbudsman ^talk/_contr 07:34, 28 November 2015 (UTC)

MinecraftEdu

The result of the discussion was that an article for the Education Edition was created. Per the website's FAQ (here), MinecraftEdu is now officially an unofficial modification to the game.

As MinecraftEdu is official as proved here and here along with the MinecraftEdu website and the TeacherGaming website, it needs to be on the Wiki as it is an officially lisenced product. The topic was debated before however it could not be agreed upon if it should be considered as an official mod or an official seperate game. I believe it is a seperate game as it has seperate features from the regular Minecraft game and is branded as a seperate game (simaller to Minecraft: Story Mode) as shown on the MinecraftEdu website which says "MinecraftEdu is a school-ready remix of the original smash hit game Minecraft. Minecraft Education Edition - Bring Minecraft to the Classroom! We provide discounted Minecraft licenses to educational institutions, a custom edition of the game with features designed especially for classroom use, and a hosting service to let users connect and play together." Please vote if you agree that it should be changed considered as a seperate game or disagree, and believe it should be considered as an official mod. Wolffillms (talk) 21:56, 25 November 2015 (UTC)

Agree for all the reasons stated above. Wolffillms (talk) 21:56, 25 November 2015 (UTC)

Oppose per KnightMiner's comments in the earlier discussion. -BDJP ^(t|c) 23:28, 25 November 2015 (UTC)

It seems as if KnightMiner did not disagree in the end, after a better source was provided. Therefore what are your reasons for disagreement? –Goandgoo ᐸ Talk
Contribs 03:39, 26 November 2015 (UTC)

Agree In addition, I don't think the page should necessarily have special requirements such as not being discussed on other pages. –Goandgoo ᐸ Talk
Contribs 03:39, 26 November 2015 (UTC)

Currently Disagree due to the ambiguous wording of the Mojang's response (I didn't realise this at the time), but am willing to agree if there is enough evidence. –Goandgoo ᐸ Talk
Contribs 05:42, 26 November 2015 (UTC)

Got better evidence https://twitter.com/mojangsupport/status/669915408816672768 Wolffillms (talk) 17:38, 26 November 2015 (UTC)

As there has been no response to this for a month, I will consider this evidence sufficient to it being a seperate game if there is no response within a week. Wolffillms (talk) 14:29, 27 December 2015 (UTC)

I do agree it is official and believe it can have its own page. –Goandgoo ᐸ Talk
Contribs 10:44, 28 December 2015 (UTC)

DisagreeThe tweet is inconclusive; due to the way it was phrased, it's unclear if Mojang is saying the MinecraftEdu product is official, or if they're merely saying that the @MinecraftEdu Twitter account is official. As previously discussed, the Mojang support page links to them only in the context of providing educational discounts, and says nothing about the MinecraftEdu product. At this point, I don't see any evidence that it should be considered a Mojang-supported product, rather than a third-party mod. If you want to convince me otherwise, get a clearer statement from Mojang. -- Orthotope^talk 04:22, 26 November 2015 (UTC)

Got better evidence https://twitter.com/mojangsupport/status/669915408816672768 Wolffillms (talk) 17:38, 26 November 2015 (UTC)

As there has been no response to this for a month, I will consider this evidence sufficient to it being a seperate game if there is no response within a week. Wolffillms (talk) 14:29, 27 December 2015 (UTC)

We really can't consider that evidence "sufficient" enough as there are three people who oppose it as such and one person who agrees it as such. You really shouldn't be disrupting this wiki to make a point. -BDJP ^(t|c) 17:57, 27 December 2015 (UTC)

The evidence is sufficient, as it does not matter the number of people who agree or disagree as there is new evidence and there is a lack of response from almost everyone involved. Also not sure what your link has to do with this discussion as 1. Wikipedia rules do not apply on the Minecraft wiki (two completely different things.) and the article doesn't even talk about saying evidence is sufficient as there has been no comment denying so for a month. Wolffillms (talk) 03:26, 28 December 2015 (UTC)

Agree with Wolffillms. –LauraFi - talk 03:36, 28 December 2015 (UTC)

I am not sure that this is point-y behavior; I can't identify any ulterior motive of the parties discussing this.

Anyway I agree that it is official and can have its own page because if you look at Wolffillms' second link here (the customer service page, not the tweets) it says that MinecraftEdu is the only such licensed non-Mojang seller of Minecraft. Whatever 'official' means, it seems to me that Mojang has set aside a unique specific legal agreement with MinecraftEdu. If it doesn't currently fit nicely within what we can put in our wiki, I would be in favor of amending the rules. To me it seems MinecraftEdu is the kind of thing that fits, and to include it doesn't appear to open a can of worms in any way because of how, on the page, it's stated that it's the only one of its kind. – Sealbudsman ^talk/_contr 19:27, 27 December 2015 (UTC)

I believe that everyone now agrees that MinecraftEdu is indeed official (however this discussion has veered all over the place :p), however the current debate is whether MinecraftEdu should be considered a seperate game (simaller to Minecraft: Story Mode) or an official mod (in which case it would be a one-of-a-kind.) Either way I'm not sure that there would need to be an amendment of the rules to allow for an article on MinecraftEdu. Wolffillms (talk) 03:26, 28 December 2015 (UTC)

False. Claiming that everyone agrees that MinecraftEdu is indeed official is deliberately gaming the system. Heck, there are three people who are still in opposition to this. -BDJP ^(t|c) 03:39, 28 December 2015 (UTC)

Again, we aren't Wikipedia. And 4 users agree. –LauraFi - talk 12:47, 28 December 2015 (UTC)

I see. ? Then I am not convinced we know whether it's developed as a separate game or whether we know it's a mod. I still think it would be fine to give it a top-level page, given the special relationship indicated at the customer service page, and just stick to the branding language they use, e.g. 'school ready remix'. I personally can't infer from their language exactly what it is. – Sealbudsman ^talk/_contr 13:57, 28 December 2015 (UTC)

Education Edition

As stated on the Mojang blog today, it seems Microsoft has acquired MinecraftEdu, and will now develop it as an official Minecraft project. With that new information I now definitely see it as notable here. –KnightMiner · (t) 15:26, 19 January 2016 (UTC)

And with this fancy piece, MinecraftEdu is now officially unofficial. We can finally lay this discussion to eternal rest. -BDJP ^(t|c) 21:54, 19 January 2016 (UTC)

1.8.8 -> 1.8.x

Could someone get a bot to change the version nav prevparent on 1.9 snapshot pages from 1.8.8 to 1.8.x? – Sealbudsman ^talk/_contr 16:28, 9 December 2015 (UTC)

Done. –KnightMiner · (t) 02:06, 10 December 2015 (UTC)

Thanks! – Sealbudsman ^talk/_contr 05:10, 10 December 2015 (UTC)

Possible bug with my userbox

Hello. Why my userbox wrote that I had the experience of 0 days, but I'm here 0.9 years. Fix this bug, please. File:Firework rocket.png Happy New Year! Regards, GRAND RADION (talk) 13:30, 26 December 2015 (UTC)

You are incorrectly calling {{gsd}}. All template parameters names must be lowercase, not capitalized at the start. Though really you don't need a userpage template for the age in days part when we have {{age in days}} which does the exact same thing. –KnightMiner · (t) 15:36, 26 December 2015 (UTC)

2016

Happy New Year! –LauraFi - talk 00:58, 1 January 2016 (UTC)

Happy New Year

–KnightMiner · (t) 04:11, 1 January 2016 (UTC)

=) click here –LauraFi - talk 04:56, 1 January 2016 (UTC)

Happy (late) New Year! — Agent NickTheRed37 (talk) 14:12, 1 January 2016 (UTC)

Please help, glitched notification

I have a notification up on my notifications bar that will not go away. I've read it already. I've logged out and back in. It's making me insane, please help.

-- DigiDuncan! (talk) File:Grid Blue Floppy Disk (ComputerCraft).png 22:49, 3 January 2016 (UTC)

That is a known bug right now. Visit Special:Notifications and it will go away (there should also be a link to that page labeled "All Notifications" on the notifications menu). –KnightMiner · (t) 15:27, 4 January 2016 (UTC)

Announcement: Official MCW App live on iOS and Android

Hello, this is a general notice that the Official app for MCW is now live on the Apple AppStore and Google Play. We plan to do a full official launch in a few weeks, but we invite everyone to check it out in the meantime! CrsBenjamin - (talk) 19:57, 11 January 2016 (UTC)

Note to all users: there are many issues with the app, causing many of the pages to not display correctly. I find it rather disappointing that despite me reporting many of these issues at the start of the development testing period, Curse's development team have basically ignored my bug reports and have gone ahead to release successive TestFlight updates without these fixes and to release the app anyway. Until these issues are fixed, I can't recommend any users to use the app. Also note that while not an issue per say, users cannot edit pages on the app. –Goandgoo ᐸ Talk
Contribs 06:15, 12 January 2016 (UTC)

We're still hard at work improving the app! The app works well for use as a reference, which is its primary purpose. Its not meant to be an editing tool and will likely never be. We released the app as a "soft" launch because we're hoping to get more users involved so we can continue to add polish in the coming weeks. Please know that your feedback is definitely being taken into consideration. Also, we took a break from development over the holidays, so that contributes to the delayed response as well. I'd encourage everyone to check it out themselves and provide feedback using the link in the app sidebar. CrsBenjamin - (talk)

06:54, 12 January 2016 (UTC)

The application for the wiki seems really unnecessary. Readers could just find the wiki website itself and read it through the browser directly. — Agent NickTheRed37 (talk) 17:20, 12 January 2016 (UTC)

I also have to say the app is disappointing. The mobile version of the browser website is ugly and buggy (I always use the desktop version on my phone), and I think there are many people who browse the wiki using their phone so an app would be a good idea. Using an app to edit articles would be a great help for editing and to gain new (potential) editors. But since this won't be possible, the app will be unnecessary and wiki authors will prefer the browser version. For a wiki reader who only wants to have a reference, the app has no advantages yet too.
I am a beta tester of the Minecraft Wiki app. Advertizements sometimes randomly pop up (really annoying, although in the latest version, ads seem to have been removed), Navboxes and galleries don't work properly yet, and you can only read articles, no talk or user pages. You can't see the recent changes. Furthermore, you can only visit the English wiki. The wikis in other languages are not readable using the app. So the app is for English users only?
In conclusion, the app is really unnecessary (and ill-conceived) as it is right now. There is no reason to use this app since it cannot be used efficiently yet. I really appreciate that Curse is working on such an app. But there is still much to be done to make this app efficient and better than the browser version. | violine1101^(Talk) 21:52, 12 January 2016 (UTC)

For the mobile view on browsers, we're limited by MobileFrontend. We'll be upgrading Gamepedia to Mediawiki version 1.26 soon and that will allow us to also upgrade to the most recent version of that extension, which hopefully will improve mobile browsing. For the app, its mainly focused on more casual users. We understand that most of you, as power-editors, will likely not be using the app, but since we're still in a sort of beta phase, we hope that we can get constructive criticism from folks here. In terms of languages, the app (and mobile) are both by domain. As of now, we haven't decided if we will be creating localized versions of the app or creating a settings/preference for language swapping. Either way, its definitely on our road-map, but as the vast majority of visitors are to the EN wiki, that's where we decided to start. CrsBenjamin - (talk)

22:40, 12 January 2016 (UTC)

I cannot test the app myself due to lacking a device that support apps, but I do support the idea; partly because I have noticed users seem to prefer an app over the mobile web version (most likely due to convenience, if not just skipping having to run web browser features that are unrelated to the wiki), and partly because there are a lot of unofficial/fake Minecraft Wiki apps out there, most of which I doubt are trustworthy but still look "real" enough to fool users. So hopefully a lot of the bugs mentioned by others will get ironed out by the official release.

I do have one question though, which is does the app currently support/plan to support an offline mode? I know the whole wiki is a lot of data to store, but being at least able to store a few favorite pages offline would be a major selling point for the app. –KnightMiner · (t) 04:33, 13 January 2016 (UTC)

We're knocking out bugs and working to improve things every day! As for an offline mode, we do have a great feature that allows users to favorite specific pages which are then cached on the device for offline use. CrsBenjamin - (talk)

16:56, 13 January 2016 (UTC)

Major issue, top of my wish list, is displaying tables directly in the page, not requiring the user press a button to view, as it currently does / recently did.

On a more positive note, I give my two thumbs up to the little floating circle nav button, that's something all of a sudden I wish was on desktop / mobile. Keep it up. – Sealbudsman ^talk/_contr 18:10, 13 January 2016 (UTC)

We recently implemented a change so that tables that fit on the page are included as well as all infoboxes. The problem is that the majority of tables are either much wider than the page by default and require awkward horizontal scrolling, or get squished into the width available on the device and then are effectively useless. This is definitely an area we'll continue to work on. CrsBenjamin - (talk)

18:13, 13 January 2016 (UTC)

Oh I see it, thanks for letting me know. – Sealbudsman ^talk/_contr 18:31, 13 January 2016 (UTC)

Pi Edition officially discontinued

Seeing that the Pi Edition has been officially discontinued (see here), I'm wondering what the effects of this should be on the wiki's pages. I know it has never been updated since its release, but I think we should no longer mark pages as Pi Edition exclusive, clearly mark that it is no longer officially supported, removed the Pi Edition mentioned features page, remove the Pi Edition version number/version history from the main page and remove references to the Pi Edition outside its own article. Thoughts? –Goandgoo ᐸ Talk
Contribs 01:38, 26 January 2016 (UTC)

I think the mentioned features page can safely be deleted, though I am a little unsure what to do with it everywhere else. We already barely cover it on most pages (skipping Pi Edition exclusive/excluded features in most cases), so it might be better to just remove references to it and cover it only on the Pi edition articles (version history, a main one, and exclusive features which can maybe be changed into just "features"), as otherwise to keep pages consistent we would have to edit every page with Pi edition features to state what is not included (for example, on water) which is just about everything and will only grow over time.

so basically, I would agree to removing any pi exclusive markers, just stating those features it as Pocket Edition removed. Likewise, I would remove references from most other pages. –KnightMiner · (t) 02:04, 26 January 2016 (UTC)

I agree. Would we still keep it on the front page? My gut says we wouldn't, but then it seems like it would be buried. – Sealbudsman ^talk/_contr 04:20, 26 January 2016 (UTC)

Ok, so these are my preferences for what should happen in regards to the Pi Edition

Remove: Pi Edition only indications (on Old, Camera, Flower#Pi Edition and other pages), Pi Edition mentioned features, version history number and icon on main page (top right), Play the Raspberry Pi Edition link on main page, link to r/MCPi on main page, Pi Edition exclusive features

Keep: Pi Edition, Pi Edition version history, Version history link on bottom of main page, entries on the history table of articles

Change: Text regarding Pi Edition on main page and Pi Edition to state that it is no longer supported.

Thoughts? –Goandgoo ᐸ Talk
Contribs 07:22, 26 January 2016 (UTC)

Sounds reasonable. If this is what happens, I don't worry about being too buried. ... And remove the link to the Pi Edition Blog from the bottom of the main page, probably, since that's already linked on the Pi Edition page? – Sealbudsman ^talk/_contr 14:20, 26 January 2016 (UTC)

I don't agree with keeping its version history. There is a single update other than the initial release which just "fixed bugs", which can just be documented on the edition's page. I would change the edition's page to document it as an isolated edition, so rather than say about difference with other editions, we just document what it does have, or start from the most similar version (e.g.: Pi Edition is similar to Pocket 0.5.0 except for X).

For the main page, I have proposed my changes for the edition boxes on the editcopy. –Majr ᐸ Talk
Contribs 02:33, 27 January 2016 (UTC)

Ok, I think we can probably just state what blocks are in the version on the Pi Edition page. I don't really think we need links to it other than in the main body of text, and we can add something like "The Pi Edition never received any subsequent updates and is now officially discontinued." –Goandgoo ᐸ Talk
Contribs 03:14, 27 January 2016 (UTC)

So basically like Minecraft 4k? I'd agree to documenting it like that, especially since I doubt most of our viewers use that edition. –KnightMiner · (t) 04:19, 27 January 2016 (UTC)

Yep, then a link to the Pi Edition can be added to the Pocket Edition template in the Versions row. –Goandgoo ᐸ Talk
Contribs 05:56, 27 January 2016 (UTC)

Would someone be able to make all links to 0.1.1 in the history table link to Pi Edition? Apart from that I think most of the changes are done. –Goandgoo ᐸ Talk
Contribs 07:33, 28 January 2016 (UTC)

Is there any reason the keep Pi in the history table? All the entries are just going to be "Added X." for a single version. –Majr ᐸ Talk
Contribs 08:01, 28 January 2016 (UTC)

True, the version table is probably not necessary at all. Other people - thoughts on this? –Goandgoo ᐸ Talk
Contribs 11:52, 28 January 2016 (UTC)

I agree to removing it, it really has no useful information that is not said on Pi Edition. A bot should be able to easily remove the section. –KnightMiner · (t) 15:09, 28 January 2016 (UTC)

We should keep the history pages, but we will note that the game is no longer updated. I used a message box like this on the main Pi edition page, which we could use as a template. The Blobs 04:07, 2 February 2016 (UTC)

Why? Both pages are completely worthless. The first version is the same info as the pi edition page, and the second version just says "bug fixes". –Majr ᐸ Talk
Contribs 04:37, 2 February 2016 (UTC)

Adding captions/descriptions to tables

The mobile app collapses tables and uses the description data attribute (and potentially the caption in the future) to describe the collapsed tables. As such, we need to add the attribute (or caption, if it is appropriate) on most of the tables on the wiki.

Category:Tables without description will be populated by pages with raw tables on them. Templates/modules which create tables will be done separately.

To add a mobile app only description, add the following to a table:

{| data-description="App only description"

To add a globally visible caption, add the following to a table:

{|
|+ Caption visible to all

–Majr ᐸ Talk
Contribs 03:07, 30 January 2016 (UTC)

The mobile app (android anyway) does display the data-description nicely, this is probably a good idea. It is awkward though when it spills over to the second line. The spacing between the lines is Too Damn High. Are you able to link the bug tracker here? – Sealbudsman ^talk/_contr 17:13, 30 January 2016 (UTC)

I don't know if there is a public bug tracker for the app, I believe you can report bugs if you're part of the beta, which I would assume you do from the app or the app store. –Majr ᐸ Talk
Contribs 04:25, 2 February 2016 (UTC)

Found it. In the app, at the bottom of the app menu is a link to the google form they're using to report bugs / take suggestions. – Sealbudsman ^talk/_contr 05:55, 2 February 2016 (UTC)

Who deals with ads

I'm curious to know, Who deals with ads here? I wonder because a person on reddit says they saw this ad here: https://www.reddit.com/r/Minecraft/comments/43gvhu/i_saw_this_advertisement_on_the_mc_wiki_today/ – Sealbudsman ^talk/_contr 03:35, 31 January 2016 (UTC)

I believe Curse is responsible for the ad networks. The Reddit post only shows the ad itself, so we only have their word that it was actually displayed on the wiki. -- Orthotope^talk 03:58, 31 January 2016 (UTC)

True, it could have been anything. On the other hand, it could have been one of the unofficial wikis too. – Sealbudsman ^talk/_contr 17:30, 31 January 2016 (UTC)

Just report malicious ads to staff and we'll send it on to the appropriate place. As stated on the reddit thread, in the case of a MC-based ad like this, you can also contact Mojang about it. –Majr ᐸ Talk
Contribs 04:23, 2 February 2016 (UTC)

Wii U edition in history tables

I just added the parameter |wiiu= to {{history}} for the console editions. It is used in the same way as the other parameters for versions, and the current articles need to be updated to include the Wii U edtion. I would just autopopulate the versions, but it is my understanding that not all Console features are in the Wii U edition yet, so a personal touch might be better.

Before they are added though, there is the question of whether to use "Patch 1", or "1" as the format for Wii U versions. "Patch 1" looks less empty, but "1" is more consistent with PS versions. –KnightMiner · (t) 22:25, 7 February 2016 (UTC)

"1" or "2" alone does not look like a version or a patch number. A "Patch" before it makes it clear that it is a patch number, so we should keep the "Patch"-prefix in my opinion. | violine1101^(Talk) 23:02, 7 February 2016 (UTC)

Need Help

Gday Guys,

Not a pro at Minecraft. Kids play it, I don't.

They have Minecraft on their XBox 360. It did an upgrade on Saturday morning (from further research I think they call it TU32). Daughter was playing in the morning all good, came back after leaving it for a couple of hours and all her worlds and my sons world were gone. Very upset. Kind of got over it by Sunday. Started a new world and this morning, same thing the world is gone. Is this happening to others? Does anyone know how they can be recovered? Can you prevent future updates happening automatically so that backups can be done.

Please help. –Preceding unsigned comment was added by Barrel49 (talk • contribs) at 7:29, 15 February 2016 (UTC). Please sign your posts with ~~~~

The forums are a better place to ask; not too many people here seem to be experts on the XBox edition. -- Orthotope^talk 10:00, 15 February 2016 (UTC)

I can't sign in

When i go to the sign in page and try and sign in, nothing happens, it just goes back to the page i was on. I also haven't got any acces to gamepedia.com and the curse website. Could that be causing the problem? -- 127.0.0.1 6:33, 2 March 2016 (UTC) 127.0.0.1 06:34, 2 March 2016 (UTC)

Your IP address is showing up as the server's loopback address, which is impossible unless you're actually editing from the server, so there is clearly a configuration issue. Are you the same person that made the contributions attributed to that IP? –Majr ᐸ Talk
Contribs 06:37, 2 March 2016 (UTC)

Since 20 August 2015 -- 127.0.0.1 10:25, 2 March 2016 (GMT) 127.0.0.1 10:25, 2 March 2016 (UTC)

Could someone help please? -- 127.0.0.1 10:54, 6 March 2016 (UTC)

A fix was deployed for this yesterday, is it working now? –Majr ᐸ Talk
Contribs 22:57, 8 March 2016 (UTC)

Nope --127.0.0.1 09:03, 9 March 2016 (UTC)

It looks like the fix was partially delayed, is it working now? –Majr ᐸ Talk
Contribs 05:06, 16 March 2016 (UTC)

Still not working. --127.0.0.1 16:43, 19 March 2016 (UTC)

Thanks for helping, its fixed now. AndrewAB (talk) 11:44, 26 April 2016 (UTC)

Adding Info to Pocket Edition Data Values Page

Hello! ThebigsmileXD has supplied some information to be added to the Pocket Edition data values page, but he's getting timeout errors when he tries to edit the page. We're unable to reproduce the error, so this could be related to location/hardware/any number of things. While we investigate the issue, the user welcomes other editors to add the information he's provided to the page! The information is: "Tripod camera 5F, Witch 2D, Minecarttnt 61, thrown enderpearl 57, minecartchest 62, minecarthopper 60 - POCKET EDITION DATA VALUES 0.14 ***IN HEX***". Thanks! BriannaMCR (talk) 21:19, 2 March 2016 (UTC)

When do we describe bugs in articles?

No, not related to arthropods. ;) I reverted this edit because it's treating a lighting bug as if it were a feature, but Araxidis re-reverted. I thought the style guide recommended to generally not detail every minor bug in the articles, but I can't find that language anywhere. Am I mistaken? Anomie x (talk) 18:45, 18 March 2016 (UTC)

There are:

Image guidelines mentioning bugs at Minecraft_Wiki:Style_guide#Images.
The Minecraft_Wiki:Style_guide/Features#History page gives a guideline about bugs in the history section.
The Issues section always directs a person to report a bug on the tracker, and not list it on the wiki.

I do recall some conversation, long ago (vague, I know, I can't even remember the particular example), where people agreed that if game behavior departs significantly from what the wiki says, so that a player could get confused and misled by reading the wiki, then buggy or not, the wiki should be corrected to reflect what the game is doing. I'm not convinced this grass path thing is one of those examples...

Even then, I think there's always going to be a question of interpretation between editors, whether certain things are bugs or not, and I think that's probably one of those things that just has to be hashed out on talk pages. – Sealbudsman ^talk/_contr 19:13, 18 March 2016 (UTC)

I don't recall any official policy discussion on bugs in the main body, though I remember the specific sectional policies pointed out by Sealbudsman, and I do believe the discussions he was thinking of was either the wolves orange collar or the wither moving when invulnerable, of which I can find no discussion, but the edit summaries seem to agree that both of them are notable since they otherwise made the wiki wrong. We really could use an official policy on this.

As for the specifics of the policy, a good starting place is a bug that changes or blocks an intentional mechanic, in which case it will just need to state the intentional and actual behavior (or mention it crashes) with a bug reference. Minor visual bugs would likely be exempt from this, as that could only really have an effect on decoration.

I am having trouble deciding where to draw the line beyond bugs changing a mechanic though, as some bugs essentially add an unintentional mechanic that was simply accepted as part of the game. A few specific examples of things we covered:

Block update detectors and the related piston bugs are widely accepted as features and I recall mention that it would not be intentionally fixed until an actual BUD exists.
The bug with slabs above ice being slippery, even though it is not the surface. By extension, there is the additional slowdown with ice below soul sand due to mobs attempting to gain traction on ice without being able to gain speed due to soul sand.
The bug with dark oak saplings removing blocks below the tree, which I say shouldn't have been covered if it were not so widely popular (which was due to the fact it could "break" bedrock, but then again so could beds in the same era)

And some we did/do not cover:

Mobs attacking through weird block hitboxes, such as block corners and doors. This bug is widely known as expected, but we simply ignore it as a bug
The pre-1.9 item elevator design with items moving upwards in blocks, again widely used (mainly in the technical community) but we did not really cover the bug behind it on the item entity page

Between what we did cover, I am currently struggling to come up with how to state the distinction between the two (it is just some feel like bugs, while some feel like Minecraft logic). –KnightMiner · (t) 04:52, 19 March 2016 (UTC)

Inconsistencies in Boat history

I have found that in the 1.9 list of changes to boats, some changes can only be found in the boat article, while others can only be found in the articles on the snapshots in which they appeared, while others still are only in the article documenting 1.9. Can you please try your best at smoothing out these inconsistencies by making sure the changes are mentioned in all three kinds of pages? VeenM64 (talk) 19:42, 4 April 2016 (UTC)

Doing I created a project in my userspace. The Blobs 01:50, 10 April 2016 (UTC)

Please make sure that the pages on the individual snapshots of 1.9 are equal to the rest as well. VeenM64 (talk) 20:02, 11 April 2016 (UTC)

Snapshots can be fixed after the project is finished. Since the user page is a project, users besides me can (and are encouraged to) work on it. The Blobs 02:30, 19 April 2016 (UTC)

The snapshots, in my opinion, are just as crucial and important as the rest. I really think you should include them, as there could be changes which are missed entirely because they only appear on the snapshot pages. VeenM64 (talk) 19:43, 20 April 2016 (UTC)

I think we agree on that. – Sealbudsman ^talk/_contr 20:18, 20 April 2016 (UTC)

I did a bunch, though it could definitely benefit from more eyes and double checking. One thing continues to bug me. Do boats go faster when you row in the right rhythm, in PE? I'm pretty sure I couldn't make it happen in PC. – Sealbudsman ^talk/_contr 01:42, 23 April 2016 (UTC)

What do you mean by the right rhythm? The Blobs 14:10, 24 April 2016 (UTC)

Before the big boat overhaul, dinnerbone tweeted "Also, you'll be able to make them go much faster by tapping at the right rhythm. Boat races will be a thing!"^[1] I personally didn't hear much about it after that, from YouTube or r/minecraft or anywhere, plus the rowing controls never seemed to respond to rhythm, but it persisted in the wiki. So I think it maybe didn't make it into the game? – Sealbudsman ^talk/_contr 15:13, 24 April 2016 (UTC)

You could test it in creative mode (if you play the PC version) The Blobs 15:25, 24 April 2016 (UTC)

Yes, after testing it, I wasn't able to tell if I was really going faster, and I think it never did work, though I was hoping others might double check. – Sealbudsman ^talk/_contr 18:24, 28 April 2016 (UTC)

You can ask other users to verify it for you on the Minecraft Forums. VeenM64 (talk) 21:29, 24 May 2016 (UTC)

I'm not a forum user, but that is a good idea in general. – Sealbudsman ^talk/_contr 22:26, 24 May 2016 (UTC)

References

↑ https://twitter.com/Dinnerbone/status/652116041594765312

New Mojang employee Christian Westman

It's on the person's twitter (https://twitter.com/westmaaan, and he announces his first day here: https://twitter.com/westmaaan/status/716864352880627712), though does anybody know of a more solid place to cite / look that would confirm this? – Sealbudsman ^talk/_contr 17:52, 5 April 2016 (UTC)

He does not appear on the Mojang twitter list or website, though since he is followed by a couple Mojang employees I don't doubt he is part of Mojang. Even so, I would personally wait for a linkable source to add an article (basically something that is not self validating, such as a welcome tweet from another employee) –KnightMiner · (t) 05:12, 6 April 2016 (UTC)

I did happen to see this Reddit comment, which led to this tweet. Anomie x (talk) 10:07, 6 April 2016 (UTC)

Well that's about as definitive as you could want. Welcome Mr. Westman. – Sealbudsman ^talk/_contr 12:01, 6 April 2016 (UTC)

and also welcome Mr. Carlson. -BDJP ^(t|c) 12:09, 6 April 2016 (UTC)

Good catch, BDJP007301. So I've just now added Olof Carlson and Christian Westman pages, and added them to the Mojang AB and Template:Mojang pages. – Sealbudsman ^talk/_contr 14:25, 6 April 2016 (UTC)

Bugs

There is a discussion about bugs for a certain page. Should pages have a section about bugs? The Blobs 17:38, 19 April 2016 (UTC)

That discussion is about the history section, which can allow bugs (see the style guide MCW:FEATURES#History) ... are you raising a discussion on whether we should allow "bug" sections in articles, or something else? – Sealbudsman ^talk/_contr 18:07, 19 April 2016 (UTC)

I mean a section called "Bugs", and it would only be about modern bugs (in all the versions). The Blobs 02:33, 22 April 2016 (UTC)

So, you mean, on each page, a current list of bugs in PC, Pocket, Console, etc? – Sealbudsman ^talk/_contr 03:07, 22 April 2016 (UTC)

What benefit would that serve over the official bug tracker? Copying the list of bugs that still exist would simply be a pain especially when the tracker lists the exact same list (only more up to date), and only listing the "important ones" begs the question of who decides which bugs are important. I think it is much easier and more productive to simply help out on the bug tracker to keep that update to date (such as checking the list of bugs related to an article to see if they still affect the latest version) –KnightMiner · (t) 04:34, 22 April 2016 (UTC)

How a block/item is worn in the helmet slot

I've seen lately, people have been adding pictures of items in helmet slots. They typically get removed because of the MCW:IMAGES rule "Images showcasing usage of specific features for decoration should be avoided."

I agree with the image rule so far as it means to avoid images of features in builds, like an end rod making part of a standing basketball hoop, or a fence gate making part of a chandelier, or a log making part of a rustic cabin. I think that the rule is intended to avoid a profusion of images of people's creative builds, and that it is a good rule for a number of reasons: such as that galleries would grow endlessly, and that imaginative use of blocks shouldn't be constrained by examples one sees in a list, and that these decorative uses are user-imagined rather than being a developer-made part of the item / block.

In contrast, I think that how a block/item is worn in the helmet slot is a first-class feature of the block / item, because the devs put in the time and trouble to position each item in particular ways. And therefore I think that it is not really subject to that rule, that those types of images ought to be allowed in the gallery, and that the rule could be clarified to some extent. – Sealbudsman ^talk/_contr 18:22, 28 April 2016 (UTC)

When the item can only be put in the head slot with commands, IMO it directly contributes to galleries being full of random mostly-useless images. Anomie x (talk) 18:35, 28 April 2016 (UTC)

Is it a general guideline that we omit things that can only be done with commands? – Sealbudsman ^talk/_contr 18:50, 28 April 2016 (UTC) ... Are things that can only be done with commands more "mostly-useless" than vanilla survival stuff? Or is it that are editors free to decide what features are mostly useless and don't need to be on the wiki? My thing is just, it's in the game, why not document it. Plus it would only be one image per page, max. – Sealbudsman ^talk/_contr 19:13, 28 April 2016 (UTC)

On the other hand if it's images that are the concern, would it be any better as text in a dedicated section in the body of the page, do you think? – Sealbudsman ^talk/_contr 19:14, 28 April 2016 (UTC)

We don't have a /summon on every mob's page. This seems like the same sort of thing.

If someone wants to make a tutorial page about putting blocks on your head, IMO that would fit in much better than spamming it on random items' galleries. And we should require that the image use the Steve or Alex skin to at least cut down on the temptation for people to show off their skins by "being" the image for random-item-on-head all over the place, same as we require that screenshots don't use custom texture packs. Anomie x (talk) 19:28, 28 April 2016 (UTC)

I agree it would be a good rule in general, that if players (apart from developers) appear in pictures, they should be the Steve or Alex skin, unless it's topically important that it's a specific player (like deadMau5 maybe?), or a specific feature of a skin.

A tutorial page, it makes sense. Putting all that stuff in one place makes sense. I would still think that page would be linked to from somewhere in the fence-gate / end-rod / etc pages? If not the usage section, the trivia section.

By and large, the blocks/items on the head render in a standard way, and I don't think it would be necessary to showcase them all, or to mention them all on their pages. I think it would be fine to show one example of the norm for blocks, say, 'stone', and one for, say, 'flower pot' – and then showcase the exceptions, those that are specially positioned. And it would be those exceptions that would be even worth a mention on the items' and blocks' pages. (In that way it would be kind of like how we already handle /summon, to use your example. When you summon any mob, it's just a normal mob, a behavior not worth mentioning on its page – except the ender dragon, whose /summon behaves unexpectedly.) So the helmet-slot tutorial page would only need to be linked from those oddball blocks and items, those exceptions to the rule.

What do you think. – Sealbudsman ^talk/_contr 20:40, 28 April 2016 (UTC)

Agree If we don't metion commands outside of the commands page, readers might get confused.

@Anomie x: Agree Although tutorials are not about the game itself, they are still important because they help people learn how to do complex tasks. The Blobs 03:25, 30 April 2016 (UTC)

Where do we put Minecraft Program Files?

I have just found a bunch of files from the different Minecraft program files folders and I was wondering where we list/showcase them on this wiki or even if we don't. Could someone please let me know! - LCSKID (talk) 00:11, 30 April 2016 (UTC)

.minecraft? What files exactly are you talking about? -- Orthotope^talk 00:59, 30 April 2016 (UTC)

Ignorance

I have a feeling that I may just be ignored by other users. I brought up a a merge suggestion and a change to a critical template, but I still get no replies. — NickTheRed37 (issues’ wall) 16:17, 11 May 2016 (UTC)

You're not the only one whose posts get ignored. I recently asked whether someone could upload some new wolf renders because the current ones are quite incorrect and noone replied. I guess that it's quite easy to be ignored on this wiki, because here is way more activity, compared to the 'localized' wikis, so new posts on talk pages could be missed in the recent changes more easily. | violine1101^(Talk) 19:14, 11 May 2016 (UTC)

It's not personal I'm sure : ) As for the Armor merge suggestion, I took note, but I didn't have enough time to read those articles for an immediate opinion, so I didn't comment yet, busy with other things on- and off-wiki. As for Template talk:Message box, that's not on my watchlist, and actually I only really check my watchlist ... sorry! That habit was originally my way of not getting overwhelmed. As for baby wolf renders, I did read that, and do agree they should be updated, but I didn't respond because I don't know how to do a render; I thought a person who could render would respond. I promise it's nothing personal! – Sealbudsman ^talk/_contr 19:59, 11 May 2016 (UTC)

"Pro" badge

Does anyone have any css code they've added to their personal page to hide this annoying badge from recent changes and signatures? –Goandgoo ᐸ Talk
Contribs 12:40, 18 May 2016 (UTC)

The following should work, though it may need tweaking in the future if anything is added to the userlinks "::before" element that you wish to keep.

.gamepedia_pro_user::before {
    display: none;
}

–KnightMiner · (t) 13:31, 18 May 2016 (UTC)

Thanks, that did the trick. –Goandgoo ᐸ Talk
Contribs 05:41, 19 May 2016 (UTC)

Go to Special:Preferences, section Gadgets, and set the “Hide Gamepedia PRO label” to on. No additional personal CSS is needed. — NickTheRed37 (issues’ wall) 14:49, 18 May 2016 (UTC)

I tried that (and am still using it). At first, the pro badges appear, then they disappear. Game widow, can you make it so that the bases don't appear at all for users who have this set? The Blobs 01:56, 26 May 2016 (UTC)

Fixed. –Majr ᐸ Talk
Contribs 02:12, 26 May 2016 (UTC)

Thanks The Blobs 02:52, 31 May 2016 (UTC)

If you want to hide the badge from others who don't have the preference set, or custom styles, you can put a space inside the link text of your signature, for instance: [[User:Sealbudsman| Sealbudsman]]. Of course it only works in your signature, and not anywhere else. – Sealbudsman ^talk/_contr 14:56, 18 May 2016 (UTC)

I was more looking for one which would hide the Pro badge from all users, so KnightMiner's code did the trick. –Goandgoo ᐸ Talk
Contribs 05:41, 19 May 2016 (UTC)

Why do we even archive by moving?

Pros of archiving by moving:

Edit history is preserved and fragmented. (Still preserved in copy-archiving, and a fragment may be possible to access by passing parameters to the history page.) Faster access to history in case such as Template:Unsigned placing (but who places this template into archives anyways? and the difference is insignificant).

Cons of archiving by moving:

Harder to archive selectively. Must move new topics out of archives.
Must perform an edit on the archive, and recreate the talk page.
A short but problematic intermediate period when the original talk page is not yet restored after a move-archive.
Old talk page history is no longer accessible (edit: correction: no longer accessible on the talk page itself).

Have I missed something crucial? --AttemptToCallNil, previously known as GreenStone (report bug, view backtrace) 15:19, 23 May 2016 (UTC)

Hmm .. sorry if I messed things up on Nether Wart Block .. I saw some more tenured people than me doing it, and I perceived that it kept archived talk together with those topics' history, and I assumed that was the desired effect. The cons associated with having to make one additional edit to move them, I consider relatively inconsequential; and the decision-making about what to move and what to keep is identical.

I realize that the (recent/current) Nether Wart Block conversation history is now fragmented, so that is something I probably should have avoided until conversations were completed.. – Sealbudsman ^talk/_contr 15:31, 23 May 2016 (UTC)

Minor correction. --AttemptToCallNil, previously known as GreenStone (report bug, view backtrace) 15:48, 23 May 2016 (UTC)

The reason I always do it using moving is just to keep the edit history with the actual code, basically the same reason page moves always are done using the move page feature. I prefer when looking at a discussion via edit history for it to still be on the actual page.

As for the cons, the first one is a case where I simply choose copy/paste moving, and the second and third I see as a minor inconvenience compared to the benefit of moving the page. As for the last one, I think the history is better synced with the page containing the topic than the original page, it keeps the page history neater (as if you leave a redirect when moving, you will always come to a point on the latest telling you where old topics are). –KnightMiner · (t) 21:54, 23 May 2016 (UTC)

I think we should still archive by moving, since the edit history appears in the same page as the discussion. Users who want to find an old discussion can use the search inputbox (this is built into the template) rather than searching each page manually, then look at the edit history of the page. The Blobs 03:07, 25 May 2016 (UTC)

iOS devices hardware performance page

On the iOS devices hardware performance page should reports for unsupported versions be removed from the section Compatible Devices, or should they be left there to help users playing on older versions of Minecraft Pocket Edition? --JimbobsDiamonds64 (talk) 00:41, 25 May 2016 (UTC)

Need some help with finishing 0.15 revamp templates + possible discussion

Hi, I think I need some help finishing up loose ends from revamping the 0.15 templates. I've revamped the template for versions of Pocket Edition to suit the 0.15 stuff and moved the realms builds to their own perspective pages. However, I may have broken a page or two in the progress, and I was wondering if some of the community (preferably well-known members and admins) could help fix that. I was sort of speedy on this, so a revert will be fine by me if that whats going to occur. Also, the discussion for this can be settled here, if thats OK. --MarioProtIV (talk) 20:17, 3 June 2016 (UTC)

Before this continues, I'm wondering whether the "Realms" builds are actually different to the non-Realms builds. From what it seems like the developers are saying, the 2nd build was released to fix Realms issues in the first build. Hence if this is the case then I think having these Realms and non-Realms builds just adds confusion and they should be merged back together. –Goandgoo ᐸ Talk
Contribs 01:26, 4 June 2016 (UTC)

Strongly agreeing with Goandgoo unless there are other alternatives. -BDJP ^(t|c) 03:51, 4 June 2016 (UTC)

Hmm. Why not move the Realms builds to the top of the template instead of with 0.15? Sort of like how the April Fools updates are stylized for the PC version. --MarioProtIV (talk) 14:52, 4 June 2016 (UTC)

Seeing there were only 2 realms builds and they were used just to test Realms, I'm thinking that it might just be better to mention them on the Pocket Edition Alpha 0.15.0 build 1 page in a section at the bottom to avoid confusion. –Goandgoo ᐸ Talk
Contribs 10:54, 9 June 2016 (UTC)

I have also noticed that you put the names of updates in fine print under the number. Is this really what we want? The Blobs 03:10, 8 June 2016 (UTC)

That is what we did on {{Computer versions}}, and it does not look bad IMO. What do you find wrong with it? –KnightMiner · (t) 13:29, 8 June 2016 (UTC)

I wouldn't say anything is wrong with it, it is just an unexpected change (especially for non-editors). The Blobs 02:23, 9 June 2016 (UTC)

Thanks to A20001017 (talk • contribs • logs • block log) for fixing the Pocket Edition Alpha Realms section (and putting it on the update page)! I was really puzzled on how to do that (I need to make the category though still).

A pleasure. :Da20001017^Talk 05:36, 10 June 2016 (UTC)

Goandgoo (talk • contribs • logs • block log): I get that but considering Realms is planned to be added in the full 0.15 release, I think leaving it as it is now may be the best option. --MarioProtIV (talk) 21:41, 9 June 2016 (UTC)

Console Edition versions

Computer Edition and Pocket Edition have a system where each version has its own page, but Console Edition has a page that includes all of e versions. The system that the Computer and Pocket editions use should also be used for Console Edition. The Blobs 02:42, 9 June 2016 (UTC)

MCT:Community portal/Archive 16#Pi Edition and further action

For a summary: find a sane way to name the articles and it would be considered. The pocket edition uses the same versio number name format for all editions, but console has them different, leading to options of:

all in the title (looks messy, hard to remember/understand)
just one in the title (causes issues for versions not on that console, treats it as more important)
every version getting separate articles (leads duplicate information)

–KnightMiner · (t) 14:18, 9 June 2016 (UTC)

Also, see MCW:Admin noticeboard/Archive 24#CEU. -BDJP ^(t|c) 20:20, 9 June 2016 (UTC)

Education Edition exclusives

We need to decide how and if we should document the Education Edition exclusive features (the chalkboards, camera, portfolio, NPCs etc that can be seen in this post http://education.minecraft.net/announce060916/). Should these get their own pages or should they just be documented on the Education Edition page? –Goandgoo ᐸ Talk
Contribs 00:36, 11 June 2016 (UTC)

[1] ttps://twitter.com/Dinnerbone/status/652116041594765312

[1]