Template talk:Infobox VG/sandbox

ID Verify

Chiming in on the recent ID Verify update. I'm not clear it's a particularly good solution, as it seems to depend on the verifier being a reliable source, which likely isn't a safe presumption over the thousands of IDs to verify. Something like a method to provide an outside URL confirming each ID would probably be preferable. I'm not clear about the mechanics, but perhaps we could also work out pulling in things like the language details that have been populated on redirect pages.

If not possible through standard wiki mechanics, I'm guessing some JavaScript as I'm hoping to implement to restore random videos might be able to handle it. Kolano (talk) 08:08, 29 December 2017 (CET)

After taking another look at it, I don't think I liked my old design either, it seemed tacky. This new version tries to consolidate everything to the GameIDs section instead of adding a new section. All that it does is look for a variable in the page's infobox that matches the name of each ID, and if there's a match then it links to wherever that variable says to instead of to the redirect page like it normally does; if there's no match for one or more IDs, then it adds the page to the unverified IDs category. For example, on page Atlantis no Nazo, if I were to confirm that page's ID FEAJ01, all I would have to do is add the line |FEAJ01 = <NUS link> and the link in the infobox under the GameIDs section would take you to the NUS. (Ironically a bad example since FEAJ doesn't have a download from NUS...) There's a demonstration on the Dummy Page so you can see what I mean.

The ultimate goal would be to have a system with some kind of small checkmark icon next to verified IDs and an X next to unverified IDs in the infobox and make the checkmark what links instead of the ID itself, but I'd need to go find some public domain icons and figure out how to do that visually. - Xerxes (talk) 10:27, 29 December 2017 (CET)

I wanted to try and do the information on the ID redirect page as a hover over for IDs in the infobox, but I don't know how to do that. Trying to transclude a redirect just gives you the contents of the page it redirects to. That's how redirects work for template names so it's core to MediaWiki that it does this. - Xerxes (talk) 09:44, 2 January 2018 (CET)

I've been thinking about this more lately. This is not a good solution because when the Wii Shop goes down theoretically these links may all break. So we'd have to archive the links first, and then you can't even confirm the ID without opening the tmd with a hex editor, and none of the tmds have names, and there's no good way to handle partial IDs like links to box covers..... I really really really hate confirming IDs. As far as I'm concerned all our IDs are junk; we can only confirm the first four characters for physical releases, and the digital ones might as well be made up (and in many cases were). My life would be one billion times easier if Dolphin just used a four character standard instead of a six character, then at least we'd know all the disc titles are right. But alas. - Xerxes (talk) 01:51, 18 January 2018 (CET)

How to retrieve parameter information from Template:Config to Template:Infobox VG?

My goal is to output "(480p no AA)" after rating text if it detects these existing parameter(s): antialiasing, anisotropic filtering, and/or internal resolution in the configuration template. Can this be done at all? I'm not sure if #var_final is working or I'm doing it wrong.

Okay, my actual goal is to drop pixelated stars while retaining these parentheses. Lucario (talk) 10:46, 6 July 2017 (CEST)

Is it still good idea to have these parentheses after rating text though? The question above won't matter anymore if the parentheses are not going to make it out of the sandbox anyway. Lucario (talk) 11:06, 6 July 2017 (CEST)

You can detect the existence of a config entry by using #ifpageincat on the categories in Category:Config Required. That doesn't get you any of the actual information entered within, just whether or not that parameter is set to something or not. That was how I was able to get platform information from the page categories to automate that part of the infobox. Though, the standard right now as I understand it is to not use any config entries for problems with enhancements, since config is reserved for issues with default settings. - Xerxes (talk) 10:02, 2 January 2018 (CET)

We've also allowed for enhancement related settings when such result in known issues. such as filtering options scrambling video; though it's not handled consistently. Kolano (talk) 10:19, 2 January 2018 (CET)

Oh, great, thanks! But how can I use that method for blue stars since there'd be too many different categories? Feeling hopeless for 480p no AA stars. I wish that "default vs non-default" rule doesn't apply to the built-in enhancement settings. Lucario (talk) 03:57, 3 January 2018 (CET)

You can do {{#ifpageincat:antialiasing|{{#vardefine:bluestars|true}}}} and duplicate it a few times for each category. Then do an {{#if:{{#var:bluestars}}|blue stars|regular stars}} later on to access it and wrap that around the styling for the stars in the infobox. I haven't looked too closely at the rating stars but that's the basic skeleton I would use. You can even stack the #ifpageincats inside of each other like the platforms section does, but that can hurt readability; only did it there because there were so many that doing all those checks every single page seemed stupid. - Xerxes (talk) 04:54, 3 January 2018 (CET)

Those anti-aliasing and other enhancements don't really belong to blue stars. The blue stars are meant to give allowance to games with less stars back to 5-star or at least something better when the non-default settings are taken into account. Oh well, there are lot of categories to fetch from Config template, idk if that's a little bit too much.

Oh, I just forgot, your method will not gonna work on the stars in the compatibility list. The 480p no AA stars are still in luck, though, since they'll only seen in parentheses appended after rating texts, and they are only be seen in game pages anyway. Lucario (talk) 06:24, 3 January 2018 (CET)

Um, what is the point of this additional parenthetical? I'm guessing that there's a lot of details here that either aren't or can't be accounted for. For instance...

• 480p is only the resolution for many NTSC titles. There are a lot of GameCube / Wii rendering modes, and many are not using 480p. It's been a while since I took a closer look, but the most common case is likely PAL titles (i.e. PAL is 576p).
• We long established that "enhancement" settings should have no impact on ratings.
• Negative outcomes from AA, Anti-aliasing, Texture Filtering, Higher IR vary wildly. Some so minor they wouldn't effect a rating, others completely game breaking.

This probably needs some discussion before you spend a lot of time on it. I already dislike the "Perfect (configured)" as if it needs to be configured it's not perfect. Kolano (talk) 05:24, 3 January 2018 (CET)

He asked a question about how to do something, so I answered him. I wasn't exactly keen to get into the enhancements conversation again either. I'm a freak who plays all his games at native res on an HD monitor, so my opinion on the matter is pretty much null. - Xerxes (talk) 05:52, 3 January 2018 (CET)

And yeah, I got too tired of ignored bug reports due to use of enhancement options, and now try to stick with defaults. Looking forward to a day when things work well enough for enhancement related issues to be considered to have merit, it's one of my favorite things that Dolphin offers. Hope I'm still interested in Dolphin by then. Kolano (talk) 08:24, 3 January 2018 (CET)

My idea of using blue stars stemmed after reading from people (JMC I'm sure, I might need to find that discussion again) wanting to give better rating to the games even though they have minimal problems which caused their stars to immediately drop from 5 to something less. The blue stars can also conveniently used to notify users that options that would improve emulation are available, kind of like tl;dr version for infobox and right from compatibility list. This goes half the same for "480p no AA" stars, they're there precisely to notify the users that HD configs are bad for that game. Okay, it's probably silly to have, but the blue stars on the other hand, I think it's nice to have. Lucario (talk) 06:24, 3 January 2018 (CET)

Warning about particular settings like AA is probably feasible and not too hard to do. But the ratings system already is pretty vague. Having a game rated five stars which has configuration fixable problems and then patching in a note about it into the infobox or the rating star template seems too hard to upkeep to me, and not really easily automated at all. Especially when both are used in conjunction; there's some settings like Ubershaders which could be considered an enhancement and may have its own problems, while in other cases Ubershaders solve massive terrible stuttering and improve the rating of a title. There's a similar problem with Immediate XFB as well, which I've been mulling over recently. - Xerxes (talk) 07:58, 3 January 2018 (CET)

I also think trying to muck with ratings will be asking for trouble. Personally I would like to see some better tracking here of enhancements and titles that have issues with them. We'd need to tread cautiously though, as such will liking increase reporting of enhancement related issues, which, per my current understanding, the devs are uninterested in seeing. It might also be a good idea to break that out somewhere separate from the infobox, as I'm unclear folks will be too supportive of wedging too much more into them. Perhaps a separate template to use in an/the "Enhancements" section per page? Breaking out the Stereoscoping review / rating with that might also be for the best. Kolano (talk) 08:24, 3 January 2018 (CET)

Now, if you wanted to be really insane, you could enforce standardized settings entries for the config template, and then make the template generate a category for each possible setting, and then grab those. Then you could actually access the data of the config template from anywhere on the page. But I don't think anyone wants to deal with that. - Xerxes (talk) 08:14, 3 January 2018 (CET)

Knowing that some setting needed to be configured was the primary concern. When they are binary choices it's usually easy to tell what state "configured" means, but obviously we don't just have binary options. Some basic standardization has occurred (i.e. use On/Off rather than other binary possibilities), but I didn't think anyone wanted to take the time to actually review / standardize entries to be able to provide more specific details. Keeping things generic has also meant it's been somewhat easier to handle config panel revisions.

There might be an argument for solidifying the config template more now that Ubershaders and Hybrid XFB were merged. But my idea was just stupid really. I mean we're talking 40ish different settings in there, most with binary choices, with some impossible to standardize anyways like the patches section. That's got to be at least... 80? new categories generated trying to do that. And that's after all the entries are adjusted to fit the standard. And this isn't even the right template talk for the discussion besides. - Xerxes (talk) 08:53, 3 January 2018 (CET)