User talk:Notmyhandle

Pokemon RS&E - Sprites
Hi NMH. Whilst i was going around adding PRS&E sprites into a category (Category:Pokémon Ruby and Sapphire images), i have found several files with incorrect names. As i am replacing the files currently, please could you delete these files to avoid any confusion?? Thanks, --Danneal12 (talk) 09:43, 14 April 2014 (UTC)


 * http://strategywiki.org/wiki/File:PRS%26E_Triathalete_Runner_M.png
 * http://strategywiki.org/wiki/File:PRS%26E_Triathalete_Runner_F.png
 * http://strategywiki.org/wiki/File:PRS%26E_Triathalete_Biker_M.png
 * http://strategywiki.org/wiki/File:PRS%26E_Triathalete_Biker_F.png
 * http://strategywiki.org/wiki/File:PRS%26E_Triathalete_Swimmer_M.png
 * http://strategywiki.org/wiki/File:PRS%26E_Triathalete_Swimmer_F.png

As i tried to upload new files, they identified that they were similar file names and so told me to add to each file instead. Therefore, could you just change the file names instead of deleting them - thanks!! --Danneal12 (talk) 09:43, 14 April 2014 (UTC)

Concerning Lego
If that's the way Wikipedia handles it, I will never object. I defer to Wikipedia whenever I am unsure myself. Interestingly, there's a discussion about that topic on the talk page for Lego, but their wp:Wikipedia:Manual_of_Style/Trademarks is consistent in that it recommends Time, Kiss, and Asus over TIME, KISS, and ASUS. As such, LEGO should be Lego. I guess if anyone ever objects to it on this site, we'll have to refer them to that page. Or officially adopt it into our own guide, and site them as the source for the decision.  Pro cyon  02:25, 15 April 2014 (UTC)
 * My view is that is Wikipedia's encyclopedia style and we can be more gamer/corporate specific. I feel we should match the actual game name as closely as possible (within technical limitations). -- Prod (talk) 04:30, 15 April 2014 (UTC)
 * Sticking with sentence case/Wikipedia is better IMO since we can justify our position with that rationale. Sticking with corporate typesetting also has its rationale though... both are arbitrary. Bleh. Also, maybe some day someone will code a bot to import all of the intros from Wikipedia and auto-stub all of the thousands of games we are missing. -- 05:33, 15 April 2014 (UTC)
 * The only problem with that rationale, is that you always see "Super Mario Bros." written in capital letters on the box, and on the title screen, but we don't name the guide "SUPER MARIO BROS." even though that would match the type setting. Admittedly, the Lego issue is a bit different, but ultimately if the proper redirects are in place, it should be somewhat arbitrary, as long as it's consistent across the entire site.   Pro  cyon  14:04, 15 April 2014 (UTC)
 * My preference would be we go by the trademarked name. Or the name they use when talking about the game (like in the manual or on the website). -- Prod (talk) 14:14, 15 April 2014 (UTC)
 * , the only downside to that is some games have multiple typeset spellings. Check out Picross e. I used sentence case here because the game is named "picross e" in the box art, and on its website it is "PICROSS e". Which would you choose? -- 15:26, 15 April 2014 (UTC)

My Activity
Sorry I haven't been active as much. I recently became promoted to bureaucrat/admin on Maple Wikia. I'll see if I can be more active.

Also, I'm guessing Prod hasn't recovered the quest data for me that was lost in that rollback yet. --PirateIzzy (talk) 05:53, 24 April 2014 (UTC)

In-line image overkill
Hey NMH. I'm getting really concerned about the frequency of the use of in-line images in the LOZ guide. For example, in The Legend of Zelda/Underworld/Quest 1/Dungeon 5, why does every instance of an item or monster name necessitate an in-line image? For one thing, the first instance of the word Dodongo doesn't even refer to an actual encounter with them. The second instance is the actual encounter, so why does the first instance need the image? Then there's all the Gibdos and Keys. The page has become so busy, that it's actually harder to read than it used to be. Images distract the eyes from text. In-line images should really be used sparingly, as a way to direct readers to point of particular interest. On that page, the Whistle is really the only absolutely necessary in-line image. Then maybe the Digdogger, map, compass, heart container, and triforce. Everything else is kind of surplus, and makes it look more like a "My first book" for little kids who can't fully read yet. Can we scale it back, even just a little?  Pro cyon  01:28, 8 May 2014 (UTC)


 * Yeah I was thinking about that threshold while I was making the edits. I think that initial references to the object makes sense, but if a section refers to the object multiple times, then those additional references don't need it. However, on Dungeon 5 there is no repetition. If a section is more clear then it should be revised. For example, I changed the unordered list to ordered. I added a small reference in step 3 that clarifies that the bomb is used to bypass the future dodongos. However, I need an expert to identify which step it bypasses them in. My vision of all completed guides is to have heavily referenced in-line images like these so that it reads like a madlib book. The thresholds to choose, to refine our aesthetics, are: image size (which determines clarity of the image and line spacing), frequency (how many in a given amount of space), and limits (are bosses out of the question?). The main benefit to these in-line image templates are not only visual guides - e.g. they can be read by scanning the images rather than having to read any text at all, but the cross-page linking that allows for quick reference to the appendices. Text-majority writings are only for technical details. -- 01:47, 8 May 2014 (UTC)
 * One interesting way we could organize guides for sections of games that have grid-based maps (where we have a map that can be used to reference specific rooms), is we could have table-based pages with a row for each room, or a header for each room. I'm thinking of columns like: |room (xy coordinates)|details|exits to|items found|enemies found. -- 01:50, 8 May 2014 (UTC)


 * I guess what I'm trying to argue for is "less is more". I think the way we handled A Link to the Past was really good.  For example, if a player visited The Legend of Zelda: A Link to the Past/Skull Woods and was only interested in figuring out where the Fire Rod is, they could visually scan the page until they found the Fire Rod, and read the surrounding text.  Images are used sparingly, so when they're used, they really stand out.  You're also right about the size of the images.  The enhanced version of the sprites were enlarged for visual appeal on the items page.  They make poor in-line image substitutes.  To do it correctly, unaltered and original sized (1:1) sprites should be used (like in A Link to the Past) instead of trying to shrink down enlarged images.  They would be 16 pixels high and fit within the text really well.  That would also be a lot less taxing on the server.   Pro  cyon  02:17, 8 May 2014 (UTC)


 * I can agree with both points. If you would be so kind to upload the originals, I will implement them. Please see my modifications to the in-line image guidelines, here. -- 05:46, 8 May 2014 (UTC)
 * I constrained the images to 16px height. Take another look at The Legend of Zelda/Underworld/Quest 1/Dungeon 5. The visual disruption to the text is much less now. Does your opinion still stand? I feel like the general rule of thumb should follow Wikipedia's rules for using links. That is, if the topic is re-mentioned in the same paragraph, don't re-link, but multiple links can occur on the page. I do not know what Wikipedia's guidelines for lists is, though. -- 05:56, 8 May 2014 (UTC)
 * IMO, it still feels a bit busy. In addition to A Link to the Past, I realized that Castlevania II hit the ratio of in-line images to text really well also.  That's what I wish LOZ was shooting for.  As far as uploading new images, there's two approaches we can take.  One would be to leave the enhanced images, and upload unscaled images just for in-line images.  The other would be to replace the enhanced images, and upscale them just for the items page.  Any preference?   Pro  cyon  00:14, 9 May 2014 (UTC)
 * My view is that images overall should be used sparingly. We use all copyrighted game images under fair use, meaning each copyrighted image is there for a reason.  If we're having in-line copyrighted images, they should be there to highlight something very specific. -- Prod (talk) 01:04, 9 May 2014 (UTC)


 * Enhanced images are not helpful imo. Sprite rippers, artists, and walkthrough people want sprites, not some alternate version. The style is cool, but should not be used to replace the original sprites people are used to seeing. I don't have a way to understand the threshold you guys want to implement. -- 01:43, 9 May 2014 (UTC)
 * OK, I'll work on replacing the item sprites. But the threshold should be very straightforward.  Items should only be in-lined whenever/wherever they are actually found.  Important items are definites, items found once in every dungeon are probablies (maps, compass, heart container, triforce), other common items are iffy in my book (keys, bombs, rupees).  Personally, I think a good guideline for Monsters is that they should only have an in-line image once per page.   Pro  cyon  03:13, 9 May 2014 (UTC)


 * I have modified the help page, and am implementing a more reserved approach. I think that if it is in a different section, that the "count" should be reset so that a new reference can be used. Also, a bit related, it looks like we are missing a Blue Gohma boss sprite, if you can dig one out for us that would be great. -- 17:45, 9 May 2014 (UTC)

Skin-dependent layouts
I had been wondering why you were revising the layouts of my Crystalis edits until I realized StrategyWiki has more than out layout skin. The problem is that we are working at cross-purposes because we use different skins. It appears to me you are editing with the Monobook or Vector skin in mind whereas I tend to use Dolphin. My layouts look good in Dolphin and Whale but not in Monobook, whereas your layouts are the other way around. Perhaps we can discuss if there's a layout style that can work well with most of the four skins. —WhosAsking (talk) 08:01, 14 May 2014 (UTC)


 * (putting this here so you get a notification): I edit with Monobook because 1) it will exist if Dolphin is ever replaced (Dolphin is the second, custom default skin we have used), 2) monobook is high-rez/wide-screen friendly, 3) I test my edits to make sure layouts are scalable, so low rez/phones can view them decently. What page would you like to analyze together? -- 16:47, 14 May 2014 (UTC)

Crazy Taxi Talk Page
Thanks, I didn't realize I had put in the Controls discussion. I actually went to the main game discussion page and wondered where it went! =) I went ahead and moved it to main game page. The old talk page is here if you'd like to delete it. TurboButtons (talk) 04:55, 20 May 2014 (UTC)

Purchasing Chrono Trigger
Hey NMH, didn't realize CT for Android was a thing. Would you like us to purchase it for you? We can either try to do that or just reimburse you for it. Let me know.  Pro cyon  04:10, 21 May 2014 (UTC)
 * @: I would really appreciate that! My goal at the moment is to get the Ocarina of Time images renamed and the Volgarr the Viking guide fleshed out (and I want to 100% the game). After that, or at the same time, I would be down to play CT on my tablet. Is there a gifting method through play store/gmail accounts? Or would you prefer to paypal me the $9.99? Btw, would you prefer to discuss this via email or Facebook? -- 05:24, 21 May 2014 (UTC)
 * Either email or FB is fine with me. Paypal probably makes the most sense.  And plus, as of last Monday, I work for them so I should probably encourage its use ;)  Pro  cyon  23:06, 21 May 2014 (UTC)

Dolphin skin
BTW, I left a comment on WhosAsking's page about the large Crystalis maps. I realize you and Paco prefer the older skins, but since the majority of our traffic views the site with the default dolphin skin, we should prioritize how the guides look in Dolphin. Ideally, we should make them look good in all skins whenever possible, but when we're forced to choose between one over the other, we should give preferential treatment to the default skin.  Pro cyon  23:06, 21 May 2014 (UTC)


 * @: congrats on the new job! Just for you, I've switched over to Dolphin. Ugh, I feel like this artificial constraint is really bad for game info. We want high-rez everything! Two ideas I have, which I won't get support for, would be to make Monobook the default skin, but make the main page a hardcoded page themed like Dolphin, so if anyone comes here they're like oh it's pretty, but when they go to a content page where space matters, there's nothing getting in their way. The other would be to revise dolphin so we aren't constrained to 60% of the screen. On my screens I have like 4 inches of total width in blue space (~700 pixels) wasted. I really dislike how we now have to go back through every guide we've ever created and optimize it to fit an artificially worse standard. -- 23:27, 21 May 2014 (UTC)


 * @: also, since there are no horizontal rules included under H2s, can we manually add them? Or is that CSS we can modify in Dolphin? I hate how Dolphin even changes the appearance of the content. -- 00:02, 22 May 2014 (UTC)


 * Hey NMH, I really appreciate your honesty about the skin. I actually share some of your concerns about the visible space, but there were a lot of technical and practical reasons for the choices that were made.  We went around and around about it, and I think you had an opportunity to weigh in on the beta site.  In the end, the pros (technical benefits, mobile compatibility) really outweighed the cons (guide width) and we pulled the trigger.  I'm not sure what you mean about horizontal rules, could you please clarify?  It is unfortunate that we have to verify multiple skins, but the alternative was to remove the ability to change them.  We can call a meeting about it (man, we haven't had one of those in a long time) if you feel strongly about it.   Pro  cyon  02:54, 22 May 2014 (UTC)


 * @: "Horizontal rule" is the full name for the HTML  tag. It appears that the dolphin CSS no longer shows a HR underneath the div accompanying H2 tags (or, in wikimarkup, ==This type of header== ). I think we should definitely re-implement it as the horizontal rule really offsets the section beneath it by drawing a visible line. Without it, it makes pages look like they go on forever in one continuous stream. The HR tag breaks up the whitespace very precisely. Also, the reason we do not use HR tags on pages is because the level 1 headers had that built in HR line, so we just told people to reserve the full-width black lines for level 1 headers and to not go crazy with drawing tons of lines across pages. -- 06:12, 22 May 2014 (UTC)


 * @: here's an issue. Take a look at Crystalis/Leaf. Some of the maps are full width. This looks great! However, on a mobile device, the width of the screen will force them to zoom in and out to see it, or click on the image. Is this an issue to you? If not, then great, we can make full-width images a commonly used visual. -- 23:45, 22 May 2014 (UTC)


 * @, : I went in and inspected the HTML/CSS for H2's on both Dolphin and Monobook. Monobook's H2 has this property that Dolphin's does not: "border-bottom: 1px solid #aaa;". Can we please add that to Dolphin? It really changes how pages look by visually separating them into blocks of grouped content. I often scan by looking at the lines themselves, not any of the words on the page. -- 00:29, 24 May 2014 (UTC)


 * @, : I made a change to MediaWiki:Dolphin.css so you can see the difference on pages now. Let me know if you approve. -- 23:40, 24 May 2014 (UTC)

Aigina no Yogen
Hey NMH, sorry to do this to you, but I already wrote a guide for Aigina no Yogen. Just didn't link it properly to the name of the game in the NES completion list. I apologize for that.  Pro cyon  01:41, 2 June 2014 (UTC)

P.S. We had to sort out a problem with Google Wallet, but we're through it now, so I should be able to reimburse you shortly.