Minecraft Wiki

Technical/Effective Sound Range Edit[]

I have noticed that you have taken after my "X (technical) / Y (effective)" sound range edits in this edit to the Guardian page. I would like to tell you why I add the spaces between "(technical)", the slash, and the second distance (Y). It not only is a stylistic choice, but it also ensures that the line breaks properly.

In cases where Y is a single character (e.g. "∞"), the risk of an improper line break isn't very high without the spaces. However, if Y is quite long for a single word (e.g. "rider only"), the resulting section of no spaces ("(technical)/rider") runs quite a risk of an improper line break in the middle of the word "rider"! This problem is compounded by the limited width provided by the table. The space after the word "rider" makes sure the line us cut properly, while the space before is simply for symmetry. "(technical)/ rider" looks quite improper and ugly, doesn't it? – Unsigned comment added by The Epicness9000 (talkcontribs) at 18:51, 22 March 2022‎ (UTC). Sign comments with ~~~~

Thanks for letting me know! So I basically copied this format from the sounds section of the Wither article, where it says "16 (technical) / ∞ (effective)". I'm not sure if you have taken a part in the wither page's edit, but if so, I really appreciate the format. I just feel that the guardian sound bug deserves some coverage, despite being a bug, because it has always worked like this since guardians were added. Windwend (talk) 04:22, 23 March 2022 (UTC)
”I'm not sure if you have taken a part in the wither page's edit” Actually, I had. It was simply anonymous, probably forgot to log in. I claimed responsibility for the edit in the talk section once I logged in. TE9K (talk) 07:29, 23 March 2022 (UTC)

Edits and reversions on Map[]

Which premise are you challenging? if you mean "the default assumption is that our articles describe the intended behavior", I believe that's self-evident. If you mean "the {{bug}} template exists to mark exceptions, not assert the obvious", are you seriously suggesting that a template named "bug" is intended to document things that are, by Mojang's own assertion not bugs? This is mere wikipedia:Wikilawyering.

There are over 12000 bug reports on Mojira that are closed as Works As Intended. Is it your intention to insert {{bug}} templates for all of them to provide "proof" of statements that were non-controversial in the first place? What a waste of time, and what a burden of maintenance to editors and distraction to readers that would be! — Auldrick (talk · contribs) 08:23, 29 March 2022 (UTC)

First, please allow me to apologize if my actions have angered you. I do indeed agree with "the default assumption is that our articles describe the intended behavior". However, I do not agree that the {{bug}} template can only be used to demarkate bugs. There are multiple instances on this wiki already, that use a bug tracker reference to prove that a game mechanic is intended. Blackstone#Usage includes one of them. Windwend (talk) 08:35, 29 March 2022 (UTC)
Also, I do agree with you that it's quite a waste of time to add WAI to non-controversial features. Some of them, in my opinion, do need bug tracker references. Take this as an example, because boats preventing fall damage is a relatively new feature (especially in Bedrock), I do believe that we need some official backing, since many people think this is a bug, and are not yet aware that Mojang has marked it as WAI on both editions. Windwend (talk) 08:40, 29 March 2022 (UTC)
I'm not angry, at least I don't think I am. We clearly differ in our estimations of what's useful on the wiki, and I often think your edits are of questionable utility, but I'm not the kind of editor who insists on my vision of the wiki being the "right" one.
That something has been done in the past is not a valid argument for continuing to do it. You are clearly educated, so it surprises me that you would subscribe to such a fundamental fallacy.
I can agree that there are cases when a {{bug}} citation can provide valuable authoritative evidence for a fact. I just don't think it's necessary in the present instance (Map), because while it's true that a player might expect a map to be centered on the player's position, the reason it isn't (and is incompatible with building map walls) is already discussed in the same paragraph. That's persuasive enough by itself, so referring to the bug reports adds nothing useful to the wiki. — Auldrick (talk · contribs) 09:34, 29 March 2022 (UTC)
Speaking of education, your remarks make me think of the education I have received. I was raised in a culture that discourages independent thinking and encourages mindless following of superiors. Maybe this is why I fall into the fallacy that you have described.
I agree that at least in the Map article, the article already explains it very clearly, so no WAI bug tracker links are needed; I will undo my edit immediately. And I also agree that bug tracker links can be useful in certain circumstances. When a game mechanic is thought of as too overpowered, or too illogical, many people might think of it as a bug, and this is when we need some official support that a game mechanic is intended. Windwend (talk) 17:29, 29 March 2022 (UTC)
Thank you. I'm happy that we reached consensus. — Auldrick (talk · contribs) 17:49, 29 March 2022 (UTC)