Template talk:Problems

From Dolphin Emulator Wiki
Jump to: navigation, search

Bug

There seems to be a bug with the new Problems template when an problem has an "=" character it causes all indicated problems to be ignored and the "no problems" statement be displayed. This is most frequently seen with External links that use parameters, refer Homebrew Channel. Kolano (talk) 19:18, 3 December 2016 (CET)

I added an equals template {{[[Template:Template:=|Template:=]]}} to work around the problem, unclear if there is any better way of handling it. Kolano (talk) 01:16, 4 December 2016 (CET)
I'll investigate this, probably an edge-case with the RegExp queries... - mbc07 (talk) 01:22, 4 December 2016 (CET)
It seems to be a template parameter parsing issue, unclear if there is anyway to escape them to avoid needing the template I added. Kolano (talk) 01:33, 4 December 2016 (CET)
Also unclear if there is any current way to search for/flag problems effected by this. Problems with external links, and some settings references (i.e. XFB=Real), are likely candidates to cause problems. The old search-n-replace had allowed for regex searches, but I think we lost that with the newly implemented one (I've forgotten the details). Kolano (talk) 03:31, 4 December 2016 (CET)
Okay, the issue is trickier than I though. I double checked all RegExp queries and they all are working as intended, the issue here is the parameter's parsing. Basically, by having a = in those cases is making the problems "text" being passed as an argument different than {{{1}}}, so, the problems never get into the template logic (since it checks for {{{1}}}, and when the bug is triggered, {{{1}}} is empty). The strange part is that the various === from the headings doesn't trigger this bug, yet a forum link like the one from Homebrew Channel does. I'll see if I can do something to somehow prevent that, but at the moment there's no fix other than the workaround you provided... - mbc07 (talk) 05:06, 4 December 2016 (CET)
Since it doesn't seem like it can be corrected, I'd like to focus on identifying pages where it occurs. Can we trigger a category when an unexpected param is provided to the {{Problems}} template? Kolano (talk) 11:47, 4 December 2016 (CET)
Sure, I'll see what can I do - mbc07 (talk) 17:27, 4 December 2016 (CET)
Take a look at the recent edit I made in Homebrew Channel. It avoids the issue completely, although it also makes template usage a bit more "messy". What do you think? - mbc07 (talk) 17:46, 4 December 2016 (CET)
Not sure. I guess it's not too bad once we'd use the search-n-replace to populate it everywhere so users wouldn't have to remember, but it is a bit ugly. I guess that logic has to exist outside the template itself? It's certainly preferable to having users needing to remember to escape any equals characters though, so I'm supportive either way. Kolano (talk) 20:43, 4 December 2016 (CET)
Yes, it must be outside of the template. It's basically assigning a variable with the text before passing it to the template, and it avoids the issue because = has no special meaning when defining a variable. The content of the variable is then "echoed" into the template parameter {{{1}}}, avoiding it wrongly recognizing = as a definition of a specific parameter. Another possible approach is using {{#vardefine:problems| <problems text here> }}{{Problems}} then refactoring {{Problems}} to work directly on that variable instead of the {{{1}}} parameter, but it still looks a bit messy. What do you think, does it look better? - mbc07 (talk) 01:55, 5 December 2016 (CET)
If it can't be embedded it doesn't really matter, the initial nested handling is probably easier to understand. So my vote would be to search-n-replace away with the initial handling.Kolano (talk) 04:12, 5 December 2016 (CET)
Alright, nested handling then. I'm a bit busy but if everything goes well I'll start the batch replace with the fix in a few hours... - mbc07 (talk) 07:00, 6 December 2016 (CET)

Template Request

  • EFB Poke: Nintendo Puzzle Collection, BlowOut, Okami
  • GBA link working / broken info:
    • The_Legend_of_Zelda:_Four_Swords_Adventures#Game_Boy_Player
    • Category:Game Boy Advance (Input supported)
    • Per JMC: I was looking for MayImilae earlier, and she told me she was busy, but, I think it's about time the GBA <-> GCN notes got updated to the new behavior? Namely, it's missing on a bunch of games, and on Four Swords it is so incorrect that it makes me barf. Here are a few pointers: There are possible audio issues when using HLE; it bugs out on ucode swapping. Only one GBA will connect on HLE audio. Pokemon games don't work afaict, but others have gotten them to work. I can't.
  • Device Connectivity: Skylanders and etc, refer issue 5153
  • In-game screenshots
I have all games from the main series and some spin offs and from personal experience we can safely split them between first gen (Just Dance 1/2/3/4, ABBA You Can Dance, Michael Jackson The Experience) and second gen (Just Dance 2014/2015/2016 and onwards). All first gen titles have video corruption issues due to filtering enhancements. Second gen titles doesn't suffer from filtering issues but works only with wiispeak branch (or Ishiiruka) and requires EFB2RAM to properly display characters in many songs. Just Dance Wii and Just Dance Wii 2 are also first gen titles (based on Just Dance 2/Just Dance 3, respectively), can't say anything about Just Dance Kids or other spin offs like Dance on Broadway...
After 5.0 stable and recent builds, everything is fixed on the newer Just Dance games. The only common problem is probably worth creating a template is for the Filtering issue on Just Dance 1/2/3/4 (but I suspect it might be already fixed in a PR opened recently which improves EFB2RAM Copy downscaling filter -- haven't tested it, though) - mbc07 (talk) 19:33, 7 September 2016 (CEST)
{{Problems}} should focus on problems not enhancements. I doubt we'd want the enhancement counterpart either. Lucario (talk) 02:59, 26 December 2015 (CET)
I'm pretty sure we would, titles with Filtering scrambling videos would be a good example case. At the same time I'm not very supportive of covering this particular issue the way we do. It's about distorting titles not intended to run at 4:3, not via an AR code or other means that would do so properly, but by stretching/skewing the rendered image or cutting off portions of the display, which I don't consider an "enhancement" at all. Kolano (talk) 08:02, 26 December 2015 (CET)

Other Shared Problems

Let's be careful not to go *too* merge happy with problems! For issues that only have two or three entries, I don't really see the need for it. Also, we need to be careful about association! The heat blur issues aren't really related, and I would be opposed to those. But the banding problems are related, since they use the same engine. Let's be careful! - MayImilae (talk) 10:02, 13 December 2015 (CET)

Noting Additional Data

Various shared problems have additional data tacked on to the end of statements (screenshots, particulars of the issue for that title). I think we may want to handle that differently so we can be aware of such content when these issues need to be cleaned up. Some strategies:

  • Just ignore it, always remember to postfix something like ".*?(?=== )" to the ends of search 'n replaces used to clean these up (i.e. followed by "== "). (My regex syntax may be off there). Though something a bit more complicated would be needed to account for shared problems following one another.
  • Add notes regarding the post-fixed content on each shared problems documentation page, and be careful cleaning shared problems with such text. We probably should have some standard documentation of it in any case.
  • Pull the content into the shared problem in some way (i.e. provide additional parameters). Though this probably makes the clean-up steps equally hard as with the "ignore it bullet", so perhaps not a good solution.

Please chime in with opinions/other ideas. Kolano (talk) 22:14, 17 December 2015 (CET)

Use comment tags instead of {{Problems}} for peculiar shared problems?

Just a thought, it'd not be ideal to create {{Problems}} for very specific things. Using a comment tag like <!-- possible shared problem: [[game title]] --> into each article source will do a better job telling editors that there is game with shared problem and should be updated accordingly, or not. Shared problem with different culprit is always a possibility. And thus using {{Problems}} templates will be more of a burden.

Using commented tags instead will also preserve unique sentences. We won't have to worry trying to merge different sentences across games with shared problems.

This will finally purge out "Mario Galaxy 1/2 shared problems", "Paper Mario shared problems", etc. and other shared problems with unsure culprit ("Heat Effect/Blur: F-Zero GX and Rocket Power: Beach Bandits" where MayImilae suggested not to merge) from above. Lucario (talk) 20:45, 31 October 2016 (CET)