Minecraft Wiki
This page is an archive of past discussions. Do not edit the contents of this page. 
If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Remove Spawn Chunks page

The following discussion of a proposed deletion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The result of this discussion was article is still useful and there is no need to delete it. --TreeIsLife (talk) 21:19, 9 September 2020 (UTC)

Note that I wrote my original suggestion in big hurry and i felt it was bad so I rewrote it here.

Hello. I updated chunk loading and still am and i realised how much outdated/wrong spawn chunk page was. I suggest its removal and here are my reasons:

1) Spawn chunks are not special, but normal chunks that are loaded by the world spawn that gives them "Start" load ticket. They are not special on their own.

2) They are all the same as chunks loaded by player or forceload. Something Ill edit in forceload too. They are exactly the same in every load regard, but loaded by different thing. This is because they all get load level of 31 or bellow, which makes them "entity ticking" and that is the highest level of loaded chunks. They don't spawn mobs thought, BUT that is only if and because player's area where mobs despawn/spawn is away.

3) Actually there is only one chunk that gets loaded by the spawn but the load levels spread to adjacent chunks until theyre weak enough to not load chunks. This start ticket is just strong enough that it activates lot of chunks.

4) There are more unique chunk loading things similar to spawn chunks, if we would need page for spawn chunk need another like 3+ pages which is useless.

These are my reasons, I think removing that page and seriously improving ita section in chunk page will do better. Thank you for your time. Klusimo (talk) 07:04, 9 March 2020 (UTC)

There are already a page for bedrock edition - ticking area, why not create another new page with title like processing chunk only for java edition, and move all the information about chunk loading to these two pages. Then create a disambiguation page contains chunk, ticking area, processing chunk, commands/forceload, commands/tickingarea, and so on. That Spawn chunk can be redirected to processing chunk. These are my suggestions so you could take it if you like. -Chixvv (talk) 10:50, 9 March 2020 (UTC)
Not bad idea but rather that "processing chunk", i think Chunk loading would be better. But I think its too complicated when we have it in chunk page (also not much would be left in the chunk page). In both scenarios removing spawn chunk page is what would be optimal.Klusimo (talk) 11:09, 9 March 2020 (UTC)
i think Java edition and bedrock editon should not be treated differently. so we can merge ticking area to chunk, or create a new page for java edition. since there isn't much useful information in ticking area(it only introduces that in ticking area events are processed and other chunk not), perhaps merge ticking area to chunk is also a choice. In doing so, both spawn chunk and ticking area page should be removed.-Chixvv (talk) 11:39, 9 March 2020 (UTC)
Agree, I will definitely add it there. So now we also have suggestion to remove ticking area once i merge it. forceload should be removed too. Klusimo (talk) 08:07, 10 March 2020 (UTC)
Added ticking area to chunk page. Now we only need to remove spawn chunks forceload and ticking area page. (Definitelly not their command pages).Klusimo (talk) 08:33, 10 March 2020 (UTC)
Ok, so update to my suggestion, since their pages are stubs and it is already in chunk page now, i suggest removal of spawn chunks/forceload/ticking area pages(not their commands pages though). Klusimo (talk) 08:35, 10 March 2020 (UTC)
 Strong oppose deleting these pages, at least with Chunk's current state. Spawn chunks are only described by the brief start ticket section. To figure out how the spawn chunks work, a reader has to read technical information about chunk levels and level propagation. The spawn chunks page may need updating, but it readily provides the size of spawn chunks, what runs in spawn chunks, and where entities work in the spawn chunks. I don't think all of this information is easily available on the chunks page. There is not enough information about ticking area either. The ticking area page provides information about which events can run and which events are suspended that isn't described on the Chunk page. While it would be possible to merge more information into Chunk, I don't know if that would be a good idea as I feel like it would make it more difficult to find information.
Instead, I would say that the Spawn chunks page should be updated with more recent information. It should be explained that the spawn chunks have a level of 22 which means that "All game aspects are active." A table or image should be made which shows level propagation in the spawn chunks. It can then be explained how the edges of the a spawn chunks do not process entities since they have a level of 32. All of this should link to the Chunk page for more a thorough and technical explanation. jahunsbe (talk) 19:12, 12 March 2020 (UTC)
I get what you're saying but instead of that you can create section in the chunk page. Its a stub after all now and it needs a lot of testing, editing etc. so we can easily add more info about spawn chunks here. The thing is you can update several pages or have one page with all the info. It just needs more edits. You can contribute yourself. Klusimo (talk) 08:51, 14 March 2020 (UTC)
 Comment I'd oppose deleting it on the basis of "it's short and incomplete/outdated". The solution should be to update and expand the article, not remove it entirely. -PancakeIdentity (talk) 19:23, 3 May 2020 (UTC)

Removal of the Java Edition part on snapshots and Bedrock part for beta.

The following is a closed rename. Please do not modify it. Any editors wishing to make further comments should start a new topic.

The result of the discussion was no change. There was an enormous discussion about this and the turnout was  Change for consistancy, doing it because it's unique is very feeble and weak statement.---Humiebee Discuss anything with me Look at my edits 21:00, 8 September 2020 (UTC)

In the snapshots and betas, the title includes the edition's name (e.g. java edition 20w28a and bedrock edition beta This isn't needed as there are only snapshots in Java and betas in Bedrock. Also, most of the links to the page are just the snapshot and beta part (20w28a and beta The wiki should remove the Java and Bedrock part and just have the name of the snapshot or beta-like the development versions on the left side and the history section on pages. --Minecraft loot (talk) 01:15, 13 July 2020 (UTC)

We had a massive discussion about this last year. It would be incredibly confusing to have to guess what version you're clicking on, and that's hardly future proof, so it's better to just be explicit whenever possible.  Nixinova T  C   01:26, 13 July 2020 (UTC)
 Oppose I think it just looks a lot neater when it's like that...It helps people who are new to the Wiki and Minecraft understand if it's Java Edition or Bedrock Edition. Also, it just looks formal. 14:00, 17 July 2020 (UTC)
 Oppose per previous discussions and Nixinova's comment. -PancakeIdentity (talk) 04:12, 21 July 2020 (UTC)

Having old sprite textures on, for e.g, snapshot pages

The following discussion of a proposed Legacy sprites is closed. Please do not modify it. Subsequent comments should be made in a new section.
Started again in this discussion. --TreeIsLife (talk) 21:08, 9 September 2020 (UTC)

Hello, should we use old sprites textures for old content like snapshots before Texture Update ?

Thank you, 10:04, 20 October 2019 (UTC)

All visual content such as screenshots and renders should have up to date textures whenever possible. The only exception is when displaying content that is exclusive to an older version. -PancakeIdentity (talk) 17:21, 20 October 2019 (UTC)
OK then, I will take in charge some snapshots. 12:34, 21 October 2019 (UTC)
 Agree Up-to-date content should be used on non-historical pages/sections. Version pages are historical pages, and therefore it would make a lot of sense for images to remain accurate to that version, which can be more easily done with images being separately versioned now. MajrTalk
08:22, 4 November 2019 (UTC)
Worth noting that this will likely be somewhat decided by this discussion. If we decide to keep and use legacy sprites, yes, they should be used for historical uses. -PancakeIdentity (talk) 04:41, 20 May 2020 (UTC)

Account weirdness

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

so i was logged in before the migration, and that account had more than 500 edits. There was no one on fandom with the same username. I was logged out like expected but when i tried to log in using twitch, it failed. 13:03, 25 July 2020 (UTC)

Then, there is problem in your Twitch account --TreeIsLife (talk) 22:31, 9 September 2020 (UTC)

@ instead of § for specific destinations in a page.

The following is a closed discussion. Please do not modify it. Any editors wishing to make further comments should start a new topic.

The result of the discussion was no change. Nonsensical proposal. § is used to refer to sections.  Nixinova T  C   21:59, 4 September 2020 (UTC)

I think that instead of using a sigma (§) we should use an @ symbol. 08:31, 27 July 2020 (UTC)

Why? I don't feel super strongly, but I think § looks better and I don't see a real reason to change it, so  Oppose for now. -PancakeIdentity (talk) 08:33, 27 July 2020 (UTC)
 Oppose, it's not a sigma, it's a section sign. Is @ ever used for this purpose? --AttemptToCallNil (report bug, view backtrace) 08:34, 27 July 2020 (UTC)
 Oppose @ is mostly used for pinging others, and I don't see why we should change the section sign.--skylord_wars (talk) 10:46, 27 July 2020 (UTC)
 Comment How about #, because it is consistent with the url, which uses #? Blockofnetherite Talk Contributions 23:57, 2 September 2020 (UTC)
 # and § are used actually---Humiebee Discuss anything with me Look at my edits 01:20, 3 September 2020 (UTC)

Is there a short for the User in User:Blockofnetherite, for example? If so, can we add one?

The following is a closed question about User pages. Please do not modify it. Any editors wishing to make further comments should start a new topic.

The result of the discussion was the question was answered. No. Blockofnetherite Talk Contributions 21:40, 9 September 2020 (UTC)

I wonder if there is a short version of typing the User in User:Blockofnetherite. If not, is it possible to add a short for it, like U:Blockofnetherite or something? Any thoughts? Blockofnetherite Talk Contributions 03:55, 21 August 2020 (UTC)

The only shorthands are for this namespace and its nontalk equivalent. Saving three characters really isn't necessary anyway.  Nixinova T  C   03:57, 21 August 2020 (UTC)

Apparently lossy compression was applied to all images (including all revisions) on this wiki

The following is a closed discussion. Please do not modify it. Any editors wishing to make further comments should start a new topic.

There is lossy compression applied to ALL images (including revisions and lossless file types) and I think it has to do with the media migration. Is this temporary or is this permanent? Fadyblok240 (talk) 03:27, 19 August 2020 (UTC)

I've also seen some svgs look blurry, like the Minecraft Wiki header in the main page, or hearts on Health since the migration. -- Unavailablehoax (talk) 11:18, 20 August 2020 (UTC)
For me, sometimes the images just don't render at all.---Humiebee Discuss anything with me Look at my edits 16:31, 20 August 2020 (UTC)
It appears that image scaling is kinda broken.
Scaling problem.png
This image of Mclogo.svg is supposed to be scaled to 295px in width, which can be seen in the url. However, the image is actually 331px in width. --Unavailablehoax (talk) 22:34, 21 August 2020 (UTC)
Also, it should just use the original svg instead of a png conversion --Unavailablehoax (talk) 22:37, 21 August 2020 (UTC)
Okay, so this is almost DEFINITELY a problem with the migration.
Migration problem.png
In the Bedrock Edition page, the images that are blurry are from the new url (static.wikia.nocookie.net) and images without this problem are using the old url. (gamepedia.cursecdn.com) You can check what url an image is from by right clicking it and selecting 'Copy image address' (At least on Chrome) --Unavailablehoax (talk) 23:11, 21 August 2020 (UTC)

Template:Schematic uses outdated sprite sheet

The loss in image quality has been mostly resolved, but the template uses an old revision of File:SchematicSprite.png. I first noticed the discrepancy when I removed the corner stairs from the sheet and put tree blocks in their place. However, when I added the samples of the new IDs for tree blocks in the documentation, the intended sprites would not show up and instead be replaced with corner stairs or nothing. I think this problem is related to the media host migration. Fadyblok240 (talk) 04:36, 24 August 2020 (UTC)

Oh, I've talked about this problem at the admin noticeboard for {{BlockSprite}} and {{InvSprite}}, and while I really don't know how these stuff really works, AttemptToCallNil could help. – Unavailable Hoax (talk) 12:20, 6 September 2020 (UTC)
Does it work now? --AttemptToCallNil (report bug, view backtrace) 18:09, 6 September 2020 (UTC)
It seems to work now, but I don't know how it was fixed. Fadyblok240 (talk) 10:39, 8 September 2020 (UTC)

Humiebee for admin

The following is a closed discussion of a proposed declined by Humiebee, plus opposition. Please do not modify it. Any editors wishing to make further comments should start a new topic.

The result of the discussion was declined by Humiebee, plus opposition.

I think he is a constructive user so can we promote him into an admin TheGreatSpring (talk) 09:03, 8 September 2020 (UTC)

 Oppose, simply because they've only been here since this June (old account)/July (new account). They've simply not been on the wiki long enough. FVbico (talk) 09:25, 8 September 2020 (UTC)
ok TheGreatSpring (talk) 09:27, 8 September 2020 (UTC)
I agree with FVBico, i have been on this wiki since may, i am the same level as humiebee, and i dont feel ready to be admin yet. James Haydon (talk) 14:00, 8 September 2020 (UTC)
 Oppose Sorry, but i can't agree. I am on Minecraft Wiki (counting my old account) more then 2 years, and i still did not have any ranks. And i've been editing even on Wikipedia. He received autopatrol for 2 reasons
  1. Of course, many verified edits
  2. Well, on other hand there was so much edits, that it makes inpossible to catch vandallers.
Administrator is not like constructive user job. Here, you need to know, how to manage wiki. Also, it is harder, because you need to know, what tools can be used in what situation. Well, if this was not in case, it will be like on Fandom wikis. Users block other users, because they don' t agree, or simply, because they are reverting vandalers edits. So vandaler got 3 weeks, you 1 year.
One note: I am actual Admin on one Gamepedia Wiki, so i know, how hard it is. --TreeIsLife (talk) 14:11, 8 September 2020 (UTC)
 Oppose for now. Still too new. Simply being constructive isn't sufficient. I am an admin on the English Wikipedia, and I consider myself quite an experienced editor here, but I don't yet feel qualified to be an admin here. There's more to it than simply working on the wiki content. And what does "level" have to do with anything? ~ Amatulic (talk) 14:41, 8 September 2020 (UTC)
I completely  Oppose myself, you promote a patroller, not an auto patrol, also you promote someone who's had at least like 3 yrs of experience and why? Like that's such a borrrring reason, contructive? There are hundreds of contructive users on this wiki and many are autopatrol but an admin? you joking.---Humiebee Discuss anything with me Look at my edits 19:17, 8 September 2020 (UTC)

Adding images to templates

The following is a closed discussion of a proposed Adding images to templates. Please do not modify it. Any editors wishing to make further comments should start a new topic.

The result of the discussion was Added.

Edit [1]. Should we add image to {{Stub}} template? --TreeIsLife (talk) 08:02, 2 September 2020 (UTC)

 Support, but it will better, if there will be another image. --TreeIsLife (talk) 08:02, 2 September 2020 (UTC)
I  Support images on every message box, but only if they are fitting. I don't see how an allow block is fitting for a stub template. Is there even a fitting image for this one? — Thomanski | t | c | 15:59, 2 September 2020 (UTC)
 Weak support, if the image is customizable, and if the message could be customized based on topic. Fadyblok240 (talk) 03:55, 3 September 2020 (UTC)
 Somewhat Support Meh, it will make it look like the other templates, though i am fine with it being plain. James Haydon (talk) 23:14, 4 September 2020 (UTC)
 Neutral It's fine but is it really nessicary?---Humiebee Discuss anything with me Look at my edits 00:21, 5 September 2020 (UTC)
 Done Ok, so now, there is Dark Oak sapling, which is like - not compleated article/not done (or small article). --TreeIsLife (talk) 20:34, 8 September 2020 (UTC)

an extremely controversial proposal that will probably never get any support

The following discussion of a proposed New mob category is closed. Please do not modify it. Subsequent comments should be made in a new section.
The result of this discussion was Sorry, but  'Denied'.

Noe idk if this is even relevant but I propose........ to make a somewhat new. mob category. So far, there are 2 community-made mob categories, defensive (technically sub-category of passive), and neutral. I propose to make a category, mini-boss a sub-category of hostile, now this started with the fact that Elder Guardians are bosses in Bedrock Edition but not in Java Edition despite them being the exact same. Mini-bosses are also in dungeons (so it could possibly improve my hopes for support) but the mini-bosses would be the Elder Guardian and the Piglin Brute. These mobs have things in common.

  1. They are non-renewable, idk if this is a definition of mini-boss though
  2. They defend a structure (Ocean Monuments and Bastion Remnants")
  3. Multiple of then spawn within a structure, but only upon generation (reated to points 1 & 2)
  4. Have lot's of health and do lot's of damage, similar but weaker than a boss.
  5. Finally, they have a mini/weaker version, guardians and piglins.

---Humiebee Discuss anything with me Look at my edits 01:21, 28 August 2020 (UTC)

 Strong Oppose. 1) All mob categories on the wiki are currently community-made. 2) Community-made mob categories have been proven to not work for a variety of reasons (see multiple above/archived discussions). 3) I don't think we ever settled on "defensive" being a category. 4) Elder guardians are not bosses in Bedrock (at least, not in any way they're not in Java). This was a myth started by the fact that they were added in the "boss update". And even if they were, regrouping them in a category that is explicitly separate from what the game puts them in is a very bad idea. 4) Dungeons is a completely different game from the sandbox Minecraft. Something being in that game has no bearing on whether it should be considered for this one. 5) IMO, piglin brutes are too plentiful in bastions to be considered a "mini-boss". -PancakeIdentity (talk) 22:07, 29 August 2020 (UTC)
 Comment"All mob categories on the wiki are currently community-made." I'll have to point out that the Minecraft Books specifically categorize mobs as passive, neutral, or hostile. For 2, I'll need a link. For 5, I disagree as I usually find only 4-5 piglin brutes in bastion remnants. Blockofnetherite Talk Contributions 02:03, 31 August 2020 (UTC)
I really, really don't think the books should be counted as official sources of information when nothing in the game or the code categorizes things this way. More likely, the community made those terms, then those books adopted them. They are useful as a very surface level descriptor, and for most of Minecraft's history, didn't have much issue categorizing every mob. Here's one discussion, here's another, here's a third. -PancakeIdentity (talk) 08:03, 31 August 2020 (UTC)
 Strong Oppose. I want to abolish all 'mob categories'. Behaviors of mobs can simply not be summarized in one or two words, in my opinion. — Thomanski | t | c | 22:20, 29 August 2020 (UTC)
 Oppose I think mob categories are more useful for briefly describing mob behavior, which is then explained in detail elsewhere, than "categorizing" mobs. Elder Guardians could perhaps be described as mini bosses, but I don't think there is any need to categorize them as such. Mob categories are just too difficult to properly define. jahunsbe (talk) 23:51, 30 August 2020 (UTC)
 Neutral I personally believe that categorizing mobs are very useful, and despite some mobs being incredibly complex in its behavior, simplifying them to "passive", "neutral" or "hostile" is very useful. But I don't see the "mini-boss" as the best approach to this, neither do I think it is a bad idea. Blockofnetherite Talk Contributions 02:03, 31 August 2020 (UTC)
 Strong Oppose Because this category is completely made-up. As for your points, I can get exceptions to them: 1. Shulkers. 2. Guardians, Piglins, Shulkers. 3. Villagers, Piglins, Evokers... 4. Ravager? and 5. No example. Sagessylu (discuss | edits) 17:02, 31 August 2020 (UTC)
Sry Humiebee, but i think we can close this discussion. This won't have any support. --TreeIsLife (talk) 22:44, 9 September 2020 (UTC)

Deletion of several Tutorials pages

Hello everyone,

I'd like to know if you think these sub-pages of Tutorials should be deleted :

  • Tutorials/Airlock : almost completely pointless, the history is mildly active, but nobody has edited this page regularly for years
  • Tutorials/Desert shelter : completely pointless, too much specific, almost untouched since its creation
  • Tutorials/Pig parking lot : completely pointless, and nobody edited this page for a full year
  • Tutorials/How to find caves : information is also in Tutorials/Exploring caverns

Speaking for myself, I  Support these three deletions. Sagessylu (discuss | edits) 12:39, 15 June 2020 (UTC)

 Strong Oppose for removing Tutorials/Airlock,  Support Tutorials/Desert shelter if merged with Tutorials/Shelter types and  Strong Support for removing Tutorials/Pig parking lot --Treeislife2 (talk) 10:32, 17 June 2020 (UTC)

Ok, thanks! Just wondering, why exactly do you oppose for Tutorials/Airlock? Sagessylu (discuss | edits) 17:17, 17 June 2020 (UTC)
I feel airlocks are a genuinely useful tool in the context of water. If an article hasn't been updated in a while, the solution should usually be to update it, not nuke it. -PancakeIdentity (talk) 03:49, 23 June 2020 (UTC)
Well, after taking a look at it, the Airlock page is mainly talking about the sand + torch mechanic currently, even if there are more airlocks with doors, signs... I thought it was only supposed to talk about these useless one-use "sand airlocks", but I was wrong, and you're quite right. So, I updated my original post to not include the Airlock page. Sagessylu (discuss | edits) 08:15, 23 June 2020 (UTC)

Tagged "Pig parking lot" for deletion, I will do so with "Desert shelter" at some point, when I'll merge it with "Shelter types". I won't do anything with "Airlock" except maybe work on it to make it focus less on those sand staircase things and more on techniques like using doors, because it's quite misleading right now. Sagessylu (discuss | edits) 10:17, 6 July 2020 (UTC)

I agree that the "Pig parking lot" tutorial is useless. I mean, why to build a complicated parking mechanism when you can just use leash and a fence? 11:13, 12 July 2020 (UTC)

I also want Tutorials/How to find caves to be deleted, since a section of Tutorials/Exploring caverns provides the same information. Fadyblok240 (talk) 00:13, 14 July 2020 (UTC)

That's right, I added it to the list. Sagessylu (discuss | edits) 15:42, 20 July 2020 (UTC)

Since Tutorials/Redstone machines duplicates the scope of Tutorials/Mechanisms, the former should be deleted, following the movement or deletion of contraptions on a case-by-case basis. –Preceding unsigned comment was added by Fadyblok240 (talkcontribs) at 13:51, 23 July 2020 (UTC). Please sign your posts with ~~~~

Actually, I converted the article into a redirect after moving or deleting all the content. Fadyblok240 (talk) 01:08, 12 August 2020 (UTC)
 Support deletion of Tutorials/Pig parking lot and merging/redirecting of Tutorials/Desert shelter and Tutorials/How to find caves. I don't see the harm in keeping "Tutorials/How to find caves" as a redirect, especially since it was created in 2011 (before "Tutorials/Exploring caverns") and may have incoming links from outside the wiki. –Sonicwave talk 22:46, 4 September 2020 (UTC)
 Done by merging the pages, there was a clear consensus, now can an admin delete the pig parking lot page?---Humiebee Discuss anything with me Look at my edits 21:36, 15 September 2020 (UTC)

Conflicting Licenses

As a part of Minecraft Wiki:Projects/Cleanup open tags I came across File:Grid Charged Thaumium Cap (Thaumcraft).gif which seems to have twp conflicting Licenses applied to it. Does anyone know which is the right one? --Asarta (Talk) 15:44, 13 September 2020 (UTC)

I believe the more restrictive one (in this case, copyright / fair use) takes precedence. --AttemptToCallNil (report bug, view backtrace) 18:05, 13 September 2020 (UTC)
 Done removing the extra license. Fadyblok240 (talk) 12:38, 14 September 2020 (UTC)

RfC: appoint a new bureaucrat

Majr is inactive, leaving Madminecrafter12 as the only active bureaucrat. It has been supported by several users on Discord that it's optimal to have 2 bureaucrats for "balance" purposes.

  1. Does anyone think we actually don't need a new bureaucrat?
  2. Who could be a new bureaucrat? (Actual discussion/voting on specific candidates could be separate and come later, I think)

Any thoughts? --AttemptToCallNil (report bug, view backtrace) 22:55, 26 June 2020 (UTC)

Don't necessarily think it's needed, as not that much needs to be done by a bureaucrat that an admin cannot do, but I don't oppose more bureaucrats. FVbico (talk) 23:04, 26 June 2020 (UTC)
Well, I feel like the definition of "need" is a bit subjective; but I will say I think it would be quite useful to have a second (active) bureaucrat. As for who it would be, I'm not strongly opposed to any of the current admins being promoted; I'd prefer to leave the deciding up to the community and I'd close the discussion, promoting if there's a sufficient consensus to do so. As for my reasoning about why having another bureaucrat would be beneficial, I'm lazy so I'm just gonna copy what I said on Discord:
"I feel like the main reason would most likely be RevDelete. As an example, there was a recent case of a user revealing private information on their profile and it was noticed at a time where neither I nor Markus (the wiki manager) was active. It wasn't until I was woke up the next day that it was hidden. Such cases aren't very common, but they do happen; and private personal information really should be expunged as quickly as possible."
"Another reason may be for "balance" purposes; e.g. if my account were to get compromised or I suddenly become inactive (in which case there would be no bureaucrats), or even simply because I need a second opinion on a bureaucrat-related matter . I guess this argument is weakened by the fact that staff exist, but still, I feel like it's good practice in general to have more than one local user with the ability to hide edits and grant/remove any user rights."
Some stated that the RevDelete argument isn't particularly strong because once we move to Fandom, bureaucrats will likely no longer have the ability to RevDelete. However, I don't see the probable removal of RevDelete by bureaucrats eventually as a reason to not promote any currently; we don't know what exactly is going to happen or when it's going to happen, so imo it makes the most sense to act upon the current situation and accommodate if the situation changes in the future.--Madminecrafter12 (Talk to me | View what I've done) 23:28, 26 June 2020 (UTC)
@Madminecrafter12: We're not moving to Fandom. Unified Community Platform won't affect URL or Gamepedia brand. There is also no proof, if it will affect something as whole. In this Phase 1 only some elements will change. In Phase 2 however, here will be that changes to skins, copyright, and new features. --Treeislife2 (talk) 14:24, 28 June 2020 (UTC)
We're not merging with the Fandom Minecraft Wiki, if that's what you mean, but it's likely eventually we will adapt many of Fandom's features. This probably includes not allowing bureaucrats to RevDel, as staff have actually stated. But my argument was actually that we don't know for sure how this is going to happen and that it's probably going to be a while.--Madminecrafter12 (Talk to me | View what I've done) 14:30, 28 June 2020 (UTC)
I didn't say merging with Fandoms Minecraft Wiki. This is not real for now, as there are big diffrences between these wikis (mostly noticed - it is really fan-made wiki, and combination of documentation wiki with extreme fan wiki is like breathing cat with ocelot in Minecraft 😀). You can ask staff, if they will keep this feature, but since Gamepedia is still upgrading, there is no reason for Fandom to revoke feature (only, if they will say, that feature is not needed). No one knows, how long it will be till end of Phase 1. Simpliest wikis on Fandom were already merged (but this is only Stage 2 from 4 of them - and you know, that stage 1 started on March 11, 2020). --Treeislife2 (talk) 16:23, 28 June 2020 (UTC)
Support adding a new bureaucrat, I don't see why not. We effectively only have one right now. I think any of the admins would do well, though I think picking someone who can cover more of Mad's inactive time would be preferable. -PancakeIdentity (talk) 00:54, 27 June 2020 (UTC)
I would support adding new admins instead of bureaucrats since there are only 9 admins. Promoting new bureaucrats doesn't seem to help the wiki much. I would say we can wait until Majr is inactive for 1 calendar year before taking action.--skylord_wars (talk) 05:15, 27 June 2020 (UTC)
The problem with having only 1 bureaucrat is that if ze becomes inactive, we have no way to get a new one. We can always ask Game widow to make someone a bureaucrat, but that is a last resort. The BlobsPaper.png 06:21, 28 June 2020 (UTC)

Possible candidates?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The result of the discussion was promote Nixinova.

The discussion above to promote a new bureaucrat seems to have a pretty clear outcome of yes, a second bureaucrat would be useful. As I myself am the only active bureaucrat, I think my own opinion could be useful as well, and I do indeed agree with promoting a new bureaucrat. The few people who were opposed or neutral towards having a new bureaucrat seemed to think that if we were to promote another bureaucrat (leaving aside whether such would be necessary), Nixinova would be the best option. There has been quite a bit of well-reasoned support with very little valid opposition, and this discussion has been inactive for about a week. It is worth noting I have no personal objections to granting Nixinova bureaucrat, so the decision is pretty clear to me. If anyone has any thoughts or objections, comment in the section above or create a new subsection; this specific discussion is closed. --Madminecrafter12 (Talk to me | View what I've done) 15:59, 23 September 2020 (UTC)

I thought I'd go ahead and open up this sub topic. If we add a new bureaucrat, which seems to be where the above discussion is heading, who should it be? AFAIK, standard practice is to choose from current admins (correct me if I'm wrong).
I mentioned my stance above; any of the current admins seem good but one who covers Mad's inactive times would be better probably. If we narrow it down to just a couple and/or a specific user is "nominated", I may give my specific feedback regarding those/that user(s). -PancakeIdentity (talk) 09:31, 8 July 2020 (UTC)

Nixinova. There are many reasons but lets start simple
  1. He is an admin (obviously)
  2. He has beencontributingg to this wiki for many years and has been an admin for more than a year.
  3. He's number 2 in the minecraft wiki.
  4. He's been playing the game since 1.4.2
  5. He owns all the versions of minecraft (including earth and dungeons) except education and discontinued versions
  6. Very Knowledgeable in minecraft
  7. he's never shown any inactivity from the time he registered his current account
  8. He lives in New Zealand and as what User:PancakeIdentity said, covering User:Madminecrafter12's inactive times would be the best and since Nixinova lives in New Zealand, it's perfect.
so that is why i think he should be bureaucrat.
1 note is that he's the newest admin if that has any effect.
The BumblebeeBee.png 00:47, 15 July 2020 (UTC)
I agree that nixinova would make anexcellentt bureaucrat.--Minecraft loot (talk) 10:46, 22 August 2020 (UTC)
Nixinova thinks twice before acting and always have amazing and precise suggestions on most subjects. --dr03ramos Piston.gif (talk) Admin wiki[pt] 00:03, 29 August 2020 (UTC)
I didn't comment on this before because I didn't know what bureaucrats actually did (just user rights and revdel, right? anything else?), so unless revdel doesn't work on mobile for some reason (in a way I can't hack around) I'd be fine with being a bureaucrat. (And thanks for the praise above :).)  Nixinova T  C   00:35, 29 August 2020 (UTC)
Correct. The only permissions bureaucrats have that admins don't are the ability to hide revisions and logs and give users any local right (patroller, admin, bureaucrat, etc.). --Madminecrafter12 (Talk to me | View what I've done) 00:51, 15 September 2020 (UTC)
 Support for above reasons Blockofnetherite Talk Contributions 21:29, 9 September 2020 (UTC)
 Comment Having two active bureaucrats, I believe, is actually  Useful. Very bad edits that need to be RevDeleted may be necessary when @MadMinecrafter12 is offline, knowing that @Nixinova is in about the opposite time zone as @Madminecrafter12. Sure, contacting User:Game widow is an option, but is the very last result. Overall, if we need a new bureaucrat (which I observe is useful considering what I just said and above reasons), then User:Nixinova would be the best candidate. Blockofnetherite Talk Contributions 19:44, 15 September 2020 (UTC)
 Support also for the above reasons --Minecraft loot (talk) 21:10, 13 September 2020 (UTC)
No stance on whether we need bureaucrats (but slightly leaning towards that we do). If we do decide we need a bureaucrat, then I'd support Nixinova. --AttemptToCallNil (report bug, view backtrace) 00:54, 15 September 2020 (UTC)
 Neutral for Nixinova. But, please, do not forget, that he is also administrator on Hytale wiki. Idk, how he can manage 2 wikis at once with no problem, but i am not oppose that.--TreeIsLife (talk) 12:46, 15 September 2020 (UTC)
I don't think being an admin on another wiki should be considered an issue at all. Nixinova is already actually an administrator here and by looking through his contributions you'll see he's very active here. And bureaucrats just have a few additional tools. It's not like bureaucrats are expected to devote all their free time to changing user rights or deleting revisions on the wiki.--Madminecrafter12 (Talk to me | View what I've done) 13:12, 15 September 2020 (UTC)
Hytale Wiki at the moment isn't much work (since the game only comes out next year) and since bureaucrat is just a couple extra tools it shouldn't be too much to handle.  Nixinova T  C   00:59, 16 September 2020 (UTC)
 Support – No objections for Nixinova (or any of the other active admins for that matter). As mentioned above, the fact that he is in a different timezone than Madminecrafter (as well as MarkusRost or the other Gamepedia wiki managers) may be useful for urgent RevDel requests. Even if that might be removed from bureaucrats in the future, having an extra bureaucrat for promoting users seems useful in case Mad also becomes inactive. –Sonicwave talk 20:07, 16 September 2020 (UTC)
Can we promote him now?---Humiebee Discuss anything with me Look at my edits 20:58, 16 September 2020 (UTC)
While there is a lot of support, it does seem nobody even thought about any other admin, such as sonicwave or knight miner. Additionally, aside from the initial arguments, nothing was added by supporters. All but being "nr 2" (which says only about quantity of edits, not quality BTW) are applicable to other admins as well, so perhaps at least put up other suggestions as well, rather than have a poll with only 1 option provided. :) FVbico (talk) 21:34, 16 September 2020 (UTC)
The most major argument would probably be the timezones one as no other admin (not even mad) live in like +7 to -11 timezone while everyone else is -8 to +6 (unless attempttocallnil lives in eastern russia, if so, also a possible candidate) if mad or markus rost are not online, whos going to be to rev delete some extreme personal or things that violate rule #3?---Humiebee Discuss anything with me Look at my edits 21:49, 16 September 2020 (UTC)
Even now, rev deletes are not something that is immediately done, and you can be kept waiting for it for more than half a day, no matter the timezone. So while it is an argument, it's not necessarily a must. To be completely clear, I do NOT oppose nixinova at all, but as it currently stands in this discussion, it really looks like nobody else even got considered. FVbico (talk) 21:55, 16 September 2020 (UTC)
For the record I don't think I would want to be bureaucrat; I have been trying to reduce activity on here (and most internet places) for a while and therefore might not always be available. As mentioned above though, I wouldn't oppose any of the other admins either. It might be worth noting that AttemptToCallNil is already a bureaucrat on Russian MCW and therefore might have some experience with the RevDel policy already. –Sonicwave talk 22:00, 16 September 2020 (UTC)

If Piglins are called "hostile" can we revert them?

The following is a closed discussion of whether piglins are neutral or hostile. Please do not modify it. Any editors wishing to make further comments should start a new topic.

I think it is fine to close this topic because there is no reply in almost a month, leaving this discussion inactive. Also, the question has been answered and the piglin situation is pretty much solved. They're neutral. Blockofnetherite Talk Contributions 16:48, 26 September 2020 (UTC)

There are many times that piglins are called "hostile" so can we revert them? - 10:04, 23 August 2020 (UTC)

Piglins are hostile by default so that's the definition. Idk why there's like a giant edit war about the neutrality of the piglin.---Humiebee Discuss anything with me Look at my edits 15:24, 24 August 2020 (UTC)
But if you wear gold armor they become neutral so I call them neutral. 02:26, 25 August 2020 (UTC)
See my edit on my talk---Humiebee Discuss anything with me Look at my edits 22:37, 25 August 2020 (UTC)
 CommentLet's stop this edit war. It should say "Piglins are neutral mobs native to the Nether. If the player wears gold armor, they become neutral." Sounds better than "Piglins are neutral mobs native to the Nether. If the player wears gold armor, they become neutral." However, we still have something going on: in the Mob page, adult piglins have been moved to the neutral section to the hostile question. I propose a new question: In the Mob page, should we place adult piglins in the neutral section, or the hostile section? Blockofnetherite Talk Contributions 01:59, 26 August 2020 (UTC)
The edit wars have stopped, though there is still some discussion about the status as it is mainly hostile, partialy neutral and partialy passive so it would fit into hostile/neutral??? like the spider.---Humiebee Discuss anything with me Look at my edits 02:11, 26 August 2020 (UTC)
I once again point to the mob category discussion above. These simple, largely undefined in-game terms are not great for grouping more complex mobs like piglins. For what it's worth though, I'd say they're neutral, especially if we're gonna count spiders as neutral. -PancakeIdentity (talk) 17:42, 27 August 2020 (UTC)

Can I edit "Bedrock Edition scripting documentation"

I am thinking of editing Bedrock Edition scripting documentation but I am not sure if I am allowed to. This is my first time contributing to wikis. I want to add on to the createEntity() that if the Type is specified as item_entity then TemplateIdentifier should be the item identifier and not the identifier of an entity. 02:57, 15 September 2020 (UTC)

I don't see any protections. Well, most of pages are not protected. But admins are mostly blocking pages with hype. These are: Minecon few hours before beggining, new major update (planned/released) and of course, pages with vandalism. And, IPs can't create any new pages (except talk pages), so you should Create a new account which will grant you abiloty to create pages + you will can use this account on any other Gamepedia and even Fandom wiki--TreeIsLife (talk) 13:01, 15 September 2020 (UTC).
Okay thanks, I will create an account. 17:22, 15 September 2020 (UTC)

Change formatting for hatnotes

Currently, there is excessive padding around hatnotes. A proposed change of mine would condense the spacing, making the hatnotes more similar to that of Wikipedia's. The following should be added to the common.css file:

/* Hatnotes and disambiguation notices */
.hatnote {
	font-style: italic;
.hatnote i {
	font-style: normal;
div.hatnote {
	/* @noflip */
	padding-left: 1.6em;
	margin-bottom: 0.5em;
div.hatnote + div.hatnote {
	margin-top: -0.5em;

to replace

/* [[Template:Dablink]] */
.dablink {
    padding-left: 2em;

Also the contents of {{Hatnote/sandbox}} should replace the contents of {{Hatnote}}, which currently has hardcoded css values.

Fadyblok240 (talk) 05:26, 26 September 2020 (UTC)

What's the benefit of putting on these stylesheets as opposed to raw inline styles? The latter seems like it would be way easier to keep updated.  Nixinova T  C   02:12, 27 September 2020 (UTC)
Here's the thing: the current template forces italics, and italic markup cannot cancel it. Using the new stylesheets would allow italics within italics (i.e. no italics). Also, when the new styles get implemented, we don't have to worry much about changing them for a very long time. Fadyblok240 (talk) 04:53, 27 September 2020 (UTC)
Hatnote comparision.png
Okay, done.  Nixinova T  C   19:14, 30 September 2020 (UTC)

Handling of Legacy Sprites

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The result was to remove legacy sprites from the current versions. They may be spritesheets dedicated to legacy sprites. Fadyblok240 (talk) 23:54, 29 September 2020 (UTC)

So, a recent discussion on discord has had regarding handling legacy sprites on the wiki. As the discord is not a replacement for on-wiki discussion, I thought I'd bring it here. Should we hold legacy block sprites on the wiki (not image files), and if so, how? Should they be in Block Sprite (and similar), or should there be dedicated templates for these legacy sprites? These sprites would mostly be used in history sections and old crafting recipes where needed.

Personally, I'm mostly neutral on all this. I'd weakly support having them on the wiki somewhere, but I don't feel strongly about it and I don't really care how it's done if we decide to do it. -PancakeIdentity (talk) 01:13, 9 May 2020 (UTC)

Currently, the BlockSprite, ItemSprite and EntitySprite templates all contain a large amount of different textures. A lot of these are left over from updating the template to comply with the Texture Update, and are rarely used, despite them taking up almost half of the space on the sprite sheets in question. This also makes editing them difficult, even in edit sprite form, since they take up huge chunks of space. I'm considering creating dedicated sprite sheets and templates to move these textures to, so that they don't have to take up as much space on the current templates in question and so that the normal ones only hold textures that apply to current Java, Bedrock and Education Edition features. All textures of removed features or outdated textures would be moved t the legacy templates instead.

By default, specifying the name of a block without stating what revision it is would default to the version of that texture as it were on Java Edition prior to the Texture Update, but further details could be specified if a different version of the texture is desired.

I will take 100% responsibility in splitting these sprite templates into the current and legacy versions as well as converting existing pages that use legacy sprites to use the correct templates.

Would anyone explicitly oppose such a change, or would I be free to go ahead with it? - User-12316399 (talk) 01:30, 9 May 2020 (UTC)

The spritesheets are too large so I  Support splitting off the legacy sprites. Nixinova T C 01:17, 9 May 2020 (UTC)
 Support for splitting off the legacy sprites. --Treeislife2 (talk) 19:42, 9 May 2020 (UTC)
 Oppose I see no reason to keep the sprites in any form (split or not); we already have revision renders, and aside from invsprite in version pages and history sections, I see no use for them. FVbico (talk) 19:51, 9 May 2020 (UTC)
So we're ignoring pages like Java Edition 1.13/Flattening then, which use modern sprites despite the fact that they have no business using block sprites from a year ahead of what they document? - User-12316399 (talk) 20:22, 9 May 2020 (UTC)
I'm not ignoring them, those can be changed to the renders instead of the sprites. FVbico (talk) 20:24, 9 May 2020 (UTC)
I mean there are examples of things like historical crafting recipes and such, I'm not sure if they can use renders. If they can, then yeah, I don't see much a need either. If they can't, is it worth all the effort to fix it? -PancakeIdentity (talk) 21:33, 9 May 2020 (UTC)
While they could be replaced with renders on pages like the mentioned flattening page, the 16x16 block sprites are almost exactly the same size as the text itself, and replacing these with renders would either require scaling them down to being indecipherably small or having them be bigger in a way that unnecessarily stretches the template out. Since blocksprite has them at just the right size to be able to convey the necessary information, I'm still sticking with keeping the legacy sprites in a dedicated template. - User-12316399 (talk) 21:40, 9 May 2020 (UTC)
This would just be very inconsistent in my opinion. And I think User-12316399 also got a very strong argument here. Sagessylu (talk) 14:03, 16 May 2020 (UTC)
If we were to keep them, would you rather they be split or kept together? -PancakeIdentity (talk) 17:55, 16 May 2020 (UTC)
 Support I don't see any reasons for which we shouldn't split. It would indeed make the sprite sheets smaller and easier to maintain. Sagessylu (talk) 14:03, 16 May 2020 (UTC)

If there aren't any objections within the next 12 hours I'll go ahead and split the three relevant sprite templates; if the consensus later turns to just outright removing legacy sprites, the legacy templates can just be deleted anyway to achieve the same effect. - User-12316399 (talk) 21:42, 12 May 2020 (UTC)

As there hasn't been any opposition in the given time frame I'm proceeding with the split of templates. Again, since both parties agree with having legacy sprites removed from the main template this shouldn't be controversial, and the dedicated legacy templates can just be deleted if that side wins. - User-12316399 (talk) 12:35, 13 May 2020 (UTC)
This was open for only 4 days, and 1 oppose and 1 support; you're in no position to say to go through immediately until there is more support. FVbico (talk) 14:00, 13 May 2020 (UTC)
In case I can still give my opinion, I'd say I  Support splitting sprites into their legacy versions, especially the {{InvSprite}}. I think removing them completely is a little extreme. I can also run the bot User:Dr03bot if needed. --dr03ramos Piston.gif (talk) Admin wiki[pt] 01:03, 24 May 2020 (UTC)
I won't be touching invsprite so someone else will have to do that one if it needs changed. - User-12316399 (talk) 04:35, 27 May 2020 (UTC)
 Support, now it seems that {{BlockLink}}'s doc can not be loaded by {{documentation}} at all, I think we need split it no matter whether legacy sprites should be removed.--Chixvv (talk) 00:35, 7 June 2020 (UTC)
I tweaked Module:Documentation a bit, it should work better now. I think this shouldn't affect split discussions though. --AttemptToCallNil (report bug, view backtrace) 01:45, 7 June 2020 (UTC)
 Support splitting legacy sprites to a separate sprite sheet. It's more visually consistent with current sprites than revision renders, at least for blocks and entities. –Sonicwave talk 00:38, 18 August 2020 (UTC)

Seems like consensus is to remove old sprites so I'll be doing that soon enough. - User-12316399 (talk) 11:56, 28 September 2020 (UTC)

Articles on Mojang staff and related persons - do we really need them?

Except for perhaps the most notable people, do we really need articles that get almost no editor attention and rarely exceed a couple short sentences? I don't see how most of them are even relevant. Even spin-off titles like Story Mode or Dungeons are more relevant, I think. --AttemptToCallNil (report bug, view backtrace) 18:56, 23 November 2019 (UTC)

I feel like, at best, we should try to expand the articles as much as possible, much like how Wikipedia does it with their policy on biographies of living persons, making sure that information about them is backed up be reliable sources. I do recall mentioning back in 2015 that we could possibly use LinkedIn profiles as a source for reliable information, though discussion never went anywhere beyond that. -BDJP (t|c) 21:30, 23 November 2019 (UTC)
We mention devs pretty often in history sections, and it might be useful to have these pages in those cases. Especially when they commonly go by nicknames (i.e. Jeb or Dinnerbone). Other than that, I don't know. I would like to see the general staff page updated though. -PancakeIdentity (talk) 04:41, 27 November 2019 (UTC)
Other than the obvious ones I think there should just be an "employees" page that lists mainly job-related info; this also avoids the BLP issues we've had in the past.  Nixinova T  C  06:03, 27 November 2019 (UTC)
I would support having a Mojang employees page, consolidating the short pages there, and having a link from there (after a brief overview) to longer pages like for Jeb. Memetics talk | edits 22:42, 10 April 2020 (UTC)

Remove separate employee pages

This wiki tries to create a page for every single Mojang employee, yet the vast majority are either redlinks or one-line stubs. This is hardly useful, and really the only information you need is name, date of employment, and job title, which can easily be done in just a table. It would be so much easier to maintain employee pages of they were all just in a table instead of spread out across hundreds of pages. Additionally, this leads to the wiki coming across BLP issues (eg: ez) and not having proper policy on how pages on people should be handled (we're not Wikipedia). These issues can be easily solved by migrating all employee information into e.g. Employees(yes, plural). Excepting, of course, very notable employees like Notch.  Nixinova T  C   05:50, 24 July 2020 (UTC)

I would support removing pages for employees that have hardly any information. There is currently a table at Mojang Studios#Employees, which could be split into a separate page and get additional columns for join date and other notable Minecraft-related info/trivia. (Also see the previous discussion on this topic.) –Sonicwave talk 17:40, 24 July 2020 (UTC)
 Strong support I agree, like whats the point of making these tiny stub pages that almost no one goes to? Completely Agree The BumblebeeBee.png 18:55, 24 July 2020 (UTC)
My opinian is slightky changed after a few months, I would  Keep the pages that do not hae the {{stub}} templates but  Redirect the pages that do have {{stub}}Humiebee (talk) 15:48, 11 November 2020 (UTC)
Moved to previous section that I didn't see when creating this section Nixinova 01:08, 25 July 2020 (UTC)
 Support. Just a note, I'd say Lena Raine and C418 should still have their own pages both as they are extremely well known (especially C418) in-community, and neither are Mojang employees. In general, though, we'd need to have a general guideline for who gets their own page. Things like a well-known nickname, notability in and out of community, and role in the company (ex: Jonas Martensson and Helen Chiang aren't too well known in the community, but hold important positions at Mojang, which may justify them have unique pages?). -PancakeIdentity (talk) 08:43, 27 July 2020 (UTC)

Changes to the upcoming template (and similar)

From here on out, Bedrock and Java will match version numbers. I was thinking that to avoid spam and compress those ugly upcoming tags, we could just allow, for example, {{upcoming||1.16}} to be used. Individual versions could still be used for version exclusive features, of course. This would help compress those editor notes which can make pages look ugly and harder to read (See Log for example). I think this, along with the proposal above about modifying the {{in}} template, would help us greatly improve the readability of articles. -PancakeIdentity (talk) 04:50, 17 March 2020 (UTC)

 Support We could have "1.16" redirect to Nether Update, to include both editions. The BlobsPaper.png 15:16, 17 March 2020 (UTC)
 Support. --dr03ramos Piston.gif (talk) Admin wiki[pt] 21:03, 18 March 2020 (UTC)
A couple notes from a discussion on discord: {{INUpcoming}} and {{inUpcoming}} could say "In the Nether Update (1.16), ...". In the normal {{upcoming}} template, we could also say "Nether Update" as opposed to "1.16". Just a couple more ideas. Personally, I'm neutral on these specific suggestions. -PancakeIdentity (talk) 02:19, 19 March 2020 (UTC)
 Support unless Mojang doesn't keep up this consistency. I'd be happy to update/create/fix templates like {{in}} etc if needed.  Nixinova T  C 
I tried implementing something like this, but I couldn't get it to work. I could get Nether Update, but not the other way around. If someone who has more template knowledge than me wants to give it a try, you can edit User:PancakeIdentity/UpcomingMockup. -PancakeIdentity (talk) 23:05, 10 April 2020 (UTC)
Yeah, I think it's too long to type "upcoming JE 1.16 & BE 1.16.1" a million times. I'll try to see if it works, your suggestion. 13:48, 25 April 2020-- 08:18, 25 April 2020 (UTC)
These templates are functional in my userspace. User:PancakeIdentity/UpcomingMockup, User:PancakeIdentity/UntilMockup, User:PancakeIdentity/InUpcomingMockup, User:PancakeIdentity/InUntilMockup. They could be implemented, but they no longer accept a 2nd version argument so cleanup will need to be done. -PancakeIdentity (talk) 01:18, 22 April 2020 (UTC)

Should sprite files be interlaced?

Currently, sprites (like InvSprite.png) are not interlaced, which means they will load downwards. If you have a slow connection (or enable slow network simulation in browser inspector), you can see content on the top show up first. So, in a normal page, those sprites coming in later versions will take a while until anything show up. After interlacing these pngs, we can expect the sprites to show up immediately blurred and then fully displayed after loaded, as the pixels are downloaded in a chessboard pattern. (check this for detail)

tl;dr: With interlacing, the sprites load up faster but will start blurred. Without interlacing, the sprites in the bottom will take a while to show up. Should we interlace the sprite files, or rearrange most-used sprites on the top?

-- CuervoTalk 06:27, 25 March 2020 (UTC)

I would support interlacing. Otherwise we would need to update the sprite positions, and the incorrect sprites may appear for the next day due to server cache. The BlobsPaper.png 15:15, 25 March 2020 (UTC)
Do we even still need sprite sheets? --AttemptToCallNil (report bug, view backtrace) 17:15, 25 March 2020 (UTC)
I doubt it, unless InvSprite pulls directly from that big image. -PancakeIdentity (talk) 21:14, 25 March 2020 (UTC)
@PancakeIdentity: The sprites are directly pulled from the large images; deleting these images would break the templates. The BlobsPaper.png 02:18, 26 March 2020 (UTC)
I meant, why not go back to the old system of individual files per image? The performance issues seem to no longer be substantial (there are issues if you're using, like, _hundreds_ of different images per page). As for the sprites in navboxes, they're not really needed; the large navboxes themselves could be candidates for deletion as they aren't very effective for navigation (a task better accomplished by a well-designed category system).
I should also note that there's the possibility that with the transition to UCP, functionality critical to the sprite system may become unsupported without any replacement (except to use individual files). --AttemptToCallNil (report bug, view backtrace) 09:42, 26 March 2020 (UTC)
iirc, sprites are introduced to optimize numbers of HTTP request, thus reducing protocol overhead. And on the SEO side, search engines seem to favor well-written sites. I know HTTP protocol has been overhauled in recent years but I'm not a web developer, so I don't know if these theories are still true today. For templates, it's true templates aren't intended for navigation on MediaWiki, but the readers would prefer easy-to-read template rather than plain category page imo.  CuervoTalk 16:39, 27 March 2020 (UTC)
I'd  Support this, although the Sprite editor would have to be changed to support this feature. Also, is there a variation of progressive JPEGs for PNGs? These first load a really low quality version of the image before scaling up the resolution once more of the image loads (for 16x16 images it wouldn't appear much different at all).  Nixinova T  C  01:42, 31 March 2020 (UTC)

IP addresses are creating non-talk pages

For example, the redirect Light Grey Balloon was created by an IP address. Any thoughts? Blockofnetherite Talk Contributions 01:36, 6 October 2020 (UTC)

By the way, this happened after UCP migration. Blockofnetherite Talk Contributions 01:36, 6 October 2020 (UTC)
Has been resolved. –Sonicwave talk 18:46, 6 October 2020 (UTC)