Talk: Auldrick

Hi, can we talk?[]

Hey, i want to know why you deleted my edit, The Better Together Update...–Preceding unsigned comment was added by Piporgames (talk • contribs) at 21:06, 31 August 2017 (UTC). Please sign your posts with ~~~~

Generally, articles are supposed to have a consistent layout. For more information, see MCW:LAYOUT. The Blobs 14:02, 1 September 2017 (UTC)

Welcome to the wiki, Piporgames! To answer your question more specifically,

1. Articles should not start with a heading. The initial paragraph, called the "lede", should be a brief (1-3 sentences) summary of the topic, and the article title is its heading.
2. Although it's common knowledge that Sony has not accepted the BTU, they have not publicly given the reason you stated as far as I know, so this is speculation. Speculation in main articles is not allowed.
3. The 7/31/2017 update section had potentially useful content, but included your personal commentary ("sadly", "Obsolete") and "<Adaptation>" tags that look like HTML but aren't valid. Articles should take a neutral, impersonal point of view per the style guide. I couldn't tell what you intended with the tags, and you didn't cite a source for me to research, so I didn't know how to fix it. If you had cited a valid source, I might have tried to work the information into the article. However...
4. Some of what you said is simply wrong: The Xbox 360 and PS3 are not "Obsolete" as long as they can still play their disc versions. I'm sure there are many people who are only interested in playing the minigames, and to them the BTU is irrelevant. They are not being "forced to migrate to newer consoles in order to continue playing Minecraft". They will have to migrate if they want new features, but that's simply a fact of life. When you buy a game, you're entitled to that game as it is; you can usually expect updates for a period of time, but not in perpetuity because technology becomes (i.e. it is not "made") obsolete. What you were doing was complaining about that fact, which you're free to do on many other forums, but it doesn't belong in an article.

With all that said, though, I encourage you to continue editing the wiki, after becoming more familiar with the Layout guide Blobs2 linked above. You might also find the "Editing Help" section on my user page helpful. --– Auldrick (talk · contribs) 15:08, 1 September 2017 (UTC)

Template:Exclusive[]

Hey Auldrick, could you point me to a page or two where console wasn't being recognized by the #ifeq? There's a couple things I'd like to try to see if the problem can be easily fixed (since it makes absolutely no sense to me why a #switch would work, but an exactly equivalent #ifeq wouldn't), and not having to re-break the template and then hunt down such cases myself would probably be the ideal way to go about it. =) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:30, 2 October 2017 (UTC)

I noticed it on Skin/Skin pack, then checked another but I've forgotten which. I think the warning about replacements with a unique string (strip marker) in the #ifeq documentation is causing it. It seems to be saying that because of how MediaWiki works, during the template expansion the #ifeq gets processed at a point in time when its parameters have been temporarily replaced by unique strings, like variable names, and the result is that the #ifeq is comparing the unique strings instead of what they refer to. --– Auldrick (talk · contribs) 17:40, 2 October 2017 (UTC)

Dinoguy1000: I've been investigating myself using a copy of your revision in my sandbox, and I think I might have reverted in panic, though I could swear I saw just "Console Edition" in the Categories: list at the bottom of the pages I checked. I can't seem to reproduce the problem now, though. In part, I got confused because "Console Edition" still appears in the logo and the text beneath it. The logo shouldn't be changed, but the text should, but it hasn't and I didn't think to change it when Goandgoo asked me to change the category. I'm going to try to fix the text now in my sandbox, and I'll restore your #ifeq code when I do (assuming the problem I thought I saw doesn't come back, of course). --– Auldrick (talk · contribs) 18:26, 2 October 2017 (UTC)

How did this go, by the way? It doesn't make sense that #ifeq would have problems with strip markers; I've used it for years with no concern whatsoever over when in the parse it gets handled, and have never run into a problem like this. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:06, 5 October 2017 (UTC)

I have implemented the completely rewritten {{Exclusive}}, using #ifeq where appropriate, and it seems to be working perfectly. I must have been confused by the logo and erroneous (because I neglected to change it) text. The commenting-out-newlines technique works beautifully, letting me format templates much more readably, and I plan to use it from now on. The only concern I have is that people with a programming background might copy the style without realizing that parser functions aren't control-flow keywords. I guess like me they'll learn, though. Thanks again! --– Auldrick (talk · contribs) 17:22, 5 October 2017 (UTC)

User subpages link[]

In case you're not aware, there's a simpler way to link to your user subpages: Special:PrefixIndex/User:Auldrick/. This page doesn't have the prev/next listings links that Special:AllPages does, and can also be transcluded to include the list directly on another page, which is the method I use to generate the list on my own userpage. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:09, 5 October 2017 (UTC)

Or {{subpages}}, which uses Special:PrefixIndex too. Use {{subpages|Auldrick|User}} :D – Dentedharp90041^tce 17:24, 5 October 2017 (UTC)

Thank you, both of you. (And I'm flattered that anybody is watching my user talk page!)--– Auldrick (talk · contribs) 18:17, 5 October 2017 (UTC)

Aah, {{Subpages}} uses DPL... Given that, if all you want is a straight list, and don't care about the formatting, I'd still recommend transcluding the specialpage instead, since that comes with less overhead (and isn't reliant on DPL, which theoretically could end up temporarily disabled or otherwise broken without warning). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:37, 5 October 2017 (UTC)

I already decided to keep the SpecialPages link, assuming it had less overhead, but I'm planning to start a personal project that will involve a number of pages which I'll put in my sandbox. I was thinking {{subpages}} could be a better way to index those. I couldn't find any information about #dpl, however.--– Auldrick (talk · contribs) 18:43, 5 October 2017 (UTC)

NOT Speculation[]

I would like to point out that my contributions to the enchantments page are not speculation all thre enchantments Impaler, Loyalty, and Slipstream Dash are referenced on the official minecraft page and Loyalty's effect was revealed on MineCon Earth and Impaler was revealed on another livestream. The only one not given specific details is Slipstream Dash which is stillconfirmed on the officialpage, we just don't know what the one does or the values for the enchantments. –Preceding unsigned comment was added by ThatManderin (talk • contribs) at 16:10, 27 November 2017 (UTC). Please sign your posts with ~~~~

Please see your talk page. We do not add information about features that have no been added to the game yet, either in a development version or a release. Also, what "official minecraft page" are you talking about (not that it matters in this case). If you're going to cite an official source, give a link to it. Otherwise it's just your say-so. --– Auldrick (talk · contribs) 17:58, 27 November 2017 (UTC)

Splash Potion Duration[]

According to your undo of my change: https://minecraft.gamepedia.com/index.php?title=Brewing&oldid=prev&diff=1223830

I just checked the duration of potions in Minecraft. And since the splash and normal ones have now the same duration, I searched for more information and found this: https://bugs.mojang.com/browse/MC-85891

So the same duration works as intended.

Anything else you need to know? –Preceding unsigned comment was added by Adversarius13293 (talk • contribs) at 16:43, 18 June 2018 (UTC). Please sign your posts with ~~~~

Interesting, and surprising that it's gone two years without being corrected. I admit your edit was correct for Java Edition. However, in Bedrock the splash potion's duration is still 3/4 of the drinkable potion's; I tested it before I reverted your edit. I invite you to restore your previous update with the differences noted, so you can get credit for the edit. Please also specify which duration applies to Legacy Console Edition, if you know. Otherwise, I guess just leave it unspecified. – Auldrick (talk · contribs) 14:59, 18 June 2018 (UTC)

I also find it very suprising, since nearly every information I could find still used the 3/4 effect duration. Would be nice if you could correct it? I am only using the Java edition, and don't know how to correctly edit the differences between each edition in the wiki. I don't want to mess up Bedrock information, just to correct the Java ones. Adversarius13293 (talk) 15:14, 18 June 2018 (UTC)

Edit has been done; see here. We have an {{only}} template to mark differences between versions, but it doesn't fit well in situations like this. We're getting ready to look at a more versatile way to do it, but for now I just wrote it in as prose. – Auldrick (talk · contribs) 15:41, 18 June 2018 (UTC)

Patroller right[]

Hi! Dinoguy1000 has put you in the patroller user group, which allows you to mark other edits as patrolled and rollback edits. It's strongly recommended to take a look at MCW:Patrollers for an explanation of the role, as well as a quick guide. Here's a brief overview of both of the permissions the user right provides:

• Marking edits as patrolled. This basically tells other patrollers and administrators that the edit has been reviewed and any problems both content-wise and formatting-wise, have been fixed - e.g., open HTML tags or incorrect information. Since you're a new patroller, if you're unsure about something, it's better to leave it to a more experienced patroller or administrator. Additionally, you can take a look at Special:log/patrol, to get an idea of when other patrollers mark edits as patrolled.
• Rolling back edits. Clicking "rollback" will instantly rollback all of the last contributions to the page by the user without leaving an edit summary, while clicking the pencil button will allow the summary to be edited. The most important thing here, is if there's any chance that the user was trying to be helpful to the wiki or the information might be correct but you haven't tested it, make sure to leave an explanatory edit summary.

If you have any questions, don't hesitate to ask! Additionally, if you don't want this user right, feel free to ask for it to be removed here, and I can ping Dinoguy.-- Madminecrafter12^{Talk to me} 13:18, 2 August 2018 (UTC)

Thanks for contributions[]

I'd like to say, thank you for your contributions to my attempt to document bedrock NBT data, I hope you keep helping out there so it at one point becomes complete. FVbico (talk) 15:15, 6 November 2018 (UTC)

You're very welcome. I hope so too. It takes a lot of work to tease out a lot of this stuff, and having it all in one place is a major benefit. Thanks for curating it! – Auldrick (talk · contribs) 15:18, 6 November 2018 (UTC)

About Special:Diff/1314690[]

The video is removed on YouTube, my puropse to add it back is for showing the direct quote from Mojang and the link rot. --HaydenBobMutthew ^{(talk, contribs)} 12:20, 1 February 2019 (UTC)

Seed picker[]

Hi. I started an article about the Bedrock Edition seed picker, and then I noticed you had already started one for Pocket Edition at User:Auldrick/Seed picker.

My intent for the article is to expand it with brief descriptions of what features and resources the user can expect to find in the vicinity (say, a daytime walk in any direction from the spawm point).

Good idea to add thumbnails like you did. I'll get to that later. ~ Amatulic (talk) 07:32, 20 April 2019 (UTC)

I've forgotten now why I never completed my version. I'm glad you're picking it up. If there's anything you find useful in my version, feel free to just incorporate it, no attribution needed and no limitations on my part. Mind you, though, that I think (based on things said in livestreams) that the seeds and picker descriptions are going to change in 1.11 or soon thereafter. The changes in world generation have made some of them not very good. – Auldrick (talk · contribs) 19:41, 20 April 2019 (UTC)

Thanks! Yes, the picker will be reduced to 6 choices in 1.11 and then another 10 will be added in 1.12.

I'm kinda disappointed that Stronghold Village is gone. I was playing that at one time. But with 1.11 the strongholds are more rare, so that seed probably doesn't generate a stronghold under the nearby village anymore. ~ Amatulic (talk) 20:20, 20 April 2019 (UTC)

OK, for this new seed picker article, I created Template:Distdir to show range and bearing to interesting features, feeling that listing actual coordinates would be too much of a spoiler. Now that 1.11 is out, I've brought the seeds and thumbnails up to date. I used your graphics for some of the discontinued seeds; thanks!

My next objective is to continue filling in interesting details. The things I have put in come from using the /locate command at the spawn point... but I discovered that /locate doesn't actually locate the nearest structures (I filed MCPE-45526 on this). So I pretty much have to go exploring each world in creative mode to flesh out the true details.

Example of the /locate bug: in "Coastal Village" I found a stronghold closer than the one identified by /locate. The seed picker article lists two strongholds for Coastal Village; /locate found the furthest one, I found the nearer one myself. I suspect that /locate uses taxicab distance rather than direct distance measurement, which feels like a bug to me, because the whole point of /locate is to find nearby things. So given two structures, one 100 blocks directly north of you and another only 80 blocks northeast (113 blocks taxicab distance), /locate will show you the farther one. I think that's what it's doing. ~ Amatulic (talk) 18:24, 1 May 2019 (UTC)

I think there have always been problems with /locate's accuracy. There are lots of times that there's simply nothing anywhere near where it points you, and I imagine it's only gotten worse since the recent changes in world generation (for example, villages can be generated a nontrivial distance from their seed-derived positions when the terrain is unsuitable). I never thought about some of its flaws being explained as taxicab distance versus straight line distance; you may well be correct! Taxicab distance is simply the sum of the differences in integer X and Z coordinates, whereas straight line distance is the square root of the sums of the squares of X, Y, and Z differences, a more processor-intensive floating point calculation that for performance reasons is avoided when possible. – Auldrick (talk · contribs) 22:24, 1 May 2019 (UTC)

Just now I verified, using the /locate command with two known strongholds correctly located by the command, that it correctly uses Euclidean distance. It turns out that /locate can completely miss a structure even when you're on it. When I positioned myself directly overhead the nearer stronghold, /locate still identified the farther one as nearest. I also discovered two ocean monuments in the "Ocean Monument Ahead" seed that /locate fails to find at all. The bug is also reported for Java Edition so I suspect there's some common code that needs fixing. ~ Amatulic (talk) 06:58, 12 June 2019 (UTC)

They're probably still tweaking world generation, including structure generation, with every release. The structure generation logic is highly complex, and at least for some structures it can move the generation origin to better terrain or even abort generating the structure at all. I suspect /locate isn't being kept up to date as they experiment with these tweaks, because the command isn't important for survival gameplay and therefore is treated as low priority for fixes, and also because they're not done tweaking yet. In addition, structure generation can change from one release to the next. If you load a world in multiple releases, a structure that was generated in the earlier release could be generated again (in different chunks that weren't generated yet) in a later release, giving you multiple physical copies of a single logical structure. Even if /locate were being kept up to date, it would only be able to find the latest one. And finally, structure generation can be aborted entirely if the terrain requirements aren't met, so /locate can point you to where a structure should be but isn't. As far as the Seed picker article goes, it's probably best to keep its generated structure descriptions very generic, at least for the present time. – Auldrick (talk · contribs) 13:08, 13 June 2019 (UTC)

Interesting. My tests have all been done in freshly-generated worlds, though. I haven't encountered an instance where /locate points to a wrong location; I've only seen it occasionally miss nearby structures and identify a farther-away one instead. The "Ocean Monument Ahead" seed in the seed picker was the worst case I've seen: several ocean monuments within a few hundred blocks of one another, and a couple of them aren't seen by /locate at all. ~ Amatulic (talk) 15:10, 13 June 2019 (UTC)

Somehow I didn't realize that the bug report you mentioned was one you'd created. I thought you were referring to another report with a similar description (there are many). Your bug hadn't been confirmed yet, so I went ahead and confirmed it so that it can be reported to the developers. I'm sorry it was overlooked for so long. – Auldrick (talk · contribs) 18:29, 14 June 2019 (UTC)

I didn't realize you were a moderator on the Mojang bugs jira. Thanks. Looking back now at my other tickets, I notice that you were conversing with me in the first bug I ever reported, 1.5 years ago (MCPE-30428).

A recent one of mine can be closed: MCPE-46407. I believe I figured out what's going on with iron golem spawning in that case. The new Bedrock village mechanics are strange and unpredictable with respect to spawning cats and golems. I've been slowly updating Tutorials/Iron golem farming as I learn new things but with that tutorial, I find I often have to delete and replace something I wrote earlier. ~ Amatulic (talk) 20:49, 14 June 2019 (UTC)

A question on modes & tense / Also, how am I doing with this?[]

I need a learned linguist's help in understanding this, so I'm hoping you'll correct me where I'm wrong here. First: I've got a big appreciation for your didactic corrections towards me, because second: the only formal education I've had on grammar was in the eighth grade, and I've a feeling that was only because I was lucky enough to have a strict grammarian for a teacher. The rest of grade school and college so far has been literally only critical reading and essay structure, and nobody ever taught me what a "mode" is, so I'm doing all this learning on my own after the fact. I have recently heard of modes, looked into them a bit, and gotten a vague understanding of them, but since our discussion I've been delving as deep as I can into the subject.

This here is regarding a particular thing you said in our discussion on the Minecraft Wiki talk:Style guide:

[T]ense is not an issue here. [. . .] The difference is a subtle one of a kind that linguists lump into a category called "mode", which is distinct from the category they call "tense" [. . .] Unfortunately, both mode and future tense are represented in modern English by auxiliary + infinitive constructions, which has led English speakers to no longer distinguish between them clearly - – Auldrick (talk · contribs) 03:10, 18 June 2019 (UTC)

[T]he usages of "will" + infinitive at issue are not future tense and are not errors – Auldrick (talk · contribs) 04:15, 18 June 2019 (UTC)

If I'm not mistaken, you're implying the conditional mode does not have tense, simply being constructed in a way similar to the future tense: auxiliary + infinitive. My understanding, however, is that mode and tense are different and irremovable descriptions of a sentence's structure—Graphically, they might be represented on separate axes—and all modes employ a verb phrase with tense. Obviously modes can conflict with each other (e.g. A phrase can't be both indicative and imperative). I'm thinking all verb phrases must have tense, so that's why we can't really say a sentence "has so-and-so tense."

Perhaps the first conditional mode usually uses a future tense verb phrase, as if a sentence in this mode is actually an attempt to describe the possible future of some hypothetical event, hence its usual use of "will" + infinitive. There cases of (what I think still is) the first conditional whose verb phrases are constructed distinctly differently than auxiliary + infinitive and sometimes even in different (apparent) tenses. For example:

1. If he got on the wrong plane, then he is in France now.

   EDIT: In retrospect, perhaps this one is better phrased with either would be, should be, or has to be.

2. If my mum had any gluten, then that explains her current abdominal cramps.

   EDIT: Also perhaps better phrased with would explain.

3. If it's that he's been mad at me, then he needed to say something about it a long time ago.

   EDIT: I'd like to rephrase this: If the problem is that he's been mad at me, then he needed help a long time ago.

— JavaRogers (talk) 01:49, 30 June 2019 (UTC)

First I think I should explain that I'm definitely not a learned linguist, just an amateur interested in various aspects of language study. Like you, my formal training in grammar ended after eighth grade English. Since then I've learned on my own and by reading various blogs (I recommend Language Log and Separated by a Common Language). I've also gotten insights from comparing the similarities and differences between how English and German use modal auxiliaries, and between how modern English and Spanish express hypothetical or counterfactual meaning.

I think you probably read the same description of conditional mode that I read when I was researching for my first comments about this. To be honest, I thought it was erratic and incomplete, so I disregarded it, but perhaps you understood it better than I did and can translate the comments that follow into those terms.

The problem I have with the original proposal is that people are seeing the "will + infinitive", which they know only as "future tense", and objecting that future tense isn't appropriate because the wiki should only be describing what is, not what will be. The mistake they're making is in relating the time frame of the conditional to real world time, when in reality it's in its own hypothetical time line. You could say that there is a sense of "future" there (and I've probably been insisting too stringently that there isn't one), but it's only because in a hypothetical world, just like in the real one, a cause precedes its effect in time. But this time relationship of cause and effect is only internal to the hypothetical time line; it's not meant to correspond to any specific time or event in the real world. (That's what it means to be hypothetical.)

Let's use another example to help drive this idea home. Suppose, for a counterfactual condition, we say "If I were [or was] rich, I would buy you a house". Here, "were" or "was" is (in form) the 1st person simple past tense of "be" ("were" is subjunctive mood, "was" is indicative), and "would" is the 1st person simple past of "will". But I don't mean "If I were rich in the past", I mean "If I were rich right now", so should this be in the present tense, "If I am rich, I am buying you a house"? Absurd! This isn't at all what experienced English speakers would write! We intuitively use the past tense forms for counterfactual conditionals, and it never even occurs to us that we could be talking about something in the past.

(Notice something here: Both "were" and "was" are past tense in form, but we don't think of them as having a past tense meaning in counterfactual conditionals. My argument was that it's the same for "will" in other conditionals; it's not talking about the future, except within its own timeline. Hence, it's not a tense marker, but a mode marker in these cases. But I might be wrong about that.)

Unfortunately, when it comes to other kinds of conditionals, it gets muddier because although we're still describing a hypothetical situation, it can be something that also occurs in the real world, at any time, with predictable results. We can conventionally describe such phenomena in two different ways: We can present it as a hypothetical occurrence and predict the result: "If you build it, they will come". Or, we can present it as a repeatable occurrence that has an inevitable result: "When you build it, they come". Whichever you use, the meaning is essentially the same, it's just a question of style. You'd probably want to use the one that's consistent with the surrounding text, (that's what motivated your suggested guideline in the first place). But my argument is that it could be either one; the "future tense" version is not an error, it's just an alternate style choice. (And it's not really future tense in the sense you were saying it was.)

It's been argued that the present tense might be easier for ESL speakers to read, and I can see that, so I'm not opposed to such edits. I'm only opposed to codifying it in the style guide, because native English writers use the hypothetical device intuitively. It would be hard for them to unlearn it for the wiki only.

To clarify about mode vs. tense, I think you're right, they're on different axes. If it's true that tense is irremovable, then I'm wrong, because I haven't been thinking of it that way. But on the other hand, it might depend on who you ask. Linguistics isn't a fully settled science (if it were, there wouldn't be any controversy about English's future tense). I don't remember all the details of how I've come to understand what tense is, but it could be that we're just listening to different experts' opinions. (Or, I could just be wrong.) – Auldrick (talk · contribs) 08:42, 30 June 2019 (UTC)

I miss you[]

You are a very nice person! Thanks for the contributions Marinah (talk) 23:18, 3 July 2019 (UTC)

Regarding my revert on Stray[]

The history section on MCW:FEATURES states as follows:

“

Generally, a change that is reverted after a single version is subject to removal as a bug unless a source is provided that it is intended. An exception is if the bug has existed in at least one major release version and notably contradicts something on the article.

„

-BDJP ^(t|c) 23:14, 25 September 2019 (UTC)

Thank you for taking the time to explain. I searched the Style Guide for "bug" before I removed it, but of course I didn't think of it being in a subpage. (I'm not a fan of subpages, and that's one of the reasons.) But I was going to let it go anyway as not being worth arguing about. – Auldrick (talk · contribs) 23:17, 25 September 2019 (UTC)

Regarding my edit to Damage[]

I wasn't making a reference to a rule, but linking directly to a page as opposed to a redirect is always good practice when editing, at least from what I've seen. --MikhailMCraft (talk • contribs) 15:35, 26 January 2021 (UTC)

I have had similar edits reverted by editors I respected, which caused me to reconsider. I think there are arguments supporting either position, so controversy is possible. I didn't find a specific guideline on this wiki, and it's not clear to me that inheriting the Wikipedia guideline about it as we usually would is the right way to resolve the issue. (It says that links should be directly to the page, but it also says that external links shouldn't be in the main body, so I'm not sure it should apply in this case.) So it comes down to a disagreement among authors, and it's very un-wiki-like to seek to impose a personal preference on other editors. I would be open to having a rule such as you propose, but it should be formalized in the Manual of Style and made available for consensus discussion first.

For comparison, this seems to me very much like edits that merely insert or remove Oxford commas, except that we inherit a specific guideline about those from Wikipedia (either convention is correct, but usage should be consistent within the article). Auldrick (talk) 16:12, 26 January 2021 (UTC)

Villager drops[]

Hi, I was not sure if when a villager is holding an item when you trade with them, that item will be dropped if it is killed. Although I have not opened the game to confirm this, I'm pretty sure it shouldn't happen, as that would be too much of an exploit. Windwend (talk) 22:28, 25 March 2021 (UTC)

Thanks for reminding me that I hadn't actually checked this fact myself. In fact, I only remembered it from the bug report MCPE-78772 on Mojira (I'm a moderator there), but it was verified by another moderator so I'm certain it's true. Whether it's intended is a different question, but the policy on the bug tracker is that we assume it might be true until we have a verifiable statement from Mojang on the subject, so it's currently in a Heisenberg indeterminate state, and therefore legitimate information for the wiki. (The wiki has lots of other descriptions of behavior that is the result of incontrovertible bugs, yet the consensus is that if it's currently true, it can be documented on the wiki even if it's unintended. I don't agree with that personally, but I was overruled.) BTW, I have no idea whether Java villagers drop trade items under the same circumstances, in fact I doubt it, so if you can check that, feel free to tag the statement with {{only|be}}. — Auldrick (talk · contribs) 22:42, 25 March 2021 (UTC)

Mushroom Block[]

I'm in the process of moving the textures containing (ES) to (SE). DeeFeeCee (talk) 00:21, 7 April 2021 (UTC)

Update: The textures should be fixed now. Please re-revert changes. DeeFeeCee (talk) 00:26, 7 April 2021 (UTC)

No, you should undo my revert, but be sure you preview the page and make sure it's not broken any more. That's what you should have done the first time; there's no reason readers should have to see a broken image link, ever. Don't worry about getting accused of edit warring: It's not an edit war unless you do the same edit a 3rd time. As long as it's not broken, I'll have no reason to revert it again and everything will be just fine. — Auldrick (talk · contribs) 00:34, 7 April 2021 (UTC)

Oh, wait, you were moving the images, not adding them. Ok, sorry, but I'd suggest mentioning that in your edit summary to avoid this problem in the future. — Auldrick (talk · contribs) 00:36, 7 April 2021 (UTC)

Sure thing! Thanks for the understanding. DeeFeeCee (talk) 00:54, 7 April 2021 (UTC)

Regarding "RfC: More admins?[]

Could you please discuss there? TheGreatSpring (talk | contribs) (Tagalog translation) 00:11, 9 July 2021 (UTC)

Deleting addon documentation[]

Hi, I've decided to help out a little with User:Auldrick/Projects/Delete Add-on documentation, so I changed the links to official documentation by checking `WhatLinksHere` on all the old pages. There's a few thing to note however:

• Special:WhatLinksHere/Bedrock_Edition_entity_components_documentation has a bunch of links, but they don't seem to actually point the page nor the redirect they supposedly use.

• I created Molang, since the wiki didn't cover the language aside from outdated docs and it would be a shame to not have anything on it after deleting the old docs. This is more of just acknowledging it's existence rather than trying to document it.

(Also I moved MoLang to Molang, but when moving Molang to MoLang I ended up creating another page, so the original Molang is now at Talk:Molang and it should probably be deleted, but I can't do that, since I'm not an admin)

Hopefully I've done everything correctly and you can delete the pages now.

MikelJohnsonF (talk) 15:52, 3 February 2022 (UTC)

Welcome to editing the Minecraft Wiki! I assume you'll look for a response here since you haven't created your Talk page yet. Also, I assume you did this editing before creating a user account, using IP 217.15.63.93. I appreciate the help with the project. I wasn't planning to fix the links, rather I intended to replace the entire list with a link to the Microsoft Documentation main page for add-ons because their table of contents is authoritative and we wouldn't have to change anything if they reorganized their documentation. However, the way you did it can save our readers a click and page download, which is a fair argument for doing it this way, so I'm just going to leave it this way.

The problem you had with Molang/MoLang is that article names are fully case sensitive, so these are actually different articles. We need to get the name back the way it was (MoLang) because this is the official spelling used by Mojang, and we always use official names for the article itself and redirects for alternate spellings, misspellings, plurals, and the like. I'll take care of it if you want me to, or you can take the opportunity to learn how. See Template:Delete for info on how to request a page deletion. Be sure to read the exception about template placement for redirect pages. (BTW, I'm not an admin either; for some reason people sometimes think I am.)

Before we can delete all those obsolete pages, we do have to get rid of the links to them. One reason you wouldn't see links in the linking pages' text is that it's part of a template transcluded on the page, usually one of the ones that go on the bottom of the page. I got rid of most of the transcluded links but I no doubt missed a few. The templates would be in the WhatLinksHere lists too, and once you remove a link from the template the pages that use that template will vanish from Special:WhatLinksHere. You can also use the check boxes on Special:WhatLinksHere to hide transclusions, which would make the list page easier to use.

Again, thanks for the help! I've been a bit ill lately and haven't felt like editing much. Also, if you don't know I'm a moderator on the bug tracker and that's been rather busy lately. — Auldrick (talk · contribs) 19:20, 3 February 2022 (UTC)

Regarding Molang/MoLang name: Mojang does use MoLang for the docs included with game but considering that the Creator docs are a superset of that documentation and that uses Molang exclusively, Molang is probably the preferred spelling. Anyway, I'll leave this to you, since I don't feel super confident about moving stuff again.

I've gone and removed the last links including the ones from the templates. Right now the only thing that links to documentation is the documentation itself and some talk/user pages. I think the pages can be safely removed now.

MikelJohnsonF (talk) 21:41, 3 February 2022 (UTC)

This project is done! :D MikelJohnsonF (talk)

Thank you for all the work you did! You deserve all the credit for it. — Auldrick (talk · contribs) 14:35, 16 March 2022 (UTC)

You undid my edit regarding iron golem summoning mechanics[]

You undid this edit by me: https://minecraft.fandom.com/wiki/Villager?diff=2108861&oldid=2108860 My reason for the edit: Before the edit the article said if iron golem summoning was successful all villagers inside a 32x32x32 cube would get their summoning timers reset. After a review of the 1.18 source code I found that it is only a 20x20x20 cube. Your reason for the undo: was correct as stated for Bedrock. When making changes like this, please remember to check both editions instead of assuming they're the same

The edit is clearly referring to Java though as the paragraph regarding Bedrock starts below my edit point. Please take a look again, thanks! 89.246.48.8 20:58, 20 March 2022 (UTC)

No, your edit does not "clearly" refer to Java, that's why I undid it. There is no edition restriction in that paragraph. There is in the previous paragraph, but not the one you edited. Text that isn't marked with a template such as {{only}} or {{IN}} does not implicitly refer to Java, it implies both Bedrock and Java. I undid your edit so that you could make it again but with the appropriate template. I would have put the template in myself but I don't have Java and therefore can't check your statement, so I didn't want to risk expressing the facts incorrectly. If you or someone else adds the required template in the next 24 hours, the matter will be settled. Otherwise I'll undo it again. — Auldrick (talk · contribs) 23:09, 20 March 2022 (UTC)

Okay now I see the reason, thank you. The paragraph was not referring to either version making it ambiguous. I don't know the mechanics of golem summoning in Bedrock so this info will be missing after I do this edit for Java. Ziron5 (talk) 09:05, 21 March 2022 (UTC)

Your current edit summary says you verified it by testing. Please understand that that's not necessarily a reliable way to get facts. With testing, the results you get could depend on conditions you didn't expect to be pertinent and therefore didn't vary during the test, so you never saw that the conditions change the result. This is why important facts need to be sourced by Mojang, not testing. Your edit summary also says you checked it in the source code. Since the source code comes directly from Mojang, it is an authoritative source and can be relied on as long as you're reading it correctly. (And of course it can't be modded.)

As it happens, I just found out yesterday that when you know something for one edition and not the other, one way it can be handled is to assume it's the same for both and mark it with a {{Needs testing}} or {{Verify}} template. I recommend this tool, although not in this case because the Bedrock iron golem details are already present in a later paragraph. (And besides, I feel like the golem spawning details belong in the Iron Golem article, which is already linked with a {{Main}} template. Repeating them in Villager just creates more maintenance work, and tbh I'm not sure they say the same thing right now.) — Auldrick (talk · contribs) 14:45, 21 March 2022 (UTC)

Apprechiate the info, I'll remember it. For the verification of the edited fact I'll just briefly break down the relevant source code here as I don't know where else to prove it.

(I've deleted the "proof" because it's irrelevant. I don't know enough about Java to understand it, and if it's meant for somebody else it doesn't belong on my talk page. — Auldrick (talk · contribs)

Ziron5 (talk) 15:39, 21 March 2022 (UTC)

I don't seem to be getting through to you. Let me try again.

• You can't, and don't need to, prove your facts to me because not being a Java player I have no way to verify or test them. You might need to prove them to another Java player if they challenge your reasoning, but if I were you I'd wait until you're challenged.
• Testing is not a reliable way to obtain facts. Suppose you were interested in learning how slime spawning works. If you didn't already know that Y coordinate matters in some cases and biome type and moon phase matter in other cases, would you even include those as variables to be tested? Almost certainly, you wouldn't, and therefore whatever results you obtained would be partially true at best. Furthermore, if you did somehow learn that these variables can control spawning, don't you have to ask yourself what else depends on them? From then on, every test you do for anything should include these as variables at first, until you've eliminated them as possibilities for the particular test you're doing. But these are just the 3 you know about; there are many, many more. What about time since you last slept? The dimension you're in? Whether you currently have the invisibility effect? To give reliable results, your experiments should include a test against every combination of these and hundreds of other variables. Obviously, that's totally impractical, and therefore testing is not a practical way to obtain reliable facts.
• On the other hand, source code (or anything that comes directly from Mojang) yields 100% reliable facts as long as you're interpreting it correctly. If you don't have a reputation for interpreting it correctly, you might be challenged and then you'd have to prove it, or you might learn how you misinterpreted it and avoid that mistake, eventually earning the reputation. But it isn't necessary to prove facts based on source code from the outset, in most cases.
• One more thing: I got 3 separate emails for this page because you edited and saved it 3 times. Similarly, your edits to Villager were saved multiple times generating multiple emails. You can avoid spamming page watchers by using the Show Preview button (or equivalent mobile function) while editing and only use Save Changes when you're done. Thank you. — Auldrick (talk · contribs) 17:37, 21 March 2022 (UTC)

I apologize for the spam, thank you for helping me through my first edit. Ziron5 (talk) 10:21, 22 March 2022 (UTC)

Regarding enchanting mechanics for 1.18.2[]

Hi, you reverted my edits for enchanting mechanics for 1.18.2. I don't know if you have been following the changelogs for 1.18.2, but it's in there. The code supporting the new mechanic is: return world.getBlockState(tablePos.add(bookshelfOffset)).isOf(Blocks.BOOKSHELF) && world.isAir(tablePos.add(bookshelfOffset.getX() / 2, bookshelfOffset.getY(), bookshelfOffset.getZ() / 2)); Please can you accept my changes without reverting them? – Unsigned comment added by Earthcomputer (talk • contribs) at 16:34, 1 April 2022 (UTC). Sign comments with ~~~~

First, I checked the changelog for Java 1.18.2 before I reverted. It does not contain either of the strings "book" or "ench", so obviously your claim that it's there is false. Second, according to Help:Official_sources, Java code is not an authoritative source. You can use code changes to identify mechanics that may have changed, but you still have to verify your understanding of the code by testing how it behaves in-game, and the testing must be easily reproducible so that others can confirm your analysis. Third, you need to always remember when editing that Bedrock exists and that there can be differences between the editions. You therefore must either qualify your change as being specific to Java or you must confirm that it applies to both editions by testing it in Bedrock. (A third option, if you're unable to test it but fairly certain that it works the same way in Bedrock, is to use a {{Verify}} or {{Needs testing}} template to warn readers and request another editor to confirm.) In the present case, I can tell you for certain that there's no evidence that anything to do with enchanting table bookshelf placement has changed in Bedrock, so the older text and diagrams must remain in the article even if you can substantiate changes in Java 1.18.2.

So I'm afraid I cannot leave your edits alone. Also, I think it was kind of rude of you to begin a dialogue to resolve our controversy, then impose your edits again without waiting for me to respond. — Auldrick (talk · contribs) 17:24, 1 April 2022 (UTC)

The string "ench" appears 4 times on the Java edition 1.18.2 page, and "book" appears twice, make sure you don't have "whole words" selected when searching the page, possibly? I will redo the changes but specify that they are only for Java edition, keeping the old stuff in for Bedrock edition. In future maybe you could point out that the change was Java edition only rather than just reverting it because it's "unsourced" (where do you even expect me to get a source from? I showed you the code, and you can verify it in-game if you don't believe me; the bug report linked in the changelog only covers half of the actual change that was made). Pointing out the actual problems with people's edits might go a long way to not discourage people from fixing incorrect information. The official sources page you linked says that sources are only required for information that cannot easily be tested in game, this can be. Earthcomputer (talk) 18:05, 1 April 2022 (UTC)

I did not search incorrectly. Those strings do not appear on the official changelog at https://feedback.minecraft.net/hc/en-us/articles/4531177623437-Minecraft-Java-Edition-1-18-2-. What are you looking at?

...the bug report linked in the changelog only covers half of the actual change that was made'. Are you saying that you're using a bug report as a source? Then you need to identify it using a {{bug}} template. And if it only covers half, what covers the rest? — Auldrick (talk · contribs) 22:15, 1 April 2022 (UTC)

How much more official is needed than "it says so in the code"? Changelogs can have mistakes in them and often do. Unless you suspect that there is some weird side effect of an unrelated part of the code that breaks exactly the thing that Earthcomputer was looking at, the code is ground truth. Fabian42 (talk) 22:27, 1 April 2022 (UTC)

The whole purpose of source citations is to allow readers to independently verify the given facts. Only a very few people would be capable of analyzing changes to code in order to verify the effect on game mechanics Earthcomputer claims, so with no other source than the code it is not enough. This is why the rules only require source citations for information that can't be easily tested in-game. If testing refutes a conclusion obtained through code analysis, obviously the analysis was wrong and should be disregarded. If testing confirms the conclusion, that's all you need and the code is irrelevant. To put it succinctly, testing trumps code and makes it superfluous for citation purposes. So the only time code can be useful for verifying facts is if it comes directly from Mojang, which deobfuscated code does not, and is sufficiently transparent that virtually anybody reading it can easily predict its effect on game mechanics, which I'm pretty sure is never true in general and is definitely not true given this code sample. Earthcomputer is effectively demanding that I take their word for it that the code change they've cited proves their facts. I am not obliged to do that. Instead, they are obliged to prove it by testing. And at the moment, they have not given any evidence of having done so. — Auldrick (talk · contribs) 23:47, 1 April 2022 (UTC)

Since articles don't contain testing instructions, does it matter if Earthcomputer read the code or tested it? Would you be happier if they claimed to have tested it and never mentioned the code? You can test it to verify it, if you want. You're not hindered from that by someone else reading code. If I understand it correctly, that only involves placing about 5 blocks in the right arrangement a couple of times and checking the enchantment table before and after. Your verification method is independent of the discovery method.

Also, whenever randomness is involved, I would definitely trust code more than experiments. People make mods based on this decompiled code, it's not like it's unrelated to what the game actually does, it IS what the game actually does. Fabian42 (talk) 23:55, 1 April 2022 (UTC)

Would I be happier if they claimed to have tested it and never mentioned the code? Yes, that's precisely what I expect. Their edit summary should mention that they tested it. Trust the code if you want, but when you edit the wiki you need to follow the wiki's rules for authentication. — Auldrick (talk · contribs) 00:02, 2 April 2022 (UTC)