Minecraft Wiki

The Minecraft Wiki is no longer considered as official by Microsoft and therefore several changes are required to be made, including to the wiki's logo. Please read this announcement for more information.

READ MORE

Minecraft Wiki
Advertisement

Host problem[]

This template is causing the host to go down. I tried putting this template several times in my user page and it keeps having the host go down. Is it due to the coding? --ToonLucas22 (talk) 18:35, 17 December 2014 (UTC)

Most likely not the template, as it works fine for me, and your page is no where near the page limits. Try editing the page without the template, and if it still throws an error try editing a section (or a different section if you already were editing a section) KnightMiner (t·c) 19:12, 17 December 2014 (UTC)

extra utility field[]

I have this idea. BDJP007301 and all interested parties, I'd like your input on this if you can. It seems to me that this wiki is meant to document the game, rather than document the bug tracker. And currently for the lists of bug fixes, it references the bug tracker, which is mostly accurate in documenting when a thing is fixed, but on the whole, inaccurate. I would say untrustworthy. Not the fault of anybody, just the way it's set up.

I just discovered for instance that the Lava being destroyed by TNT bug wasn't fixed in 1.8, but earlier, in a 1.7 snapshot. And only because on the tracker nobody checked for that period of time. Again, nobody's fault, and on the tracker, the purpose was served.

Anyhow: can we have a boolean verified field in {{bug}}, that if it's true, it means that somebody here has verified that the bug was in fact fixed in that particular version. And going with that, some page, maybe a category, that gathers all the unverified instances of the {{bug}} template, where the field is false or absent, for further investigation.

Anyway those are my ideas - thoughts?

Sealbudsman (Aaron) SealbudsmanFace.png t/c 22:38, 18 April 2015 (UTC)

Well, assuming that category is added, it would certainly be a lot of work to verify all the bugs from tracker that are listed on the wiki. The code would be a bit complicated to not add the category on non-version articles using the category, causing it to be a bit inefficient for a template to make common links, so I would suggest a different way to mark pages with bugs needing verification.
Instead, it might be a good idea to make a project, which would allow the same category system for incomplete pages, and make it easier for additional users to get involved. You can basically add a category to verified pages, and generate a list of incomplete pages from pages in Category:Computer versions that are not in that category (you could really just copy the code from MCW:Projects/Rewrite for Style/Blocks#Progress and change the category names, or I could set it up) KnightMiner t/c 23:38, 18 April 2015 (UTC)
It would be a ton of work, yeah, I do realize. Quite a bit, no lie. But i mean, at least it would be an accessible project for those who want to do it. And i like the idea of making a proper project.
Would we need to make the distinction between version and non-version articles? Editors can generally look at a category page and tell the difference, yeah?
I wouldn't (unless necessary) want to go the route of adding an 'Unverified Bugs' category to each page. I'm thinking along the lines of this hidden category in Wikipedia, where the Citation Needed template inserts the category with every incorrect usage of the template. In our case, {{bug}} (and i guess {{fixes}}? uh oh, this is getting complicated) would keep track of inserting the Unverified Bugs category to the page based on the 'verified' parameters. Would something like that work, if for the project we took the intersection of the Unverified Bugs category and the Computer Versions category?
Sealbudsman (Aaron) SealbudsmanFace.png t/c 00:38, 19 April 2015 (UTC)
I think these would be the categories (everything is in the second category, only because Category:Unverified bugs doesn't yet exist):
Bugs not all verified
#dpl:uses=Template:Bug|category=Unverified Bugs|namespace=
Bugs all verified
#dpl:uses=Template:Bug|notcategory=Unverified Bugs|category=Computer versions|namespace=
(I'll delete this table after this thread is final)
I'll take a crack at making an auto-inserted 'Unverified Bugs' category in {{bug}} and {{fixes}} later, or anyone can.
Sealbudsman (Aaron) SealbudsmanFace.png t/c 17:59, 19 April 2015 (UTC)
Yeah, we could simply look at the results using DPL, though I still don't like the idea of adding the category to pages that don't fit the category. One option also might be adding the category if the parameter is set (and removing the parameter after verifying the bug), then sending a bot to set the parameter on all computer versions. That would also make it easier to generate a list of all unchecked bugs using DPL's "includematch" parameter, as finding a nonmatch is more complicated. KnightMiner t/c 21:09, 19 April 2015 (UTC)
That sends a bit more complicated to me.. More steps, using a bot. Maybe i need to better understand your objection to having the template handle the adding of the 'unverified' category ? – Sealbudsman (Aaron) SealbudsmanFace.png t/c 23:23, 19 April 2015 (UTC)
The main reason I was against adding the category here is the fact that it would require somewhat inefficient code for a common link template, as each call would have to speerately check the page type, or we would have to add a category to pages that do not belong in the category. Although, I just though of a somewhat efficient way to add the category. Setting a variable in the version nav is an easy way to figure out that it is a version page, as that template adds the version category. It still would be a good idea to add a project to coordinate the testing though.
The only remaining problem is assuming you finish all the bugs on some pages, such as 1.7.2, you still need to add the verified parameter 96 times, so a short name might be in order, such as {{{v}}}. It should be easy enough to add support in {{fixes}} as well.
Lastly, two question related to this: "would you test all the bugs on a page at one time, or test bugs one by one?" and "would you plan on the verification tags being removed after all bugs have been tested, or leave them for future versions?" KnightMiner t/c 00:52, 20 April 2015 (UTC)
I see. I think I wasn't thinking of having {{bug}} also be responsible for checking whether it's in a version page. I can see how that could be awkward if it didn't. So if you think a variable in the version nav is a clean way of telling that difference, that takes care of that...
A short name, agreed.
I believe each bug would need to be tested 1 by 1. The way I found the correct location of the lava vs TNT bug, I tested it in isolation. I think whatever paradigm is created ought to allow for unverified vs verified bugfixes on the same page. Some are going to be trickier than others, and if the project page keeps track of what pages are what, I don't believe there should be a necessity to do whole pages at a time.
I believe it would be better to leave the {{{v}}} tags in place, #1 so that the project page reflects their completion, #2 for any future viewer of the page. I think removing it, you lose the fact that it's verified. I'll give you a use case. Let's say we verified everything in 1.7.2, then removed the parameters. Then someone down the road closes a bug in the tracker, and it goes in 1.7.2. Now it appears that nothing in 1.7.2 is verified except that new one. Is it recorded somewhere else that all those bugs are verified?
I think the project we make would probably not be a strictly completable project, but more of an ongoing QA project. And so I think the tags would stay.
Sealbudsman (Aaron) SealbudsmanFace.png t/c 01:55, 20 April 2015 (UTC)
Advertisement