User talk:The Retro Gamer

Welcome!
"though it's somewhat ironic to welcome someone years after they joined, when they joined around the same time you did." Truth be told, I didn't actually look at your edit history when I gave you this message. I just noticed you made an edit and then gave you the template because that's what we did back then :P 23:12, 27 March 2018 (EDT)
 * I'm sorry if I poked you a bit with my edit summary. I just got a bit of amusement seeing this message on my user page years after I registered an account. Obviously, I haven't been very active on Super Mario Wiki (I spent most of my time editing on Donkey Kong Wiki while people were still active there), so it's understandable that you would add the template. --The   Retro   Gamer  09:02, 29 March 2018 (EDT)
 * Nothing to be sorry about, I find this funny myself. Sometime later, I did notice you registered years before, but by the time I noticed that, it was like "Well, too late now!" That's probably one of the reasons why we abandoned this template :D 11:00, 29 March 2018 (EDT)

Merging the wikis
Hello! I'm a supporter of DKWiki merging with Super Mario Wiki. At the suggestion of, I came here to point out some good articles from the DKWiki whose Mario Wiki counterparts would be significantly improved if they had the others' information: Bonus Level, Funky's Fishing and Crosshair Cranky. Just some help with the job. Many people agree with the proposal and there's currently no opposition. My question is, what's gonna happen to DKWiki articles that are equally as good as their MarioWiki counterparts? Would be a pity to delete them simply. -- 11:28, 27 March 2018 (EDT)


 * I appreciate your input (as a side note, Crosshair Cranky was recently renovated by Atari Jaguar.)


 * In regards to the merging process, I am planning to systematically review all articles on DKWiki. After an article is reviewed on DKWiki, a review indicator will be applied to that article (either a template will be added or the page will be deleted; I haven't finalized the review marking method.) During that review process, many of the articles will have no new information or be identical (i.e. likely copied from Super Mario Wiki). These can be safely marked as reviewed. Another group of articles will have new information, or obviously improved formatting, and will be integrated into Super Mario Wiki's version of the article. For the rare case where the information is comparable, but the style is incompatible, a judgement call can be made on which style to retain. Most articles will not have this problem; the information and style of DKWiki is relatively comparable to Super Mario Wiki.


 * Hopefully that somewhat addresses your question. If you have any more questions, feel free to ask them. --The   Retro   Gamer  15:04, 27 March 2018 (EDT)

For the record...
For the record, as the guy who coloured it the way it is to match Navigation templates, I was well aware that doing the CSS code directly in the DKC article was...less than efficient (one reason why the previous formatting is still on DKC 2/3, etc), especially since there doesn't seem to be a simple way to do odd/even rows within the page code except by doing each row manually [vs. (odd)/(even) in an external stylesheet]. So I support your efforts :) - Reboot (talk) 18:38, 15 April 2018 (EDT)
 * Thanks! I've been learning some CSS, and realized it had direct application here, so I just wanted to help. --The   Retro   Gamer  18:40, 15 April 2018 (EDT)

re: 2 questions
1: ayyyyy, just applied it to the css.

2: While making a proposal would be the "proper" thing to do, I guess, my opinion is that it would be an unnecessary delay. I doubt *anybody* would have strong feeling on the notion, especially given the prevalent opinion among the community that DKWiki was redundant, and any objection to content change resulting from the merger would be on a vase-by-case basis anyway. --Glowsquid (talk) 19:06, 15 April 2018 (EDT)
 * Okay. I've been considering the differences between the wikis, so nothing controversial will change without consensus here. People have already been trickling in from MarioWiki to support it anyway, so I agree that it's probably not problematic to merge at this point. --The   Retro   Gamer  19:16, 15 April 2018 (EDT)

Bot
Yeah, um, you can't have your own bot. Not sure how things are run and if you have one on the DKWiki, but here only Porplemontage is allowed to have a bot, or one officially created by the administrators. We have some policy pages on this, namely Bots and Blocking policy. However, you are able to request to a Bureaucrat to give you bot status for a time should large changes be needed. 21:55, 15 April 2018 (EDT)
 * Just saw you messaged Glowsquid about the account, so if he says something different that what I said here, follow that instead :P 22:02, 15 April 2018 (EDT)
 * (Edit conflict) Some merge tasks will require a bot, so I've (perhaps prematurely) registered an account for that purpose. Porplemontage does have a bot for template replacement, but that will be insufficient for merging. If it's a real problem, it can be disabled after the merge is complete, but it will be necessary in the near future. --The   Retro   Gamer  22:04, 15 April 2018 (EDT)
 * I'm not sure what you plan on using the bot for (likely to help with merge, I'm assuming), but if you need any large-scale maintenance done, you should talk to Porple and see if he'll configure his bot to do what you need one to do. 22:07, 15 April 2018 (EDT)
 * Yes, the bot would be solely for the merge. Porple could probably configure something, but from what I've seen of his bot's contributions here, it's mainly for find-and-replace. I have more specific needs than find-and-replace, like template modification, category additions. I'm not going to do anything without discussion first. Regardless, the point is currently moot, because there's not any immediate need for a bot until I have more specific plans outlined. --The   Retro   Gamer  22:15, 15 April 2018 (EDT)

re:Flagging an alternate account
I gave it the bot rank due to the unique circumstances but I have no way to manually set it as autoconfirmed. If push comes to shove it might be easier to ask porplemontage to program porplebot to do your bidding tbh.

I'd recommend starting a thread on our forum board for wiki projects to discuss the merger and identify point of contentions before going forward with a proposal. --Glowsquid (talk) 22:20, 15 April 2018 (EDT)


 * Porple also may be able to set it to autoconfirmed, or I can get the status the old-fashioned way (time and contribs; shouldn't be too hard). Thanks for the suggestion about the boards, I'll make a post there soonish. --The   Retro   Gamer  22:24, 15 April 2018 (EDT)

Photo Album
Um, you realize we do keep separate articles for official enemy classes, like Dudim Phreykunoutonthis as separate, right? You should split those all back. Either way, that's a large enough-scale change you should have run a proposal for that, period. Doc von Schmeltwick (talk) 00:03, 16 April 2018 (EDT)
 * "Large-scale" varies on the perspective, but I can run a proposal on it if you think it's controversial. You can easily revert my changes if you want to. I've said my piece: the groups aren't independently notable of the album, and it's more useful to redirect them to the album than to spaghetti them into stubbish and speculative pages. If this is a question of consistency, perhaps other enemy groups should be combined into "Enemy groups of Game name" articles --The   Retro   Gamer  00:08, 16 April 2018 (EDT)
 * It's not stub if it covers all necessary bases :T . The only reason we don't have one for the DK1 enemy classes is that the names are so overly-generic. Doc von Schmeltwick (talk) 00:11, 16 April 2018 (EDT)
 * Note I said "stubbish". --The   Retro   Gamer  00:18, 16 April 2018 (EDT)

Just for future reference, the outline for a talk page proposal is located on the Proposals page in both the Basic proposal and support/oppose format and the Talk page proposals sections. And just a suggestion, maybe go over our policy pages or ask before making major changes, as you seem to be having some trouble adjusting. I know you're just trying to get the merge with DKWiki to work as flawlessly as possible, but you also need to keep in mind how the Super Mario Wiki is handled. Most of us (all of us that has said something, anyway) support this merge and we're here to help you if you need it :) 00:47, 16 April 2018 (EDT)
 * The layout needs to be surrounded in  tags for clarity, because I did copy it directly from the page. I'll try not to step on any more article modification landmines; I did check Redirects prior to making the change, but it didn't cover turning pages into redirects, so I guess I should have realized that needed a talk page proposal.  --The   Retro   Gamer  00:50, 16 April 2018 (EDT)
 * Pretty much everything in a game with a name gets an article (levels, NPCs, etc.). The only real exception to this so far I can think of has been Power Moon missions. How we went about the Power Moons was decided by a proposal, and it seems to be somewhat the same case here. Usually, a major change such as a page conversion is something that needs to be discussed first, especially when it goes against what has already been solidified.
 * "The layout needs to be surrounded in  tags for clarity" What exactly needs this? Never mind.
 * And got your message as I was typing this: the is there, it's just located in the talk page proposals section. It says to add the template to the top of your proposal, under the header. And I'm not sure on the time, that was decided before I was even registered. Might be a question for an admin that's been here longer than me.  01:07, 16 April 2018 (EDT)
 * Thanks for the clarification.


 * I guess "Pretty much everything in a game with a name gets an article (levels, NPCs, etc.)..." is a community norm? In my opinion, that's a dreadful norm that encourages stubbish articles which could be combined into more meaty, interesting articles. It's somewhat disconcerting that this wiki doesn't have Notability. But DKWiki probably doesn't have it either. --The   Retro   Gamer  01:29, 16 April 2018 (EDT)
 * Further down on the main proposals page are where the main proposals are held, for things like major wiki-wide changes. The pre-writen code is meant to be the base for those proposals, with an explanation on how talk page proposals work coming next. An extra parameter, sure (it's only seven characters), but there's no need to write the whole code a second time on the same page.
 * The "everything gets a page" thing is so everything gets its own set of information. It would look terrible if all those infoboxes and Name in other languages charts were crammed onto one page. It also makes categorizing easier. 01:31, 16 April 2018 (EDT)
 * I have to sign off because it's getting late for me, but if you have any other questions, let me know and I'll get back to you when I log in tomorrow :) 01:33, 16 April 2018 (EDT)
 * Oh, no worries about signing off. Patience is the rule of wikis; without it, one will inevitably despair or be blocked.


 * I'm fine with everything getting its own information, but not everything needs an infobox. Names in other languages may have a point, but it can't take up too much space? Though I can see how it can be problematic if a named thing doesn't get more than a mention in the main article. Though, I'm not here to change Mariowiki policy, I'm just here to integrate articles (at the moment).


 * Regarding the proposal template, how about this proposed modification then:

[Enter the proposal title here]
[If it's a talk page proposal, include this template: ]

[Describe what issue this proposal is about and what changes you think should be made to improve how the wiki handles that issue]

Proposer: Deadline: [Insert a deadline here, 7 days after the proposal was created (14 for writing guidelines and talk page proposals), at 23:59 GMT, in the format: "August 8, 2011, 23:59 GMT"]

Support

 * 1) [Make a statement indicating that you support your proposal]

Comments

 * With this version all the sentences are capitalized and it's clear the needs to be added for talk page proposals (which are the majority of proposals).  --The   Retro   Gamer  01:44, 16 April 2018 (EDT)
 * To be frank, you shouldn't make a proposal without reading the entirety of the page anyway. There is a separate section meant to describe how talk page proposals work, and there are additional steps that need to be taken for them that would just be a mess to have in the example. 12:20, 16 April 2018 (EDT)

re:Photo Album
Proposals --Glowsquid (talk) 08:50, 16 April 2018 (EDT)
 * No, the main proposals page. --Glowsquid (talk) 09:38, 16 April 2018 (EDT)

Your templates
Several of the template pages you've made don't seem all that necessary. I get that templates are supposed to make coding easier, but most of the ones you've made seem redundant. Not sure on Template:DK levels table row and Template:DK levels table section, but these ones listed raise some major concerns. 22:56, 22 April 2018 (EDT)
 * User:The Retro Gamer/table - This is just the coding for a standard table put into template form. This should be pretty common wiki knowledge anyway.
 * User:The Retro Gamer/table end - Literally just . Doesn't seem useful.
 * User:The Retro Gamer/table begin - Same as first point.
 * User:The Retro Gamer/para rq / Template:Para needed - ...Why do we need a template that displays an error? Wouldn't it just be easier to fill the parameter rather than adding an extra template calling for an error? This doesn't seem useful at all.
 * And User:The Retro Gamer/music doesn't need to be a separate page. You can just stick it in your sandbox. No need to create multiple pages tied to your userspace. 23:02, 22 April 2018 (EDT)
 * Regarding, it can be later expanded to an error category in case a parameter is overlooked. It's a nice catch for mistakes, but if it really isn't wanted, it can always be deleted and removed from the templates it's on. The DK levels templates reduced a great deal of redundancy, allowing changes to the tables to be made in 1 place instead of 7 (before, to change the section headings, one would have to individually modify the section heading for each world's section.) This removal of redundancy and clutter can be clearly seen in this cumulative diff , which reduced the page's size by 5,000 bytes.


 * table table begin, and table end were just a bit of mucking about before I realized it would just be preferrable to use a combination of table tags and templates. I've marked all 3 for deletion.


 * You seem concerned about the number of pages in my userspace. Reading through Userspace, I see nothing concerning about having multiple subpages as long as they're related to the wiki. If I wanted to I could move everything to the sandbox, but it's a personal demarcation: the sandbox is for testing things, and other subpages are for other organizational hierarchies. --The   Retro   Gamer  23:13, 22 April 2018 (EDT)
 * Thing with para needed is that it's an error call, which is something editors usually try to avoid. How we usually have it set up, like in cases with infoboxes and other tables, if a parameter is ignored, it is excluded from the transclusion.
 * Take Template:Character-infobox for example; if "|full name=" is not used on a page, the parameter is ignored. Adding an error call and causing a large full name= is required where the parameter should be is not only space-consuming, but it looks terrible, and if there is something to include there, it would've been included in the first place. Or the parameter can be added later, fully coded and ready to use. This template does not seem necessary.
 * And you're right, there is no limit to userspace pages as long as they are helpful to the mainspace or are meant to be transcluded onto several pages, like a talk archive or status page. But if it's something like a simple table, it doesn't really need a page of its own, unless you're planning on transcluding just it somewhere else (which is something you don't usually do with a table). 23:26, 22 April 2018 (EDT)
 * It does look terrible, and that's on purpose. These templates are meant for a very specific purpose, and diverging from that purpose is always wrong. A table can't skip a cell; it should always be filled with something. An error could alert the current editor or any future editor that the template needs to be modified. I could have set it so that it would display "n/a" if a table cell is not filled, but I want the editor to make the conscious choice to format it that way, rather than have any risk of accidentally missing a cell. It's a bit different from a navbox, because a navbox can be expanded to add more information, while a table needs all of the cells in a row filled when a row is created.


 * Regarding the music subpage that "doesn't really need a page of its own", it's sort of a work-in-progress, and it's the organizational structure I personally find useful. I plan to add to the page. I may misunderstand the wiki format, but I don't think creating a new page uses significantly more memory than adding to an existing page. I will likely continue to create pages for things that "don't really need pages of their own", both because they're a works-in-progresses and because different page names can serve as a useful organizational tool in many cases. --The   Retro   Gamer  23:42, 22 April 2018 (EDT)


 * (If I may chime in) Yes, tables should be complete with information, but in the event it is missing information, it's really not so big of an issue that it needs to grab the attention of users in big, red text. An empty cell in and of itself should be enough to let users know that it needs to be filled. Having text to falsely simulate an error message and alert users is unnecessary and just makes the table look worse than it needs to. 01:33, 23 April 2018 (EDT)


 * Fair point. I've updated it so if individual cells are missing in, it just displays a "?". I have however, retained the other error messages for the moment, since I would prefer the template not be misused unintentionally.  --The   Retro   Gamer  06:46, 23 April 2018 (EDT)

If User:The Retro Gamer/stuff is only meant to be transcluded onto your main userpage, keep in mind that you cannot do that as per Userspace: "The following uses are NOT allowed, and will be deleted if created: [..] Pages that are just meant to be transcluded onto another page (I.e. a status update that only goes on one page, a subpage that just contains the userbox tower, or some other component of the user page : just put the content on the page directly. If you find that it makes your user page too cluttered, consider lessening the amount of content.)" I know it may seem like I'm being very nitpicky about this stuff, but I'm just trying to help you learn your way around how we do things here. The template can be kept if it's meant to be somewhere else as well, but it seems more like a main userpage kind of thing. Same thing with your User:The Retro Gamer/working, User:The Retro Gamer/links, and User:The Retro Gamer/done pages. They don't need to be separate. 15:51, 27 April 2018 (EDT)
 * What Alex95 said. 16:42, 27 April 2018 (EDT)

Music names in tables
Docky here! Given that this page is just a click away, then I'd say no, removing them would be detrimental. Doc von Schmeltwick (talk) 03:01, 25 April 2018 (EDT)
 * The music consistently corresponds with very specific level types, I think that's important to note... Doc von Schmeltwick (talk) 10:08, 25 April 2018 (EDT)

RE: DKC levels table
I'm going to have to register a strong, strong "no" to the colouring. I spent ages (starting with DKR and moving onto DKC) recolouring the tables specifically to *REMOVE* random colouring like that.

Widths, you have to remember that (a) it's not the only table on the page, they need to be consistent with each other - if they're all random widths and/or colours it's going to look bad and (b) not everyone's looking at things on a desktop browser. Frankly, I think the way you've done the tables as templates is fairly silly - everything else on the pages are still wikicode tables, there's not much of a gain in reducing complexity, and you're having to dump raw HTML into the page over wikicode. If you're going to try something like that, you need to look into (a) making the entire table ONE template, not one template per row and (b) switching from  s to a more responsive design style to justify it - there's nowhere near enough of a gain as it stands,. - Reboot (talk) 18:57, 25 April 2018 (EDT)

Having had a proper look at and, yeah, this is absolutely a backward step. These need to go. They're overcomplication for the sake of overcomplication - you're even having to manually specify all the row colours again?! - Reboot (talk) 19:06, 25 April 2018 (EDT)

Okay, proof of concept putting the whole table in one template, avoiding having to have any raw table code, or multiply specifying the same variable. (Insofar as the users are concerned, at least, since meta-templates are used. And no, it doesn't hit all the beats I mentioned above. Like I said, proof of concept knocked up in an hour. For a "real" one, even if I stuck with tables, I'd be hiding unused rows/worlds with s and so forth): User:Reboot/LevelTable - Reboot (talk) 20:06, 25 April 2018 (EDT)

Docky here, having all those colors, regardless of color coordination, just looks really unprofessional, and almost painful to be honest. It can be input through text alone just fine. Besides, some areas of the same type have different palettes, notably the underwater ones. Doc von Schmeltwick (talk) 01:51, 26 April 2018 (EDT)
 * Yeah, there is variance in some levels; I tried to pick a generally representative color scheme, but sometimes it's just the idea of the terrain in a cohesive sense that's important to convey. I disagree that "having all those colors, regardless of color coordination, just looks really unprofessional, and almost painful to be honest", but my taste may be different from the rest of the wiki, in which case I will obviously not implement it. --The   Retro   Gamer  01:57, 26 April 2018 (EDT)
 * When you have me & Doc agreeing, you know you've gone wrong :p - Reboot (talk) 01:58, 26 April 2018 (EDT)

RE:Music themes column in DKC levels table
Hey there! I understand your point - since each terrain type is associated with its own musical track, it seems redundant to list both of them separately like that. That's not entirely true, however: for instance, despite being respectively set in mine and walkway areas, the minecart levels do not play their respective soundtrack, instead opting for a specific music. Same goes for the toboggan levels in DKC3. These exceptions alone make the listing of both columns necessary, in my opinion. But a viable solution would be the one you presented me, in which you make a distinct table that does just that. However, this would be inconsistent with DKCR and DKCTF, which don't really have fully designated terrain types and the music may repeat in multiple unrelated levels. -- 15:44, 26 April 2018 (EDT)