User talk:Lucario

Currenttimestamp?
As far as I can see, the CURRENTTIMESTAMP template (i.e. ) doesn't update per page refresh, it seems to stay stuck at the point when the last edit occurred or the cache page was generated. So I'm not sure it can be used to generate the random value. I think we had determined that some JavaScript is needed to either handle the random selection, or minimally generate an actual random value here. BTW, a parameterless version of things would be nicer, even if it can't handle the random selection. Kolano (talk) 08:42, 27 January 2018 (CET)


 * You're right, it didn't update on page load. I was hoping that it was just cache of another template rather than on page directly, but nope it's still not updated, as confirmed in next section below. We'll look into Javascript I guess. I've wondered how will Javascript look and how will it pick three lucky videos and list the rest. I'm no Javascript expert so I won't be able to tell how hard it'd be. Lucario (talk) 09:00, 27 January 2018 (CET)


 * You can't cheat the cache. You have to use MediaWiki:Common.js. That's the only way. If you put logic in there to generate a random seed, that should be enough. - Xerxes (talk) 09:15, 27 January 2018 (CET)
 * Thanks for letting me know, it kinda suck we've had to wait for the cache to purge out for the time to update. Lucario (talk) 14:18, 27 January 2018 (CET)


 * I agree! Parameterless seems better. With it the uploader can just select all > copy'n'paste the url then append with caption. It'll have same feel as you'd copy full url then append with caption in brackets. There was one editor who deliberately assign +1 to all vid/cap parameters then use the first parameter for his video. It made me want to curl! Lucario (talk) 09:12, 27 January 2018 (CET)


 * Yes, they also frequently will perform arbitrary edits (i.e. adding/removing spacing) until their video comes to the top. This is the exact reason we want to restore true randomness. Kolano (talk) 09:32, 27 January 2018 (CET)


 * Generating a random ID in common.js is easy enough. However, I'm not clear there is any way for that to hand off to wiki handling, so I think any randomization related logic here is likely pointless. Since I'm not clear there is any good way to perform a hand-off, I think we need to perform the random selection and HTML generation in JavaScript, which makes things more complicated (though not particularly difficult). Kolano (talk) 09:37, 27 January 2018 (CET)
 * I don't think I'll be around to do that stuff. Anyone else can try. Lucario (talk) 14:18, 27 January 2018 (CET)

Time refresh on page load test

 * current time:
 * current time in template:
 * expecting empty #var:trololo:
 * expecting empty #var:trololo default:
 * expecting defined #var:trololo:

Which one updates faster?

SNES Ratings
Did you actually test the SNES titles, a number of the pre-existing ratings indicated problems so I'm not clear it's safe to assume them to all be 5 stars. Kolano (talk) 03:15, 30 March 2017 (CEST)
 * I haven't tested any SNES title for a problem, but yeah I realized it's starting to overlap with 0 stars "unknown" in term of untested. I'll probably go through them again and rate them 0 when there isn't a testing entry (slashed for laziness but it's good indication of whether game is actually tested or not...). Lucario (talk) 03:55, 30 March 2017 (CEST)

Infobox Edits
Your edits seem to have broken the Infobox VG template. I'm likely to revert them back shortly.

I don't think the edits you've been making on the Infobox template will be well supported anyway. We currently only list "Platform" on VC titles, so we would never generate a "Category:Wii titles that use Classic Controller" as there should be no pages that list "Wii" as a platform. In the case of the VC titles, the supported controlled are almost never different, so these categories would just become duplicates of the pre-existing VC categories. In general, if we want something like this, I'd think it might be better to look into adding an "intersection" extension to the wiki, which would allow for auto-generating sub-categories based on the inclusion of other categories. Kolano (talk) 18:54, 20 September 2015 (CEST)

Please talk to us before doing big structural changes to the way our templates work... Even I won't change things like that without talking to everyone to make sure they are fine with it! Big changes that effect everything need to be agreed upon. Btw, if the idea is to allow for cross referencing of controllers, a plugin would be great for that! - MayImilae (talk) 19:56, 20 September 2015 (CEST)


 * My original intention was to create a list that show all Wii games with controller specific support. For example, "Wii titles that use GameCube Controller". I think it's nice addition to this Dolphin wiki. In earlier edit in sandbox I've added them instead of replacing the existing controller set. It should work out of the box (sort of, it depends on |platforms=, unfortunately). Then I ultimately replaced them as I think it's bit odd to see like this:


 * Category:Classic Controller (Input supported)
 * Category:Wii titles that use Classic Controller
 * Category:GameCube Controller (Input supported)
 * Category:Wii titles that use GameCube Controller
 * Category:Nunchuk (Input supported)
 * Category:Wii titles that use Nunchuk
 * Category:Wii Remote (Input supported)
 * Category:Wii titles that use Wii Remote


 * While I know "GameCube titles that use GameCube Controller" is very silly and redundant, but that can be kept separated from other platforms, and as an replacement for "GameCube Controller (Input supported). Such as, the link Category:GameCube Controller (Input supported) in GameCube game pages. It's sheer obvious that every GameCube titles will use GameCube controllers. They're basically a duplication of the list of GameCube games, with other platforms only to add clutter to it. Indeed, the current controller categories are a mess at the moment. If one user want to view Wii titles that use GameCube Controller, they will have to read through list of irrelevant platforms. Some titles don't use GameCube Controller, while others do, so it's realistic to see platform x controller categories to exist.


 * I've created "|system=" because due to my limited coding abilities, I can't parse each system into "[SYSTEM] that use [CONTROLLER]", such as if there was Nintendo 64 and Virtual Console in the infobox.


 * But since you've deleted the categories that Infobox VG (with my edits) was going to take advantage of, my edits are complete pointless.


 * Any part of my edits that you'd like to detract other than the need to update every game pages to take advantage of my changes? I'm thinking of just add specific Wii game pages that support GameCube controller to subcategory Category:Wii titles that use GameCube Controller. Is that cool with you? Lucario (talk) 00:31, 21 September 2015 (CEST)


 * OK, to be specific regarding my concerns:
 * The edits would require editing every titles page, with thousands of pages that would take a while, even if we put the regex search-n-replace to use.
 * Preexisting pages that included a "platforms=" were completely broken, spitting out a broken and escaped set of categories. This may have been addressed by replacing "platforms=" with "platforms="+"system=", but I was unhappy to have all the pages broken till that was completed, which per above would take a while.
 * It should be fairly easy to use the Regex template to do things like purge out the comma and "Virtual Console" from the platforms list if that was the only reason to add a separate "systems=" parameter.
 * This sort of "pages that are part of multiple categories" category is provided more cleanly and easily via a few different Mediawiki add-ins, which is probably a preferable way to pursue this.


 * I'm not against setting up these sorts of categories, I just don't want to cause chaos while they are set up. Some other responses/comments:
 * If we are going to have these sorts of categories we should have a "GameCube titles that use GameCube Controllers" category. Yes, it seems like all games should support the consoles own controller, but I'd prefer there to be consistency in how things were handled.
 * For similar reasons, I'd prefer to not just arbitrarily add only a "Wii titles that use GameCube Controller" category.
 * I wouldn't mind getting Wii/GameCube listed as platforms and auto-generating their related categories, so we could purge out the handcoded GC/Wii category assignments. Again, this requires a lot of page edits so it should be approached carefully.
 * For the dual-category categories, let's look into getting an "intersection" extension in place, which I think will make this as easy as editing some template parameters.


 * I'm going in for some surgery after breaking my foot Mon morning, so I may not be able to respond/follow-up on this for a while. But hopefully we can work this out over the next few weeks. Kolano (talk) 07:35, 21 September 2015 (CEST)


 * Regex search-n-replace is something I thought we could do it after the new infobox took in effect, but since you've said it'd take quite a while, I'm afraid you're right, it might not be good idea to go ahead with all the changes in infobox when the articles are not ready for it yet. I actually don't mind investing my time into it and undertaking regex search-n-replace if I know how to do it, because I don't have much else to do. Do you/they not mind if the recent changes page exploded with regex replacement changes? I can start with adding "system=" and leaving the console names out of "platforms=" in the Virtual Console game pages. I want to apply "Virtual Console" as platforms along with GCN and Wii, in similar way the games was sorted in Dolphin gamelist by platforms (Virtual Consoles as WiiWare actually & unfortunately).


 * I don't know anything about Mediawiki addons... sorry! I'm still learning wiki codes. Maybe you could do it meantime?


 * Hoping you get better soon! Lucario (talk) 07:56, 28 September 2015 (CEST)


 * Personally I still think that some sort of cross referencing wiki plugin would be the best approach for this. That way a user could combine "Wii games" and "Input GameCube Controller" and get the list you wish to create, all without us editing a single page! The best part is, we'd instantly get a very powerful cross referencing system for controllers, allowing for far more possibilities that even you have imagined! - MayImilae (talk) 12:30, 22 September 2015 (CEST)
 * I don't mind that actually. Lucario (talk) 07:56, 28 September 2015 (CEST)
 * Is it that addon which is enabled recently that you were referred to? I'd like to set up the console <-> input method categories. Is it possible currently? Lucario (talk) 03:18, 25 November 2015 (CET)
 * Yes, sorry, had wanted to test it out in a few spots before moving on to that. Syntax is described here. By default it spits out long flat lists, so you may need to play with it a bit to get something formatted like categories. One other oddity I ran into was that when using the "uses" clause it seemed to trace through certain redirects, listing disambig pages as well as pages linked by them. I was able to manually filter out the undesired pages, but it make things trickier than they should have been. Kolano (talk) 03:47, 25 November 2015 (CET)

Inclusion of deletterbox codes, film grain removal codes and blur removal codes
Hi, I would like to ask you for your opinion on the inclusion of deletterbox codes, film grain removal codes and blur removal codes. I believe players should be able to tweak the graphical settings of their games as they wish, and believe Dolphin Wiki would be a great place to list such codes because they can be difficult to find elsewhere, and they are purely optional. The discussion for this is here. Devina (talk) 18:52, 4 February 2016 (CET)

Banned list

 * GameCube games with Korean release date


 * Chinese release dates - consoles were banned in China (2000-2015)

Config Template Spacing
Thanks for taking out the gap in the config template the other day. If you have a chance please take a look at the few other gaps that remain in the template. They can be seen at Template:Config/sandbox/doc. More or less any time a config section is skipped an additional gap appears. Kolano (talk) 08:28, 10 November 2016 (CET)
 * Sorry, I'm not sure why the parser function (#if:) isn't preserving newlines for the header tags (== ==) to render. I do know that when the parser function that output empty newlines consecutively there will be large gap in between. Lucario (talk) 05:24, 11 November 2016 (CET)
 * Apparently "===" is really, but the latter one does not require newline. Lucario (talk) 06:33, 11 November 2016 (CET)

Version Labels
Thanks for the update trimming the "r" info from the intermediary version label. The "r"'s are only maintained to allow for sorting/alignment and generally shouldn't be exposed (outside of the old revs where they were the primary ID). A few further suggestions... Kolano (talk)
 * I think adding a transparent white background will likely help with remaining overlap. Such should cause the most recent revs to obscure later ones, hopefully better maintaining text visibility, while still leaving older markers somewhat visible.
 * Presuming that works out, it would be nice to add in rev markers for at least 4.0 and 3.0 (and if the overlapping is addressed 3.5).
 * We probably should also purge the "(current)" label on the latest rev, it's also not useful.
 * Also let me know if there are things there that can be better addressed in a base stylesheet. I think when it was initially set up many styles were embedded, but that could likely be more cleanly handled with outside stylesheets.
 * Stylesheet, it's something that I would like to get tooltips working for mobile devices, you can see example here. We could try update there to clean up unused codes while implementing the codes needed for tooltips.


 * The major revision mark overlapping problem still exists on some browsers (can confirm here on iPhone Safari), so we could get rid of "(Current)" appending next to the current revision as it's another trivial information. When I had said I wasn't sure that adding more major revision markers was good idea, it was when they were appended with "r" revision number in parentheses, and they become crowded in many revisions later. I think it's OK to add all major revision marks now that they don't have to have revision number appended with them. I'm not fan of overlapping n obscuring another information, it'll give false positives in browser's find in page function, and the obscured texts, if not fully obscured, will appear chopped off, as if the web page style is broken or poorly designed. Using the white background to obscure another is not in good direction.


 * I'm hesitant to have revision text on top going live outside of sandbox though while it has received enough supporters, but the rotated text didn't received enough supporters which that could've solved the illegible text overlapping problem once the revision texts went up out of bars. We also have problem with revision text in bars as well, they became harder to see in darker colored backgrounds like teal and red. Lucario (talk) 23:54, 3 April 2017 (CEST)


 * Still wish I could understand the resistance to non-horizontal text, such would resolve the overlaps easily, and should only be unsupported in fairly ancient browsers (i.e. prior to CSS3 support). We can make the colors more pastel if text legibility is a problem.

INI History
I noticed you mentioned an archive of INIs in one of your recent edits. I'd suggest checking out the file histories available on files through GIT for a more comprehensive view on INI histories (though only post the transition to GIT), if that wasn't already the mechanism you've been using. Kolano (talk) 00:09, 8 August 2017 (CEST)


 * Come to think of it we might be able to provide some general integration to those histories from the title pages, though the truncation / merging of them probably makes that tough. Kolano (talk) 00:11, 8 August 2017 (CEST)
 * I did tried look though change history of GMSE01.ini (wasn't it and not GFEE01.ini?) on GitHub to find when a setting has been added. I've browsed through its changes on GitHub but then it'd be hard to find the actual Dolphin revision out of it. I can, however, look at change's date to look though download pages of older development versions faster then look for matching PR description, but it's completely useless when the age of last relevant change was older than age of . Lucario (talk) 08:32, 9 August 2017 (CEST)

Preferences
Friendly reminder that you can set your edits to default to minor from within your wiki account preferences in case you get the desire to do mass edits again. You can also increase the recent changes cap to above the normal max of 500 from there as well. - Xerxes (talk) 04:46, 15 January 2018 (CET)
 * Wasn't aware of the abilities to make my edit "minor" without me doing it each time. I have tried 1000 in recent days but returned to 250 because of page loading. Lucario (talk) 05:11, 15 January 2018 (CET)
 * A lot of the time I was just manually clicking the button every time because I'm weird, but there's really no need to do that. At this point I just said fuck it and set recent changes to display 1500. (Sorry for blowing everything up by the way.) - Xerxes (talk) 05:26, 15 January 2018 (CET)