User talk:BDJP007301

Snapshot bug fixes sections
Hello,

I'm Aaron, I've been doing the work on the bug fix sections these past handful of months. I've seen you working on the fixes lately, and I like it, it's good to know it's getting done. I only haven't been keeping up because my little netbook died and I am between machines right now.

I generally try to do a good job and make sure the bugfixes go to the snapshot page that represents actually where the bug was fixed, rather than where the tracker says it was fixed -- and I noticed you doing that as well. I know the tracker software doesn't let the mods mark them fixed in the right version oftentimes, and frankly it would be a huge job for them in addition to what they already have to do, so I don't blame them.

So I just wanted to let you know, I was not able to test the bugs in 14w30a, 30b, 30c or 31a, I just put them there with the intention of sorting them out later. Feel free to tackle that if you are so inclined. If not, I'll get to it, but in either case thanks.

Any questions, lemme know.

– Sealbudsman (Aaron) (talk) – 19:59, 4 August 2014 (UTC)

Removal of Fixes
May I ask why you removed Fixes from 14w32d? The main point of the template removes the problem of several mistakes that are commonly made, (forgetting to update number, forgetting to sort by number), and it automatically makes the better version of the tracker link. It is also not at all complicated to use. --KnightMiner  (t 02:29, 9 August 2014 (UTC)

IK about that. The reason why I removed it was because it was basically too confusing for me. You see, I'm basically just not used to sudden change. --BDJP007301 (t 04:31, 9 August 2014 (UTC)


 * The main reason I was switching it over was because it would likely be used on all version pages at a later time, and it was easier to only need one system between 1.8 and it's snapshots. Also, I figured if I added it to the latest snapshot, it would get used when the next one got made. --KnightMiner  (t 21:54, 9 August 2014 (UTC)

Issues for 1.4
Hi there, if you have time or are interested, would you be able to link up the bugs from 1.4 (versions + snapshots) to the bug tracker, and sort them? At the moment most of those pages don't have links to the bug tracker, and seem fairly incomplete. Thanks –Goandgoo ᐸ Talk Contribs Edits 12:52, 12 August 2014 (UTC)

Will do. --BDJP007301 (t 13:15, 12 August 2014 (UTC)


 * Hello, I noticed that you put the bugs on the 1.4.3-pre and 1.4.2-pre pages, and I was wondering how you knew that those bugs were fixed in those versions. – Sealbudsman (Aaron) SealbudsmanFace.png (t|c) – 15:05, 12 August 2014 (UTC)

I ordered the bugs by how they were created and sorted them from the beginning to end. Afterward, I clicked on the fix version (in this case, 1.4.2 / 1.4.3), and found yet even more bugs that were fixed in those versions. I was able to sort them out by affected versions, creation, etc on the pages. --BDJP007301 (t BDJP007301 16:21, 12 August 2014 (UTC)


 * Once you have finished linking to the bug tracker, 1.5 also needs to be sorted. –Goandgoo ᐸ Talk Contribs Edits 21:16, 12 August 2014 (UTC)


 * Just started working on it tonight, and I'll continue tomorrow! :) --BDJP007301 (t BDJP007301 01:52, 13 August 2014 (UTC)


 * Hi again, here is a list of all the versions without a sorted fixes section/possibly incomplete: 1.7.1-pre, 13w11a, 13w12~, 1.5.1-pre, 1.6-pre, 1.6.3-pre, 1.6.2-pre, 1.4.4-pre, 1.4.5-pre, 13w25c, 1.6.1-pre. Thanks for your help in fixing up these sections :) –Goandgoo ᐸ Talk Contribs Edits 13:31, 14 August 2014 (UTC)


 * Will do. Always a pleasure to help. --BDJP007301 (t BDJP007301 13:42, 14 August 2014 (UTC)

Bugs reopened in the bug tracker
Good morning, a few things:

Tip; when you remove bugs because they are 'reopened', be sure to also search the wiki for all instances of the bug (usually searching by the bug id number is enough), because it could be listed in several places; like the bug you just removed from 1.7.10 was also listed on the snapshot page. I've been doing that so far for your reopens, so no worries to this point.

Also when you put things on (for instance) 1.8 snapshots, and they are listed as affecting 1.7.x or lower, you can also go ahead and list them on the 1.8 page as well, cause basically for a player that's not playing the snapshots, they are bugs that a player would see fixed when he jumps from 1.7.10 to 1.8. I've been doing that so far for bugs you put on snapshot pages, so again, no worries so far, but I thought I would mention it, it's a simple thing I think.

Also I noticed you were keeping track of bugs 'reopened' and I thought to myself, is BDJP doing it in a more efficient way than I am? Because my way of keeping track of reopened bugs is actually kind of hectic and time-consuming in my opinion, as opposed to my way of keeping track of newly-closed bugs, and I would love to know if you have a better way.

Cheers,

– Sealbudsman (Aaron) (t|c) – 14:47, 18 August 2014 (UTC)

1.8-pre
Atomoclk00 here, the changes to Realms on the 1.8-pre-release page were added back in 1.7.10, I am not vandalising I'm getting rid of false information. -Atomoclk00 (talk) 11:41, 22 August 2014 (UTC)

Broken MCF and Tumblr links
Hi,

The links for your MC Forums account and Tumblr contain "http://" twice, redirecting anyone that clicks on it to http.com. :) -Sonicwave (talk) 04:33, 15 November 2014 (UTC)


 * Fixed! Thanks for the heads up! BDJP007301 04:49, 15 November 2014 (UTC)


 * By the way, you could use - to removed the need for all those line breaks after your userboxes. –KnightMiner  (t 05:07, 15 November 2014 (UTC)

I don't know what happened
I messed up confusing ladders by stairs and I'm sorry, in my language they are referred by the same word. Kkkllleee (talk)kkkllleee


 * Its okay. BDJP007301 04:31, 2 January 2015 (UTC)


 * On another subject: What are you talking about, community names are relevant, people reading the page would be less confused, that's why we have eye of ender/ender eye, mushrom stew/mushroom soup, crafting table/workbench, it's not new to have alternative names make it into the wiki, so my question is: what is your standard?
 * Kkkllleee (talk)kkkllleee


 * My standard is that we should go by what Mojang says the name of the block / item it is. BDJP007301 05:45, 2 January 2015 (UTC)


 * Then how do you explain the names I just said? Every time I do something I do something wrong. Kkkllleee (talk) 05:51, 2 January 2015 (UTC)kkkllleee


 * Its mainly based on three factors: in game name: past and present, names used by mojang, or internal name (name in the code).
 * Ender Eye is the name in the code for Eye of Ender
 * Mushroom Stew is sometimes called soup by Notch and in the code
 * Workbench is the internal name of the crafting table, as well as the old name
 * And don't be too worried about messing up at first, most of us here messed up at first too.
 * – KnightMiner  (t·c) 16:35, 2 January 2015 (UTC)
 * Can you help me adding the marker tag addition to the armor stand? 	Kkkllleee (talk) 20:11, 2 January 2015 (UTC)kkkllleee

Punctuation in quotations
Concerning your undo here -- it's the convention in American English that punctuation that follows quoted text is moved inside the quotation (for example, Rule 3a). As a programmer I think it's a terrible convention (and thus I don't feel strongly motivated to undo your undo), but it is the convention and no explanation/edit summary should be needed for such a "simple" punctuation correction (though the third paragraph of changes was more questionable). Not asking for anything, just expressing an opinion. :) &mdash;munin &middot;  &middot; 18:17, 16 March 2015 (UTC)

Planned versions
You have been saying that "items that existed before" doesn't make sense. What I mean is items that already existed in survival mode, but now appear in creative mode. Hopefully this gives you a clarification. ~From Contrapple 02:56, 19 March 2015 (UTC)


 * That's now how the creative inventory additions part works. Its meant to talk about additions to the creative inventory, not items that existed before. There was no consensus to add that part in, so that's why I removed it. BDJP (t 10:01, 19 March 2015 (UTC)

Reverting replies to old comments
Since the addition of the MCW:Talk page guidelines, it is no longer disallowed to reply to old comments (advised against, but not disallowed). While I doubt most users will restore the comments, adding the comments is not against the rules anymore. – KnightMiner  t/c 15:07, 27 March 2015 (UTC)


 * Looks like I'm suffering from a bit of jetlag then. BDJP (t 15:15, 27 March 2015 (UTC)

Special:Diff/820247
User:LauraFi/Upside Down? – LauraFi -  talk  01:22, 2 April 2015 (UTC)


 * Yep. BDJP (t 01:50, 2 April 2015 (UTC)

bug fix template
Hi, I'm looking at the way you edited the bold subcategories under 1.8.4 (from versions before 1.8.4, for instance). I know there's no written rule on how those are supposed to be categorized, but i noticed we seem to have different ideas about it. Whereas i had categorized the bugs by whether they were from the last major release (1.8), or from before that - you seem to have put them all in one category... Bugs occurring since before the 1.8.4 release.

One, that category is like, every bug, by definition.

Two, the point of these bold headers, when they were introduced, i dunno if it's been changed, was to give a broad sense of what bugs affected what versions. Like, how old they are essentially. For instance in a 1.8 snapshot it was always last snapshot, 1.8 snapshots, or released versions. The distinction is there because if you never play snapshots, you don't necessarily care about a certain set of snapshot only bugs, so you can just pay attention to category 1, and if you do play snapshots, and follow them weekly, you'd be interested in category 2 and 3.

Likewise when you have a release like 1.8, you can have fixes for bugs in the most recent minor release (1.7.10), fixes for bugs in the most recent major release (1.7.2), and fixes for older bugs. They kinda form these natural categories, and it tells you something useful about the age of the bug.

Likewise with 1.8.4, you can have fixes for bugs in the most recent minor release (1.8.3), fixes for bugs in the most recent major release (1.8), and fixes for bugs before that.

Anyway long story short, was just wondering what your thoughts were on that, also wondering why you would use just one category. I know there's nothing written about it, for these release versions like there is for the snapshots. – Sealbudsman (Aaron) t/c 14:40, 17 April 2015 (UTC)


 * Usually, what I like to do is look up the bug report which was posted and then just look through the affected versions to check to see if it wasn't just in a development version. As I'm autistic, I usually like to take things in a very literal nature. Basically, I look for a version that shows that this bug is actually in a full, major release of the game (a.k.a I really don't like just adding a bug based on what the root version was when this bug was first discovered (a.k.a I usually take it from a major release onward)). Taking for example, it shows that the bug was originally in a development version, but then passed on to other "major releases". What I'm basically trying to say is that the root version usually doesn't matter when it comes to adding bug reports. BDJP (t 19:58, 17 April 2015 (UTC)


 * Okay, I see. And to clarify, I agree: for these bug lists in major releases, for instance 1.8.4, I don't care to mention whether the bug originated in a snapshot.  I also look to the first full release.  Taking your example,, it looks like that's 1.8.1.


 * What I'm saying is, the bold headers are to signify how old a bug is. For example, categories for 1.8.4 would possibly include (looking at the fixdate only):
 * bugs older than 1.8 (none),
 * bugs since 1.8, the prior major release (from at the fixdate:, , ),
 * bugs from 1.8.3, the prior release.


 * Furthermore, I'd argue two things:
 * I'd move to the 'old' category, since it's well documented as being as old as 1.6.4.
 * I'd move, since it occurs in a 1.8 snapshot, so it's likely actually occurring in 1.8. (Actually, whether it occurs in 1.8 is easily checked, but I'm not at home to check)
 * The result would look like this.:
 * bugs older than 1.8 ,
 * bugs since 1.8, the prior major release (from at the fixdate:, , , ),
 * bugs from 1.8.3, the prior release (none).
 * – Sealbudsman (Aaron) SealbudsmanFace.png t/c 21:10, 17 April 2015 (UTC)