Template talk:Problems

From Dolphin Emulator Wiki
Revision as of 22:56, 6 August 2017 by Mbc07 (talk | contribs) (Username rename (MaJoR => MayImilae))
Jump to navigation Jump to 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 {{=}} 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

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 pay (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)

Black Bars

As is apparently common with GameCube titles this game adds black bars around the edges of the screen to avoid gameplay being covered by television bezels. Figured we should probably have a common {{Problems}} template for such, but want to get some further details first. How it works seems to be a bit odd, at least for this title. Here I get black bars at startup (in 4:3 mode) and all the time if in fullscreen mode, but if in windowed mode /w Auto AR and Auto Adjust Window Size no side black bars are seen. In any case hoping someone can chime in regarding some of the details with titles and black bar edges. Kolano (talk) 05:54, 2 December 2015 (CET)

AFAIK enabling "Crop" option in Graphics settings should get rid of those black bars in recent revisions. Have you tried it? - mbc07 (talk) 16:32, 2 December 2015 (CET)
Noticed that last night, but didn't have a chance to try it. How "smart" is the cropping? Different titles left a variety of different sized gaps; some only on one pair of sides, some even allowing fine grained control over their coverage area. Kolano (talk) 22:57, 2 December 2015 (CET)
Perfectly smart! Described in a progress report here To poorly describe how phire put it when he told me about it, it uses the area that the game tells the hardware it will render to within the rendering space. It will eliminate all black bars, period! And it does it by zooming in, instead of the old squishing method (which can be achieved by using stretch to window). - MayImilae (talk) 12:27, 3 December 2015 (CET)
OK, question spew...
  • Any chance we'll still see "a full blog post ... coming later to explain all of the technical details."?
  • What's the feeling on how we should handle titles with black bar issues? Would a {{Problems}} template be appropriate for them (the review process for this seems pretty large though :-\ )?
  • "Crop" is defaulted to off, should we be recommended it be turned on for titles /w black bars (or perhaps in general)?
  • Do we know how crop works out on titles that allow redefining their AR? I'd need to reference back through the recently GC Widescreen test titles, but at least one provided individual adjustments for both the horizontal and vertical (and possibly also allowing an offset for an uncentered image).
Kolano (talk) 20:15, 3 December 2015 (CET)
I'm pretty sure all of the recent "black bar" problems are invalid. ALL games will have small black borders around them now with crop off, and this is by design. I think this black bar things that keep popping up are just people seeing the black and adding errant problems because they don't know how it works. Honestly, I wish phire had set crop to on by default to avoid that. :/ As for any issues with crop... there shouldn't be any. And crop works on games that redefine their Aspect Ratio. Much like how aspect ratios are handled now, crop uses what the game tells the console, so it is extremely reliable. The auto widescreen detection algorithm could have some problems, however, but they would be separate from crop. Also, if by black bars you mean something like what the Metroid Prime 2/3/Tri problem? That's very very different and unrelated to all of these!
As for the article... ask phire. He's been procrastinating it! Also, if you want any information at all on this, phire knows all about this, and he can fill you in.- MayImilae (talk) 04:48, 4 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)

Retrieved from "https://wiki.dolphin-emu.org/index.php?title=Template_talk:Problems&oldid=148839"