User talk:Goandgoo

Mods page
There's been a proposal to split the Mods page into smaller subpages (loaders, aesthetic, new content, etc.). You seem to be the unofficial curator of the page, so I'd like to get your opinion about it. -- Orthotope 05:31, 13 March 2012 (UTC)

Hey Orthotope, thanks for that. I didn't know one would call me the 'unofficial curator'!! Anyway, I have embraced the name and have kept everyone posted on the Mod'sTalk page. Goandgoo 09:05, 13 March 2012 (UTC)

Hello mate. I think you added the wrong links for snapshot 30c--130.225.0.218 12:37, 24 July 2012 (UTC)


 * The links use an anchor which I don't know how to change. I believe an admin has to change it.
 * Silly me, I changed it and it's all good now.
 * good good :D now I've made a profile so now i can edit it as well :D --Txd 12:46, 24 July 2012 (UTC)

Your choice of words
Your choice of words is a bit unfortunate. In your commit message of you wrote (Undo revision 353478 by user:Kumasasa (talk) Don't be stupid all you did was remove all of the past few edits. Also, don't fake the change "linked ref", only makes it worse). I don't like to be called stupid and that I would fake commit messages. Yes, I did make a mistake (read: Yes, I did make a mistake) while editing several versions instead of the last version, but that doesn't give you the right to call me stupid. BTW: About making mistakes, read the topic just above this one... --Kumasasa 18:20, 1 August 2012 (UTC)


 * Oops sorry I thought it was deliberate. I will know for next time.
 * Ok, accepted. ...but I don't want to know what you write when you're impulsive ;-) --Kumasasa 21:04, 1 August 2012 (UTC)

Section headers
Level 1 section headers are never appropriate in bodies of articles. Also, some of the pages you just created require a References section. -- Hower64 07:10, 27 October 2012 (UTC)
 * Ok, I fixed them up. Sorry, didn't know that before. Goandgoo. Talk - Contribs 07:25, 27 October 2012 (UTC)

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. -- Orthotope 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. Goandgoo. Talk - Contribs 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 here. (Note the brackets are not displayed outside of the code.) — Hower64 05:49, 10 February 2013 (UTC)


 * Ok, thanks for the advice, I'll keep that in mind for future edits I do. –   Goandgoo ᐸ  Talk  Contribs  Edit count 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. --74.105.190.207 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). –   Goandgoo ᐸ  Talk  Contribs  Edit count 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? –ultradude25 ᐸ Talk Contribs 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 Bed (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. –  Goandgoo ᐸ  Talk  Contribs  Edit count 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. –ultradude25 ᐸ Talk Contribs 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. –   Goandgoo ᐸ  Talk  Contribs  Edit count 12:05, 12 February 2013 (UTC)


 * So can I start adding this to content pages? –  Goandgoo ᐸ  Talk  Contribs  Edit count 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.
 * –ultradude25 ᐸ Talk Contribs 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: User:Goandgoo/Sandbox


 * I think the bugs should be in a collapsed menu to save space. Thoughts? –   Goandgoo ᐸ  Talk  Contribs  Edit count 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. –ultradude25 ᐸ Talk Contribs 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? –  Goandgoo ᐸ  Talk  Contribs  Edit count 08:28, 13 February 2013 (UTC)


 * Minecraft Wiki:Projects/Style Guide. Also I think we should call it "Issues" not "Bugs". –ultradude25 ᐸ Talk Contribs 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 Bedrock 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 History2 template? –  Goandgoo ᐸ  Talk  Contribs  Edit count 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. –ultradude25 ᐸ Talk Contribs 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 sandbox page - 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). –  Goandgoo ᐸ  Talk  Contribs  Edit count 07:40, 14 February 2013 (UTC)


 * –ultradude25 ᐸ Talk Contribs 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. –ultradude25 ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 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? –ultradude25 ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 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."? –  Goandgoo ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;"> Talk  Contribs  Edit count 10:47, 16 February 2013 (UTC)


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


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

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


 * Sorry, what is the BaM page?? –  Goandgoo ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;"> Talk  Contribs  Edit count 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). –  Goandgoo ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;"> Talk  Contribs  Edit count 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? –  Goandgoo ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;"> Talk  Contribs  Edit count 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. — Hower64 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. –  Goandgoo ᐸ <small style="display:inline-block;line-height:1.1em;vertical-align:-1.0em;"> Talk  Contribs  Edit count 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 style guide says titles should be in sentence case, it would have been better if you uncapitalized the m in "Installing Mods". — Hower64 12:16, 21 April 2013 (UTC)