Project talk:Wiki Conventions

So, I've been working on this in my spare time, just wittling away at it. I had intended to keep at it myself till it was more complete, but with all that's been going on I've neglected it a bit, plus Kolano is doing something very similar with the Infobox VG template documentation, so I figured it was time for me to open this up and get some help. This wiki is colaborative, so let's work together on it. The only request I have for the style of this is that it avoid "rule" language. Thou shalt and thou shalt not type stuff. Just read the "preamble", and you'll get it. I'd like to be open and inviting, focused on how we do things and why, and not be bossy. I'm not sure I got that standard myself, but that's the goal for me.

So, first up, the things that are wrong with it right now. You'll notice there's alot of blanks, but that's just stuff that isn't complete yet. The broken formatting is the biggest issue for me right now.
 * How to format the opening. Putting the "preamble" up top created a situation where there is this tiny bit of text up at the top against the header, and then the giant contents box, then the information people wanted. It made the preamble completely invisible!
 * Seriously, how on earth does one get multiple lines into  code? I tried everything without any luck. Anyone have any better ideas for that section?

- MaJoR (talk) 08:11, 17 November 2012 (CET)


 * If you want multiple lines in the  tag, you must insert a space infront of each line. I've fixed the lines in the page already as a test. As for the preamble. I think the preamble and methodology can be merged into one section since it seems like they have a similar intention. ─ Garteal (talk) 14:01, 19 November 2012 (CET)


 * ...of course it was somethings simple. DOH. Thanks. As for the merging of the preamble and methodology, I thought about it, but I wasn't sure how to make it flow well from one to another. I'll try again sometime soon. - MaJoR (talk) 14:16, 19 November 2012 (CET)

FOV patches
I think there should be a convention to that can support FOV changing here because certain amount of people want to adjust it for a nice view something like zoomed out.--Brandondorf9999 (talk) 22:09, 15 July 2015 (CEST)


 * I oppose adding FOV codes; they modify the way the game was intended to look and it's a lot more invasive than a simple widescreen fix, 60FPS codes or cheats to bypass emulation issues (like ZTP patch). Also, from the recent troubles regarding cheat codes, only you showed interest in adding these kinds of codes while the majority of other wiki admins and active users are against them too. Jhonn (talk)


 * Well you need to support them. It's not invasive, it's an enhancement. Also, it should be like other games where you change FOV on like Call of Duty.--Brandondorf9999 (talk) 00:19, 16 July 2015 (CEST)


 * We do not. There is no FOV codes indicated for any of the Call of Duty games on the wiki, so I'm not sure what you are talking about there, I suspect you may mean the PC Call of Duty, which has nothing to do with this wiki. In general such codes augment gameplay in ways that were not intended by their developers, which is specifically counter to the goal of enabling accurate emulation here. Kolano (talk) 02:15, 16 July 2015 (CEST)


 * There is a Call of Duty wii game with the FOV code submitted by Bully WiiPlaza and it's located somewhere in that gecko code page. That one's called Call of Duty: Modern Warfare 3.


 * Another note is that it's proper emulation, but some of them have bugs. The game in question can have more FOV than the one they adjusted it for.--Brandondorf9999 (talk) 03:21, 16 July 2015 (CEST)


 * You're still the only one showing interest in adding them, so, not gonna happen, as I said, the majority here is against. Jhonn (talk)


 * I think you need to lose your admin status because you're agreeing that the fov codes shouldn't be posted other than widescreen fixes.--Brandondorf9999 (talk) 07:56, 16 July 2015 (CEST)


 * Hahahahahaha don't make me laugh, now I should lose my admin rights just because I do not share the same opinion as you? Grow up dude. By the way, where's your contributions to the wiki? As far as I can tell all you did was uploading screenshots modified outside of Dolphin (and even getting a temporary ban because of that) and adding cheat codes we already gave N reasons why we don't want them, then complaining about how an admin should lose his rights just because he's opposing your opinion in a particular subject. You also seem to disregard the opinion of the other admins as if I, and just I, were opposing your FOV codes. If it's not clear to you, like me, Kolano and MaJoR are against those codes too, as they already expressed in Talk:Mario Kart Wii. So I'll say one last time: taking in consideration the opinion of currently active members and admins, FOV codes aren't coming to this wiki. Jhonn (talk)

Widescreen codes
Ok, I'll be direct: the whole AR codes thing got too far and in most pages it's a mess. Some time ago (from a PM I think) MaJoR also was bothered that we should remove codes of non-standard ARs (like 48:10, 21:9), allowing only 16:9 which still is the standard for majority of monitors. What also bothered me is that every page have this section in one format, not to mention that most of these codes makes things worse (I tested many AR codes that Karasuhebi reverted and indeed they caused way more problems than the built-in widescreen hack, save for 3 exceptions -- Paper Mario: The Thousand-Year Door, Bomberman Generation and Pokémon Colosseum) and because of that I'm removing them right now. I'm also proposing a standard entry for this section (as you can check now in the games I mentioned before). Basically:


 * 16:9 AR only: I know 21:9 monitors are slowly gaining market but I tried implementing other ARs as well but the final result always were a mess (like the previous version of Wind Waker page). We should stick with 16:9 which still is the standard for majority of monitors.
 * Quick and dirty: Say what doesn't work with built-in widescreen hack and that's all. We don't need to explain why the game does that, as an end-user I would simply get the code and close the page/go somewhere else.
 * Unencrypted codes only: Encrypted codes (aka. Action Replay standard) are just bigger and offer no advantage at all. As example, before my edits in Pokémon Colosseum, someone entered both an AR for PAL and for German version, the encrypted code was different but the unencrypted result was exactly the same
 * Only tested codes: That one may be tough because we don't own all GC games in the world (although JMC4789 surely can help us with this). So, only include a code if it really fixes something that the built-in widescreen hack can't handle. That's to avoid mass reverts of non-functional codes like the recent one from Karasuhebi

If you guys are OK with that I'll implement that into our wiki conventions. And yes, I was bothered with that and just edited many pages with what I'm proposing without consulting you guys first but feel free to change them if someone oppose something. If everything goes well I'll try to achieve a standard for 60FPS patches too (look at Zelda Collector's Edition, it's another huge mess >_< ). - Jhonn (talk)


 * I complete agree! I would even go further and ban 120FPS codes too. What do you think Kolano? - MaJoR (talk) 14:42, 19 August 2015 (CEST)
 * And 21:9 monitors are super niche, 1440p and 4K are where the growth is. Both 16:9! :D - MaJoR (talk) 14:48, 19 August 2015 (CEST)
 * I so wish that wasn't the case. 21:9 monitors is where's it's at! :D -Karasuhebi (talk) 17:10, 19 August 2015 (CEST)


 * Glad to see this AR code cleanup picking some steam, I'm glad I could contribute a bit in that respect. Great job Jhonn! :D -Karasuhebi (talk) 17:10, 19 August 2015 (CEST)


 * I'm glad to see further analysis/clean-up occurring here. I would like to be careful about cutting out too much though. I kind of feel that codes for "standard" aspect ratios / higher framerates should be preserved, as I see them as enhancements Dolphin can provide to those with appropriate hardware. I was all for purging somewhat arbitrary ones (i.e. for multiple monitor aspect ratios, since there's an endless set of them), but those aligned with display devices with larger production runs I'm less comfortable with generally purging. This may be my 16:10 monitor talking though. We shouldn't be posting things just cause they exist though, so purging out ones with oddball effects that don't improve on the widescreen hack is for the best, thanks a lot for your recent analysis there John.


 * There is one other thing I'm wondering here, should we rename the current "Patches" section to perhaps be labeled as "Enhancements" (or moved down the page below the Problems section). That would allow for things like discussion of issues with 3d Stereoscopic enhancements there that may not align with the term "Patch" (I know we have a separate page for such, but I doubt it get's seen much). As emulation continues to improve we should reach a point where enhancements should be the only thing to track here, so we probably should put some thought into how we approach that state (even if it's a ways off yet).
 * Kolano (talk) 22:25, 19 August 2015 (CEST)


 * Not sure if this was directed to the other admins or if I could also weigh in here but I'd totally agree with moving it down. I don't like Patches being the first section people see when they go on the wiki. Seems a bit strange IMO. I also agree with renaming it so other things can be included.


 * Also where is this separate page for 3D enhancements? I want to see it. :D -Karasuhebi (talk) 03:10, 20 August 2015 (CEST)


 * I hadn't thought about this before and indeed it makes a lot of sense putting the section below problems. Also, changing to Enhancements seems fine too, after all, HD texture packs, 60FPS or Widescreen codes makes little sense being tagged as Patches. In future, if we start to tag 3D compatibility or required settings it would fit very well in that new section. Regarding codes for other ARs, I tried integrating somehow (after all the address is exactly the same, the only thing that change is the value) but I failed miserably, all approaches I tried became messy and cluttered. Because of that I still think we should stick with 16:9 only. I see this as another confusion source in future, let's say someone puts a code for an awkward AR, like, let's say, 39:12, then another guy come and put another strange AR as well, in little time the pages would be a mess again. And in relation to other "standard" ARs, like 16:10, using crop feature would suffice, I mean, you'll lose a very small part of the frame which is veeeery unlikely to have important data since the game is already running in a wider resolution than the intended. - Jhonn (talk)

I kind of want to clean up and remove all credits that included after the code names after seeing that Jhonn has converted the widescreen code for PM:TTYD then removed the credit, as seen here: Difference between revisions of "Paper Mario: The Thousand-Year Door"

I don't believe anyone can deserve a credit if the code is only made up of one or a few lines, so I'm in support of removing them. Anyone else? Lucario (talk) 08:38, 23 August 2015 (CEST)

I'd generally agree, but one of the major providers of the widescreen codes had thrown a hissy fit that they weren't being credited. Kolano (talk) 17:40, 23 August 2015 (CEST)


 * Sorry for the late reply, I also think an memory address shouldn't be credited, but if that's the case with people complaining we could put a small citation close to the code (like Wikipedia). I'm not happy with that approach but it's to avoid problems, so, let it go. I plan doing the Enhancements change to a sandbox page soon to see how it looks and to address anything else you guys may want... - Jhonn (talk)

Inapporopriate use of Enhancements Section
I don't believe it should be used to list non-default config problems. The most appropriate way to handle them is to not include them anywhere on the game page. If something should be mentioned at all, at least let Emu Info or Problems have it, but it's bit odd to actually let Enhancements have it. It's not normal to hear something like "this problem will enhance your gameplay!" Lucario (talk) 08:16, 16 December 2015 (CET)
 * Problems like the Corrupt Videos problem on Marvel Super Hero Squad are extremely important for us to have. It doesn't matter that it is non-default, anisotropic filtering is essentially a free graphical enhancement (so is per-pixel lighting) which almost never causes problems. When it does cause problems, users are going to forget that option is enabled, and blame the emulator and post issues and on and on. This wiki exists solely to inform users of problems and fill them in on things that they should know about. This is exactly what it's for!
 * And our conventions are not about non-default vs default or anything black and white like this. That is not how this wiki has been run and not how it would serve users best. We tailor what we allow and don't allow in the various sections based on what the users need. - MaJoR (talk) 08:42, 16 December 2015 (CET)
 * That problem is something I'm trying to bring back into Problems section. It was put under Enhancements from Problems section by Kolano recently and I find it inappropriate place for this problem and had tried to move it back into Problems section which made better sense but was undone by Kolano. Then Project:Wiki Conventions was revised recently that would approve such thing. Right now I'm trying to explain that it's still not appropriate place for problem regardless of config. Really, would you like to see the corrupted video (Marvel Super Hero Squad) in your gameplay? It's an enhancement because it's under Enhancements section. Makes sense? Putting it back into Problems or into Emu Info would have been made much better sense. Lucario (talk) 09:03, 16 December 2015 (CET)
 * It's a problem with an enhancement, seems appropriate for the Enhancements section to me. Placing it there allows us to maintain better consistency with things listed in the problems section, which theoretically shouldn't list things that don't occur with default settings. This also allows the title to be rated 5 star without controversy in future. Also if you want to get into nitty-gritty, any problem with a solution could be considered an "enhancement" as they improve upon the broken state. Kolano (talk) 09:57, 16 December 2015 (CET)
 * It's still a problem and most people that come here are readers. The game pages need to make sense for them too. If this problem really still needs to stay out of Problems section because it's from non-default setting then why not let Emu Info have it? It's like another problem section that accepts different problem statements that may be inappropriate for Problems section but still worth mentioning somewhere for the readers. We're not going to take anything from Emu Info into compatibility rating of a game.
 * Actually I still thinks it's best fit under Problems section (and hurt compatibility rating still) because as a "Problem" it expects a solution that dev may come up with someday. Emu Info in my view should be collection of 'WontFix' problem statements. Lucario (talk) 11:05, 16 December 2015 (CET)