Template talk:Gecko

Accreditation

One other thing this template may need to account for would be accreditation. In general we try to avoid such, but a few folks have thrown major fits over their codes being credited to them. Kolano (talk) 10:09, 3 January 2018 (CET)

We could just follow GeckoCodes.org's naming scheme, they have hacker's name as part of name of the code, for example, "60 FPS [Lucario]". I'd rather not to implement some kind of credit system to this template. Lucario (talk) 00:09, 4 January 2018 (CET)

I agree with Lucario, the current way of handling it like with Ralf's codes seems fine to me. If someone copy/pastes the code like they're encouraged to do, they copy over the creator's name too. Just because of that it's probably already the best way possible to credit the code creator. - Xerxes (talk) 08:19, 4 January 2018 (CET)

Allowed Categories

There may be one other allowed classification. A small subset of codes may be used to work-around bugs or emulation issues beside problems with the widescreen, though I'm not clear if any of these sorts of codes still exists (i.e. fewer are needed with our more accurate emulation). In any case a "bugfix" category may be appropriate. Kolano (talk) 21:16, 31 December 2017 (CET)

It's going to be difficult to correctly flag cheat code as bugfix because there's arbitrary way how it's called, and anyone can flag it as bugfix with their malicious edits. Just say it's not 16:9 or 60FPS will allow us to patrol those codes.

Actually, if you mean that we can rename "Not 16:9 or 60FPS" category into "bugfix" and they work the same way, I'm up for it. Lucario (talk) 21:59, 31 December 2017 (CET)

The only pages I know of that use patches to fix bugs right now are Mario Kart Arcade GP and Mario Kart Arcade GP 2. There's handling for it in Template:Config as well, but I don't think that's ever been used. - Xerxes (talk) 04:26, 1 January 2018 (CET)

Yeah, I think it may just be the patches to bust out arcade mode from Fzero that remain, but I'm not sure. I believe in the past there were a few other cases where bugs were worked around. I understand the fear of arbitrary codes being labeled as such, but I'd like to allow the use of this template in the few alternate cases that we have. I think alternate case are handled, but get flagged with a category now. So I guess we can account for things as they crop up. Kolano (talk) 12:39, 1 January 2018 (CET)

Regions

Though the vast majority of titles can be classified with NA/JP/EU, there are other regions and sub-divisions (i.e. EU language releases, special editions, etc.). May want to handle it more generically allowing GameIDs to be fed in as identifiers (more generic region identifier names could likely be determined through the 5th character). Kolano (talk) 21:32, 31 December 2017 (CET)

I agree that users who submit new codes should be forced to specify what ID those codes are for. I think this is a healthy change. And yes, they don't always split into nice regions. There's always weird exceptions, even a high profile game like Super Mario Galaxy 2 had a Chinese language release for example. I would be in favor of this to the point of even including duplicates of the same codes on a page just to show that the codes work with each GameID for a title. The only problem with enforcing this would be that there would be some ambiguity with what ID existing codes are for, but that's not a problem with the Gecko template, that ambiguity has always existed. - Xerxes (talk) 04:22, 1 January 2018 (CET)

Actually ID isn't foolproof either. Super Smash Bros. Melee has different revisions that share IDs and need different codes... so IDs aren't a perfect solution. - Xerxes (talk) 05:39, 1 January 2018 (CET)

OK, so beyond accounting for region differences, we'll also nee to allow for exceptions. That's annoying, but likely has limited occurrences. Good to account for that now, rather than after this has been implemented. Kolano (talk) 12:27, 1 January 2018 (CET)

One thing I'm unclear of would be unnecessary classification, I'd guess in some cases memory addresses are handled similarly across regions and codes work the same way across them. The current design can handle that with duplication, but we might want to alternately handle it to avoid separate edits. Kolano (talk) 12:44, 1 January 2018 (CET)

Look's like Xerces was able to convert the set region inputs to be handled more generically, allowing for arbitrary inputs. Is that a satisfactory solution here, or does this need more discussion / review? Kolano (talk) 10:12, 3 January 2018 (CET)

Well if there's no good standard identifier that will work in all cases then it seemed like it should just take anything. From that you could still add back in checks using regex later if you wanted. Though right now it has no limit on how many codes it can take and they're ordered horizontally, so the codes may look squished if there's more than 3 or 4. - Xerxes (talk) 10:32, 3 January 2018 (CET)

Well, I'm not used to GameID as header of the code table. Maybe I'm just too used to the likes of "NTSC" and "PAL". I think those disc revision could be merged into NTSC column as part of title of the code. Lucario (talk) 00:09, 4 January 2018 (CET)

OK, how about the Korean releases then? Should we presume the can merge under NTSC-J? Pokémon Snap is probably a good example. It has 7 different releases /w 3 PAL ones and requires a 16:9 Aspect Ratio Fix. There is currently only one code for the NAKE01 GameID.

Something else positive that can likely come out of using the GameIDs would be the ability to tell when additional investigation / codes are needed (i.e. there are 6 missing codes for Pokémon Snap). Kolano (talk) 02:10, 4 January 2018 (CET)

We'll also need to have some standard method of handling generic codes, applicable across multiple regions. Unclear if we can get away with a single "generic" indicator, or would need to allow for this code for GameID 1/2 and another for GameID 3/4/5. Kolano (talk) 02:13, 4 January 2018 (CET)

We can add check that when there's nothing in 3rd parameter, it'll ignore heading codes, so there'd be code table without heading. Lucario (talk) 03:54, 4 January 2018 (CET)

There are four regions in Nintendo's regional lockout ([1]), it goes by NTSC-K, NTSC-J, NTSC-U, and lastly PAL, we can have four columns and that seems very reasonable amount. We'll need to work out how to assign multiple GameID's region code to a region column though, like NAKF01, NAKP01, etc into PAL column. I think column layout should be for region only as it's felt natural and easier to notice than looking at region code inside GameID. Lucario (talk) 03:54, 4 January 2018 (CET)

Yeah, unfortunately the "X" and "Y" releases complicate that as they may occur in arbitrary regions, so I don't think there will be any way to automate it. Kolano (talk) 04:33, 4 January 2018 (CET)

I guess we gotta have fifth column for those? It could be the "Special releases" along with NTSC and PAL, but is it okay that they don't fall under actually appropriate region, only there? Lucario (talk) 05:16, 4 January 2018 (CET)

I guess that adds a 4th column you hadn't planned for, but should likely be OK. Kolano (talk) 07:52, 4 January 2018 (CET)

Maybe do the four lockout regions with your tab layout design, and once you click into the tabs then all the codes for that regional lockout are shown? I don't really like having the ID pasted in with the code because the code box styling lends itself to copy/paste, and there's not a reason to copy/paste over the name of the game in that format.

Let's not get too carried away here either, it's about a) making it as easy as possible for site visitors to figure out what codes will work for their games, and b) making it as easy as possible for editors to add new codes. I thought a) and b) could be solved at once with IDs because IDs are easy to find from within Dolphin itself, follow general patterns, we can do some funky stuff with DPLs with how our IDs work and access them anywhere, there seemed to be a lot of fun potential there (like comparing the IDs of the codes with the ID redirects we have on the wiki, and detecting mismatches). But Melee kinda stomped on that. I still think IDs are probably both the most practical and the least vague identifier of all. If you want to get kind of mean you could just say screw it and make code submitters calculate their md5 and copy paste it in with their code, then there would be zero ambiguity. But that seems kind of rude/distrusting and not very visually appealing. - Xerxes (talk) 12:37, 4 January 2018 (CET)

Taking a closer look, you kind of had the same idea I had actually with messing with the ID. But I guess it just isn't practical to try and take the IDs and region sort them in that way. I keep going back to the W region IDs, but again Taiwan follows the NTSC standard, and Hong Kong/Macau follow the PAL standard, and yet there were releases to both sharing IDs (SB4W01). Did one disc have one lockout and the other have another? Or do they share an NTSC-J lockout or what? Wikipedia generically says NTSC-J for both but it's not cited. In any case, there's still a lot of unknowns currently with the regions, we haven't even figured out what to do with JALT01 yet, on top of the discrepancies we know for a fact exist, like the X/Y/U inconsistencies. So you're going to run into more than just template design problems here with this approach. - Xerxes (talk) 13:05, 4 January 2018 (CET)

Wow, Xerxes, you got it! That two or more GameIDs under same region column. It's working just what I've wanted! Lucario (talk) 09:48, 5 January 2018 (CET)

I noticed your comment about that Infobox needs to be changed to accommodate for Japanese and European titles, I've seen Wikipedia using dedicated template (https://en.wikipedia.org/wiki/Template:Nihongo also SmashWiki's https://www.ssbwiki.com/Template:Ja) for game's Japanese title, I thought we could borrow its template and bundle the vardefine system into there and it'll get the job done. But I'm not sure what else to handle European titles though. Lucario (talk) 09:56, 5 January 2018 (CET)

We probably should be using something like that, I tried to add a bunch of Japanese kanji game titles to the descriptions while going through last summer but our handling of anything JP is a bit lacking at the moment. (SmashWiki uses it to fix rendering of the characters, are our JP characters rendering properly without that on all platforms? Does anyone even know?) My idea was a new "alternate titles" entry in the infobox with the European and Japanese titles. That might be kind of labor intensive to actually do for all pages though. - Xerxes (talk) 10:18, 5 January 2018 (CET)

SmashWiki's JP template apparently put romaji inside the tooltip when you mouse over the Japanese text you will see its romaji. Kinda nice but not great for mobile users. But my point is apparently Wiki sites did use some sort of template for game's Japanese titles. I'd like a slightly different approach where we can handle European titles as well. Infobox VG might be a place for them, but I wouldn't feel great about it since Japanese texts are already around in beginning of article. I also noticed somewhere on this site there are something along with game title "known in European as game European_title, ...", we can take advantage of that: a new template that handle all game's title and its alternative titles in sentence or parentheses, starting with Japanese texts in parentheses "(フォックス, Fokkusu)" then European title "known in Europe as Fuchs", they will have vardefines for both European_title and Japanese_title ready. Lucario (talk) 10:37, 5 January 2018 (CET)

That's a good idea but how do you want to handle displaying all the titles when there's a lot of them? It's not always going to be the nice 3 if you really want to capture native languages for all the release regions. You'd have to capture stuff like our Netherlands titles, and the Chinese releases, and the German/French/Italian... Sometimes the name's just a proper noun and shared, so it doesn't really matter whether you have it written in each language or not, but not always. - Xerxes (talk) 11:26, 5 January 2018 (CET)

If we wanted to go down the road of trying to flesh out the different region information for specific titles, we could be totally crazy and try User:Kolano's idea on his TODO to provide region specific covers, titles, etc. for each ID redirect. That's an entirely different discussion though, but it would be relevant if we're trying to think of long term approaches to capturing appropriate alternate titles. - Xerxes (talk) 10:58, 5 January 2018 (CET)

Quality Categories

If you want to turn gecko codes into a template (not a bad idea), it might be good if you're going to try and integrate quality checks to hook it into Template:Problems/GC Widescreen Auto and Template:Problems/GC Widescreen 16-9. If the game supports 16:9 already but also has widescreen codes for whatever reason, then the template should generate flags to show that the widescreen gecko codes aren't needed. That would give the template tangible benefits rather than just style compared to the current way of doing it. I don't know how to handle that with Wii though, but I don't really know how widespread the creation/desire for widescreen Wii codes is when most games already support it (I think?). - Xerxes (talk) 04:17, 30 December 2017 (CET)

Good idea, if this new template is going to make it to game pages then we can add additional qualility checks regarding games that already support widescreen. We may like another category for whether it's used in Wii game pages. Lucario (talk) 03:29, 31 December 2017 (CET)

Pagename Use

Sorry to jump on this so quickly, but we won't want to use the pagename template in this content. It will be likely to only align with the titles name in the NA region (or one other in our priority cascade). If we include titles the appropriate titles should be used. Kolano (talk) 02:35, 4 January 2018 (CET)

I understand it's terrible method when it comes to alternative titles the game has, still working on it... It's there so the GameID look good. It's inspired from GeckoCode.org Lucario (talk) 03:54, 4 January 2018 (CET)

Template:Pre

Maybe we should make our own really basic copy of the Pre template? It seems like it would be nicer to work/more readable than the weird includeonlys inside pres randomly on the page, and the ability to have markup in pre tags could come up again. I don't see a reason why not. (Did a minor edit on accident, oops....) - Xerxes (talk) 14:08, 6 January 2018 (CET)

Gecko template really need a way to display output in pre tags. I can't think of any other use-cases that need this, but preferably not, I can see this becoming rival against Gecko template. Lucario (talk) 01:15, 7 January 2018 (CET)