User talk:Goandgoo/Archive 2

Version history
Just out of curiosity, what makes redstonehelper's changelog more official than the one that was already here? As far as I can tell, he(?) has no connection to Mojang or any other source of privileged information. -- 05:49, 22 December 2012 (UTC)
 * Redstonehelper's information was just simply more detailed and better set out than what was previously here. It was not official, I probably should've worded it better. .  -  01:25, 5 January 2013 (UTC)

Couple of notes
Remember to use the show preview button; it helps prevent having to go back just to fix minor mistakes. And just a tip, with the history template, early versions of the game which can only be differentiated by their date of addition can be correctly anchored to by putting brackets around the dates, like. (Note the brackets are not displayed outside of the code.) — 05:49, 10 February 2013 (UTC)


 * Ok, thanks for the advice, I'll keep that in mind for future edits I do. –  ᐸ    05:53, 10 February 2013 (UTC)

Bugs
The purpose of bug lists on content pages is not to have the bugs fixed, but to inform readers that, when they encounter anomalous behaviour, it's a known issue. Ideally, these bug lists should link to the appropriate entry in the tracker. -- 08:23, 12 February 2013 (UTC)


 * The problem I have found is that usually 60% of bugs have been fixed in an earlier version of Minecraft. Also, it is not an effective way to show bugs, as there could be much more prevalent bugs which are present, but not listed on the content pages. Furthermore, I have not seen one content page where the bugs linked to the Issue tracker, probably because people don't list it there. Basically I can't see the point of it being there if it's not going to be kept up to date, or if people just post random bugs there which may actually not be a bug (the issue tracker is monitored by moderators to make sure the bugs are actually bugs, unlike the content pages). –  ᐸ    09:01, 12 February 2013 (UTC)


 * Just consider bugs as trivia. As a new user, I like to know stuff about a block, and to understand why some strange behaviours appear. So bugs should be kept in the wiki (except maybe some too technical bugs)


 * I think we should at least show the most long standing or critical bugs, or perhaps have a way to link to the tracker showing only bugs relating to that page? – ᐸ  11:06, 12 February 2013 (UTC)


 * Ok, I understand your point. However, the problem was, and as I previously stated, none of the bugs linked to the tracker. I remember a few pages, including (go back a few revisions) where all the bugs were simply locked in a hidden section, which messages saying "please check to see if the bugs are current" etc. When looking back multiple revisions, it seems like some of these pages were left for months without change. So  I have an idea. How about on each page in the bug section, there is a page listed with a custom search to the issue tracker - name of block (e.g. Bed) with the following criteria: Project: Minecraft, Minecraft Pocket Edition, Resolution:Unresolved. So that way, it will always be up to date. So if you searched bed with those criteria, you would end up with this page. What do you think? e.g.

Bugs

For all bugs relating to Beds, click here to visit the Issue Tracker.


 * Or at least something like that anyway. – ᐸ    11:53, 12 February 2013 (UTC)


 * And we could use JIRA's API to pull some of those directly on to the page and have that link as a "view more" sort of deal. – ᐸ  12:01, 12 February 2013 (UTC)


 * Great idea, if you could somehow implement this into the wiki (hopefully it's not too hard to accomplish) it will be a great feature, meaning bugs won't have to be uploaded manually. –  ᐸ    12:05, 12 February 2013 (UTC)


 * So can I start adding this to content pages? – ᐸ    02:38, 13 February 2013 (UTC)


 * I've created a simple script which (by default) pulls 20 entries from that link using the page name as the search term.
 * It will search for an element with the #issue-list id and replace its inner text with the issue list once it is downloaded.
 * The data-name and data-num parameters can be used to change the name it searches for and the max results it will return.


 * E.g.
 * – ᐸ  06:58, 13 February 2013 (UTC)


 * That script is excellent! When used in content pages, what should the data-num parameter be set to? How about this:


 * I think the bugs should be in a collapsed menu to save space. Thoughts? –  ᐸ    07:22, 13 February 2013 (UTC)


 * I think 20 or 30 is reasonable (so we don't tax the server too much). Collapsing would probably be best since it avoids the page jumping when the content loads.
 * Here's a template for it issue list. – ᐸ  08:10, 13 February 2013 (UTC)


 * Wow, thanks so much for your help Ultradude. One last question - where is the ideal place for the bugs section? After the history or trivia? – ᐸ    08:28, 13 February 2013 (UTC)


 * . Also I think we should call it "Issues" not "Bugs". – ᐸ  08:36, 13 February 2013 (UTC)


 * Ok, I renamed it to Issues on the Style Guide page, and I also put in the new info about putting in the issues template. I shall start adding the new issues sections. UPDATE: When implementing the template onto various pages, I noticed that some of the search entries were not really all that relevant to the content of the page. For example, in the page, issues such as Buggy light, torch glitch etc were appearing. Anyway to make it so that less relevant entries don't appear?
 * On a separate note, when will we start to use the ? – ᐸ    08:47, 13 February 2013 (UTC)


 * When people actually comment on what they want from the template. That's just a demo of the details view right now.
 * Could change the search to look in the summary instead of the whole issue text. – ᐸ  09:01, 13 February 2013 (UTC)


 * Thanks for making the search more specific. One more suggestion - could you make it so that in the Issues dropdown menu, there are subheaders with Computer version: and Pocket Edition:. I have updated my - please check out my suggestion. I think it will improve the search so new people know which bugs are relevant in the version that they're playing (yes, I know they have different tags - MC and MCPE but it still look neater). –  ᐸ    07:40, 14 February 2013 (UTC)


 * – ᐸ  08:17, 14 February 2013 (UTC)

Just to keep the discussion of the template in one place, I had an idea that I ended up posting on my talk page in the Ocelot topic, but I would like to expand on it. The issue list template is great, and at this point in time, perfect for articles, but I would like to suggest expanding the template to cover other things as well as have more inputs for specific queries. One of the big ideas I have is to have a version input. This way, we can simply use the template in each section on the upcoming features and version history pages, rather than having to format every single bug reported on Mojang's blog or trying to keep track of Twitter posts made by Mojang.

This is where my other input idea comes in, have a "fixed" input to go with the version input. Here's a following example for 13w08a next week (if that will even happen, since 1.5 is getting very close):. This will list anything in the bug tracker applicable to 13w08a with the "Fixed" resolution, and we just slap that in with the changelist for 13w08a on the version history/development versions entry. Dropping the "fixed" arg makes the template fall back to listing unresolved bugs, and then we could use  in place of the "notable bugs" list in the 13w08a entry.

Another input idea I had, which I noted on my talk page, is to have the template accept other resolution inputs, such as "workingasintended" or "wontfix", but as Goandgoo pointed out there, that really isn't a necessary list in articles, but there could be a use for it somewhere. Basically, having the template act as a full query could have very interesting uses.

One last idea is having an arg for a specific edition, like  and we can put that on the Nether Reactor page. I know this is now looking like a run-on post, but I just remembered that the template has a bit of an issue with more than one word names, like NPC Village did. It treated the query as "NPC AND Village", which caused me to think about just getting rid of the NPC in that move request. Should the query work like "NPC OR Village"? 03:35, 16 February 2013 (UTC)


 * It isn't really suitable for that. Loading the development history page alone would cause 21 requests per load. Not to mention the page jumping all over the place from all that content being inserted.
 * The bug fixes at the very least should only be retrieved once and inserted into the page instead of being loaded live. Although I don't know why that's particularly useful since Mojang lists all the bugs they fixed in their blog and all you need to do is wrap them in the bug template.
 * The notable bugs you could either have load on click or only have the most recent version live, although that would mean you have to have an easy way to download a snapshot of the bugs and insert them into the page once a new version is added. Seems more of a hassle than what we already have.


 * In terms of how searching works, I would've thought npc AND village would be better, otherwise you'd get a bunch of unrelated bugs to do with npcs. What I wouldn't mind adding is allowing multiple optional search terms, to try and give the most relevant results. And then you'd be able to use that to do what you want as well.


 * I'm not sure what benefit searching for a specific version would be. "Reactor" would only return results for PE because there's nothing called "Reactor" in the pc version. – ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 03:58, 16 February 2013 (UTC)


 * I see. I seemed to have forgotten about the size of the version history page, and yea, putting it that way for the blog bugs, it isn't that hard formatting them. As for the AND/OR, you are also right. I can't think of anything off the top of my head that has two words that would benefit from an OR search. I was mostly thinking of whether or not someone reporting a bug would correctly use the full name of something, since someone reporting a Reactor bug might not call it "Nether Reactor". And finally, yea, the reactor thing is fine as is, since you already have a "Computer:" and "Pocket:" title in the template. I got a bit carried away with ideas lol.


 * Adding to the optional search idea, that would be great. When I put the template on Ocelot, I previewed using the word "Cat". There isn't any current bugs in the tracker for that, but I can imagine someone submitting a bug using "Cat" instead of "Ocelot", unless the tracker mods are great with revising and replace every "Cat". Same with wolf, where I would assume some people would use "Dog". Using the optional search terms, I would imagine using  or something to ensure everything applicable is returned.   04:34, 16 February 2013 (UTC)


 * Does that change fit the bill? – ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 10:43, 16 February 2013 (UTC)


 * What bill? You mean when you originally said "What I wouldn't mind adding is allowing multiple optional search terms, to try and give the most relevant results. And then you'd be able to use that to do what you want as well."? – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   10:47, 16 February 2013 (UTC)


 * http://idioms.thefreedictionary.com/fit+the+bill And since I was replying to Kanegasi's last reply, yes. – ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 10:50, 16 February 2013 (UTC)


 * Ok, got it. – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   10:51, 16 February 2013 (UTC)

Go Job!
You did good with the BaM page. 22:52, 18 April 2013 (UTC)


 * Sorry, what is the BaM page?? – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   04:22, 19 April 2013 (UTC)

Edit counter
You have to escape the apostrophe in your caption, like this:    12:55, 20 April 2013 (UTC)


 * No wonder it wasn't working - thanks for your help Kanegasi (and also for making the awesome edit counter). Perhaps you should mention that you need to "escape apostrophe's" in the description on the Wikipedia page (unless I happened to miss it somewhere). – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   12:59, 20 April 2013 (UTC)


 * No, I didn't mention it, so I'll have to put that in. It isn't just apostrophes though, there are a few other special characters that mean something in Javascript, but for variables, the single quotes/apostrophes open and close the variable. Also, the ! table headers with the wikitable class overwrite any styles you use. I thought it was just text styles that are overwritten, but apparently it's any style as I realized with your blue background option. The way around this is to use tableHeaders = false and then add font-weight:bold to your topRowAttrib. You could also just take off the wikitable class as well. Make sure to preview these directly on your edit count table before running the script again.  13:09, 20 April 2013 (UTC)


 * This is probably a silly question, but how do I preview the table without actually editing my common.js and running the script again? – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   13:15, 20 April 2013 (UTC)


 * Just like any normal wiki page edit. Go to your edit count page and use the show preview button. Anything in the topRowAttrib variable simply gets pasted after the first |- in the table and anything in the bottomRowAttrib goes next to the second |- after the class="plainlinks" (which removes the external link arrows on the numbers).  13:23, 20 April 2013 (UTC)

Page moves
What do you mean "capitalizing the 'm' for consistency"? And please stop spamming the RC log with lots of consecutive edits to the same page; decide what you want to do and then do it in a single edit. — 11:40, 21 April 2013 (UTC)


 * Sorry Installing Mods had a capital 'm' so I thought Creating Mods should also have a capital 'm'. You can revert it if you thought it was unnecessary. Also sorry about the amount of consecutive edits I will avoid that in the future. – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   11:45, 21 April 2013 (UTC)


 * Consecutive edits are fine, it's just lots of unnecessary consecutive edits to the same page which should be avoided. Since the says titles should be in sentence case, it would have been better if you uncapitalized the m in "Installing Mods". —  12:16, 21 April 2013 (UTC)

Signature
While composing my second comment on the dev versions talk page, I noticed your signature code. What you have for your name,  can be combined into. No need to have more than one span tag for the same element. 03:13, 22 April 2013 (UTC)


 * Thanks, I didn't know you could do that, update my signature. – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   03:16, 22 April 2013 (UTC)


 * No problem.  03:25, 22 April 2013 (UTC)

Bypassing redirects
When bypassing sentence case redirects on in-game names, can you please use a piped link? E.g. change to  instead of just. — 13:47, 22 April 2013 (UTC)

Please do not edit my user pages
If there's a problem on one of my user pages, please tell me about it on the talk page.

Thank you,

&mdash; &middot;  &middot; 15:30, 22 April 2013 (UTC)

"Normally I wouldn't edit other people's userspaces"
 * Normally, editing other users' pages is a blockable offense if it's a recurring thing. is just getting off his third block for continuing to mess with userboxes in other userspaces. Userspaces are not an abnormal thing to edit, they are something you just don't edit. It's common wiki courtesy. The only time you are allowed to edit is to mark spam, revert someone else's unsolicited edit, or revert a rule break. Keep in mind that some rules do not apply in userspaces.   17:32, 22 April 2013 (UTC)


 * Sorry about it, I wil learn for next time. – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   21:51, 22 April 2013 (UTC)

Double redirects
You need to fix. — 03:47, 26 April 2013 (UTC)

- Except for double redirects on user pages. – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   06:12, 26 April 2013 (UTC)

Tutorials/Mob farm revisions
I fixed spelling, grammar, added wikilinks, clarified ambiguities, corrected dubious information, removed opinionated language and redundancy, introduced consistent nomenclature, mentioned caveats of the mathematical formula, formatted the formula so it wasn't extending outside of its box, wikified other formatting, made the article more concise and precise overall,... and you revert nearly everything. Actually, no, you didn't revert it. You pasted the text of an old revision as your edit, completely circumventing the standard reverting procedures and etiquette. What gives? Seriously. Do you even bother reading edit and summary tags in the page's history, or do you just like to  pages? -- and 11:42, 27 April 2013 (UTC)


 * That was not the intention at all. If you had bothered reading the edit summaries this is what is mentioned: "Copied the rewrite from Minecraft Wiki:Sandbox/Tutorials/Mob Farm". As I was looking through the wiki's sandbox, I came across the page and the formatting and such looked far superior to what was already on the page. What I obviously didn't realise was that the 'rewrite' was based off an older revision. That was an overlook on my part. But no I didn't just revert it to an older revision - compare the edits before and after I copied the rewrite. If there is something that you feel that the rewrite missed, feel free to look at the edit revisions and copy it over. Next time please don't make false accusations without actually doing your research. –  ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   12:58, 27 April 2013 (UTC)

Sig title
It only accepts one word because you haven't got quotation marks around it, which you should be using anyway. – ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 08:49, 2 May 2013 (UTC)

– ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;">   11:45, 2 May 2013 (UTC)

Your signature
I never really thought about this until now, but your signature is almost double the limit of 255 characters. If it doesn't fit into the default signature box in your Preferences, it's too long. I suggest using a character counter, such as this one, to aid in trimming it. 22:42, 3 May 2013 (UTC)


 * I've trimmed it down from 420 characters to 317, is that ok? – ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em">   23:29, 3 May 2013 (UTC)


 * I got it down to 270 by trimming the Contribs title and the height numbers, removing all quotes (as ultradude25 hinted at above, it's good practice to always use quotes in tags, but using attributes with no spaces in their values still work without quotes if you need to save space), using a "safe" color (first, third, and fifth hex character in the color you used), and combining the span and triple quote into just a < b>. Except for that title, that's the best I can do without changing the appearance. It's definitely an improvement and I'm more-or-less indifferent now, but someone else may or may not agree. I was just pointing out the excessive length.
 * {| class="wikitable collapsible collapsed"

! Sig
 * – ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>
 * }  00:00, 4 May 2013 (UTC)
 * }  00:00, 4 May 2013 (UTC)


 * Wow, that's an extra 47 characters trimmed off :P Just a quick question - on my info box how can I make it so that the signature is in normal font, rather than Lucida Console?  – ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   00:05, 4 May 2013 (UTC)


 * 00:12, 4 May 2013 (UTC)


 * Thanks for your help Kanegasi! – ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   00:15, 4 May 2013 (UTC)
 * Note: For what you add the edit count link directly to the signature? If you don't need it - you can reduce your ridiculous signature's size further. –Regards, ᐸ <small style="display:inline-block;line-height:9px;vertical-align:-3px">  13:06, 9 September 2014 (UTC)

Tutorials/Item sorter
Why did you delete the content from and redirect it to ? 11:21, 4 May 2013 (UTC)


 * Whoops I meant to have put it into rather than . I moved the content basically because I think a Hopper tutorial is a better place to add on other tutorials rather than something as specific as an item sorter. Btw no content from Tutorials/Item sorter was lost.  – ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   11:44, 4 May 2013 (UTC)

Show preview
You seriously need to use the Show preview button and check your edits. Please don't make me remind you again. — 05:50, 5 May 2013 (UTC)


 * I used the Show preview button but I probably didn't check through the edit properly. Next time I'll double check my edits. – ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   06:19, 5 May 2013 (UTC)

thanks for your help
really goes a long way towards helping me familiarize myself with the format here.

looks like i've got some editing to do! i already have a few in mind.

thanks again!

16:38, 16 May 2013 (UTC)

cheers, -u.

Hey, can you help me?
Hello Goandgoo, I was wondering if you are familiar with modifying Minecraft in any way. Because I wanted to know how I could make it so you can use leads on hostile mobs. If you know how, I'd highly appreciate it if you could tell me, and if you don't, maybe you could direct me to someone who knows how. Thanks :)