Template talk:Gecko

From Dolphin Emulator Wiki
Jump to: navigation, search

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)

One other class we probably should allow for, LOD codes. Apparently folks have been working out disabling reduction of Level of Detail via codes. Kolano (talk) 04:17, 15 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)
It screws up the documentation on the page though by consuming the includeonly tags, leaving that empty code box at the top of the page. I don't see how a workaround template here would compete with the gecko template, we already have a few smaller templates for stuff like this like Template:Hover, so there's precedent. - Xerxes (talk) 09:31, 8 January 2018 (CET)
Luckily the Gecko template has shown no more than just a weird bar when out of includeonly tags, I don't think it'd be very distracting. When I said Pre template would compete Gecko template I meant that users might use Pre templates for their Geck codes. Lucario (talk) 21:41, 8 January 2018 (CET)

Widescreen

Not all 16:9 codes want the Widescreen hack disabled, some require it. Kolano (talk) 22:53, 7 January 2018 (CET)

Which game? It looks like there are variety cheat description for 16:9 code than I though. Lucario (talk) 23:40, 7 January 2018 (CET)
Lemony Snicket's A Series of Unfortunate Events is one game that needs the widescreen hack. I'm sure I've seen it on other more high profile games too, but I can't think of them off the top of my head. Maybe add a |widescreenhack=true or false into the template for 16:9, then have a sentence like "Make sure the widescreen hack is disabled / enabled" depending on what it's set to? - Xerxes (talk) 09:14, 8 January 2018 (CET)
Thanks, but I'm not comfortable with having another parameter to determine between disabled/enabled requirement for the widescreen code. The sentencing is awkward, I think using an unspecified cheat description is better suited for the code that requires widescreen hack, it may trigger a "not 16:9" category, but that seems okay to me as it's an incomplete code that doesn't do 16:9 yet. Lucario (talk) 21:35, 8 January 2018 (CET)
I get what you're saying about how the code doesn't technically change the aspect ratio itself, but that's a pretty minor distinction. The point of even having 16:9 codes here as I understand it was because of problems with the widescreen hack, so whether the code itself does the widescreen or it fixes the widescreen hack, it's accomplishing the same goal. It's probably more confusing to have a 16:9 template that doesn't take all the 16:9 codes available. If there's widescreen codes that are just using the default display option of the template and not the nice formatting we've come up with, then why should the template even exist? That's kind of where I'm at with this. (Metroid Prime (GC) is another game that has a 16:9 code that uses the widescreen hack, as a side note.) - Xerxes (talk) 00:01, 9 January 2018 (CET)
An unspecified cheat description still does appears to be suited well for those 16:9 codes on Metroid Prime game. How else are we supposed to make sentence that would make sense across games that need widescreen hack? They have lot variety of 16:9 fix statements, rewriting is going to be hard. I guess we need to edit doc page to explain how automatic cheat description works, tells what "16:9" will do, and when to use it based on whether does the code even do 16:9 (in replacement of widescreen hack), not just 16:9 fixes, and the category will go away only if we have real 16:9 treatment for those that need widescreen hack. We could rename that category into "bugfix" if the "not 16:9" is bit misleading to you. Lucario (talk) 01:24, 9 January 2018 (CET)
Maybe we should not try and describe the widescreen codes in a standardized way at all? Just let code submitters fill out whatever they want? - Xerxes (talk) 00:51, 9 January 2018 (CET)
Yes, that's what an unspecified cheat description parameter is for, and as a bonus they can add additional information after "16:9" and they will appear after/under automatic cheat description Lucario (talk) 01:24, 9 January 2018 (CET)
Yeah you're right, it would be fine that way. For some reason I was thinking you wanted to go back to the really basic version of the template that basically is just a pre box for single codes. What do you think about the change I just made, where it ditches the automatic description for 16:9 codes? Or do you think we should still try to have one? - Xerxes (talk) 02:06, 9 January 2018 (CET)
Uhh, we need automatic description for 16:9, like before you removed it, there are many cheat codes with similar description so the 16:9 automatic cheat description would've cover them. I've just realized Metroid Prime game has one proper cheat code that does 16:9 so that's what had caused confusion between us...? Lucario (talk) 07:01, 9 January 2018 (CET)
Yeah, a default description should be provided. If there is a mechanism to allow overwriting it everything should be fine. Kolano (talk) 09:36, 9 January 2018 (CET)
I was a little confused so I'm sorry for getting into this long conversation about basically nothing. My concern was classification of what are effectively widescreen codes into the non-widescreen part of the template, but maybe Lucario's just right and we should prioritize codes that don't rely on the widescreen hack anyways. I think it's fine to do it Lucario's original way where codes using the hack just go into the generic category. don't hate me - Xerxes (talk) 10:11, 9 January 2018 (CET)
This discussion had us think of other things that need to be done, so this doesn't accomplish nothing. This reminds me to update doc about how does the automatic cheat description works, and when to use it, etc.. You're welcome to improve list of existing cheat description, maybe add another one, I just don't feel like hijacking one of them for other code types, please add new cheat description and find new regex match to use. Please also remember to make mention "Gecko" as I noticed your cheat description at Dummy Page made no mention of it, the readers needs to know which the code is for. Don't worry about "Action Replay", it's an Template:Action Replay's job to find and replace all instances of "Gecko" to "Action Replay". Lucario (talk) 11:39, 9 January 2018 (CET)

So, it's settled that the 16:9 + widescreen hack will be going to use generic cheat description? Lucario (talk) 11:39, 9 January 2018 (CET)

Mixed Code Types

One issue with this handling is that some titles hay have mixed sets of codes across regions (i.e. Gecko for NA, Action Replay for EU). It would probably be better to have a generic template. Due general formatting differences it might also be possible to automatically identify the types of codes. Kolano (talk) 08:35, 4 March 2018 (CET)