Project talk:Wiki Conventions

Preamble Problem
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?

- MayImilae (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. - MayImilae (talk) 14:16, 19 November 2012 (CET)

Encrypted AR Codes
We need to document that encrypted codes are undesired under the Enhancements section, and also provide some examples/other description to allow encrypted vs encrypted codes to be distinguished. Kolano (talk) 22:40, 4 January 2016 (CET)


 * Did this end up getting documented? I'm still seeing encrypted AR codes being added. I also think that a guide (if such a thing can be done? No clue) on how to decrypt codes since some people adding them wouldn't know how to decrypt them in the first place. -Karasuhebi (talk) 21:54, 9 January 2016 (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. mbc07 (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. mbc07 (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 MayImilae 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. mbc07 (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) MayImilae 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 >_< ). - mbc07 (talk)


 * I complete agree! I would even go further and ban 120FPS codes too. What do you think Kolano? - MayImilae (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 - MayImilae (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 mbc07! :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. - mbc07 (talk)

I kind of want to clean up and remove all credits that included after the code names after seeing that mbc07 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... - mbc07 (talk)


 * So mbc07 (talk) it looks like everyone agrees with the standards you have put forth for the AR codes. Can we go ahead and include them in the Project page now? :D -Karasuhebi (talk) 21:53, 9 January 2016 (CET)
 * I'll revamp those and put them in the conventions soon, currently I'm so busy with some personal life stuff that I barely have time to look at recent changes :(
 * (Kolano and MayImilae, feel free to go ahead if you guys want, no worries from me) - mbc07 (talk) 00:30, 10 January 2016 (CET)

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. - MayImilae (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)

Some idea I came up with just now that would solve the false sense with enhancement problems in enhancement section. There would be yet another section named "Enhancement Problems" designated to document the problems of Dolphin's enhancement settings. This will make more sense to the readers than shoving them into the "Enhancements" section. What do you think? Lucario (talk) 01:48, 26 December 2015 (CET)
 * -1 from me, we already have too many sections. - mbc07 (talk) 18:20, 26 December 2015 (CET)
 * Okay, lol. I agree that it's bit too much to ask. I still feel they should go to Emu Info or back to Problems section. Lucario (talk) 09:46, 27 December 2015 (CET)

Ping? Marvel Super Hero Squad felt so wrong still. Lucario (talk) 02:41, 23 November 2016 (CET)


 * They are problems with enhancements, so I have no issue with them appearing under enhancements. I believe the base problem was that we don't want these sorts of issues affecting ratings, and thus banished them from the Problems section. I wouldn't be opposed to adding a separate section to handle them, but such has some problems we'd need to address. A similar issue occurs with "Emulation Information" so it may not be bad to address generally anyway.
 * I think the general opposition to adding additional sections is that general editors frequently fail to have necessary insight to use the appropriate sections, particularly if they don't pre-exist in the page. Having them pre-exist causes an alternate layout problem, in that many empty sections are off-putting. Due to that we had tried to limit the use of these sorts of categorizations, but it seems we've slid a good distance from everything under problems and only problems handling of the past.
 * In any case, support might be higher if we can work out ways to try to ensure new edits go to appropriate sections, and there would be a means to avoid the ugliness of empty sections. Perhaps further commented sections inclusive of some descriptive commentary? Still unclear this will see general support.
 * Kolano (talk) 03:06, 23 November 2016 (CET)


 * I think better commenting the sections is a good idea. I second that. Karasuhebi (talk) 05:18, 23 November 2016 (CET)


 * Yeah, it seems that creating new section types will certainly get things out of hand. I'm not sure I'll like that every section to have comments. I thought we have good section names that's very easy to understand by everyone. I wasn't bothered by empty sections, they're there for the sake of preserving layout alignment and Edit buttons and that's good. Anyway, I have noticed we don't use Emulation Information and Enhancements section correctly sometime, like some problem sometime getting shoved into Emulation Information that should've been in Problems section and to hurt the compatibility rating. Maybe someone was desperately trying to rate that game as 5 stars. The opposition is true, there are some problems that Emulation Information deserves more than others, like (IMO) problems of Dolphin's enhancements (had old mindset that they should go to Problems section but I don't have that any more). Would you be fine with every problems relating to Dolphin's enhancements to go under Emulation Information instead? It'll make more sense because then it'll not be like "this problem will enhance your gameplay because since it's in Enhancements section", Dolphin's enhancements aren't like other enhancements. We don't see something like "Dolphin has Anisotropic Filtering feature for this game! You can choose 2x though 16x," with a side note "Note: causes corrupted videos tho". I have noticed that problems under Emulation Information sometime get resolved randomly, although they weren't Dolphin's problems (where Problems section don't deserve), I think it'll be good idea to take these such problems into Emulation Information either way, so one day these problems may miraculously go away as well. It's good that compatibility rating only reflects problems in Problems section than others. Lucario (talk) 09:00, 23 November 2016 (CET)


 * What's wrong with every section having comments? It's not like you can see them unless you go to edit the articles. Karasuhebi (talk) 04:12, 24 November 2016 (CET)


 * Oh... that comment tag. I'm not sure how will it help with situations like this. Lucario (talk) 04:48, 24 November 2016 (CET)


 * How will that not help? I thought Kolano said the issue was "general editors frequently fail to have necessary insight to use the appropriate sections". Karasuhebi (talk) 06:41, 24 November 2016 (CET)


 * It was Kolano who moved the problems of the Dolphin's enhancement into Enhancements section, not the other editors' doing. I don't mind comment tags where necessary but that's not within the scope of this topic. Lucario (talk) 07:10, 24 November 2016 (CET)

Still believing this is wrong. Rule created and enforced by one man. Sad. Lucario (talk) 13:17, 14 January 2018 (CET)


 * I like the way it is currently, honestly. It was the ultimate compromise between allowing enhancement information on the wiki while not hurting the rating. Though I agree that the naming is kind of bad/nondescriptive, it always seemed like a "hack" to me to get the information in. If the section was renamed from "Enhancements" to "Enhancements Information" or the like would you like that better, out of curiousity? I don't really think shoving it all into Emulation Information is that great of an idea just because Emulation Information already has its own identity as a spot to capture game-specific quirks which don't particularly fit into any of the templated locations. - Xerxes (talk) 17:43, 14 January 2018 (CET)

Change Name: Emulation Information -> Emulation Notes?
JMC4789 added his own section name into Fire Emblem: Radiant Dawn. I like it. What do you think?

Well, after asking google the meaning of "information" and "notes", "Information" makes better sense. Lucario (talk) 16:07, 26 December 2015 (CET)

Virtual Console: Nintendo.com Game Guide Cover Art
Currently, we use the game's original cover art for Virtual Console pages, causing pages to be quite inconsistent across systems. Compare the pages for Arcade VC, C64 VC, MSX VC, Neo Geo VC, N64 VC, NES VC, SNES VC, SMS VC, Genesis VC, TurboGrafx-16 VC, WiiWare, and Wii Channels to see the largescale inconsistency. Arcade games use fliers instead of boxes, SNES and N64 boxes are wider than they are tall, C64 boxes are typically quite worn, and that's just the tip of the iceberg. These pages are all documenting downloadable software for the Nintendo Wii and should look consistent with each other. Nintendo.com's Game Guide has consistent covers for the VC releases we could use instead. For example, here's their cover art for Sengoku 3 for the Neo Geo, and Double Dragon 2: The Revenge for the NES. The only downside is that Virtual Console game covers would be the same 160px width as WiiWare covers are now, but this could be remedied by upscaling them using something like Waifu2x. For example, here's the Game Guide cover for Double Dragon 2 upscaled using it. - PowerKitten (talk) 17:39, 11 October 2017 (CEST)
 * I don't believe these were provided consistently across regions, so you end up with similar inconsistencies between NA, EU, and JP releases with them anyway. A related issue exists for WiiWare titles, where the US Wii Shop images were used, but similar images don't exist for Asian releases. Using the box covers per our region preferences tends to provide a consistent reference point for what the image should be, outside of a few "disk download only" JP NES releases, and the arcade titles where we've made due /w the flyers. Kolano (talk) 01:46, 12 October 2017 (CEST)

Regarding Infobox Series Convention
I would like the convention on using italics around series names in the infobox to be changed. Besides the special case of differentiating different consoles in the release dates/publishers sections, stylings aren't used for infobox entries in any other case. And the italics weren't even preserved in page output; before I touched this section of the template, the very first thing that was happening to the series entry was it was regex replacing all '' with nothing, deliberately stripping this markup off. If there's still a desire to put the series links in italics, I can set that up from within the template, without needing them actually added on every page like it was before. - Xerxes (talk) 19:07, 24 December 2017 (CET)

Yeah, it was a convention from early in the wiki, prior to all the customization of the infobox template. And yeah, as you had noticed, it had gotten ignored/hidden when the initial infobox customization went into place. There is probably no good reason to preserve it. Kolano (talk) 23:46, 24 December 2017 (CET)


 * No objections too, go for it. - mbc07 (talk) 07:19, 26 December 2017 (CET)