User talk:Reboot

/Archive1

Checkpoints

"Checkpoints" currently doesn't have a page, the current link is a redirect to the YTT ones. I was planning on making a page a while back, but forgot to, so if you want to make a full page or disambiguation page, you probably ought to. A full page would probably be best, due to some games (like Galaxy and Super Mario Bros. Deluxe) having non-physical checkpoints. Doc von Schmeltwick (talk) 19:25, 17 March 2018 (EDT)

Re:Skull

Still though, game identifiers should only be used for when two different things have the same role and name between games anyway, like multiple enemies named "Bat" with no other defining characteristics. Anyways, "save point" might be a better name, or "skull (save point)." Doc von Schmeltwick (talk) 23:18, 17 March 2018 (EDT)

RE: CMYK

MediaWiki with ImageMagick are having issues with CMYK images. It's a known bug that has been fixed in later versions[1], but Porplemontage (talk) on Discord is saying he can't upgrade right now due to technical limitations, which he hopes to lift by the end of this year. Also, I'm just uploading the images unmodified. Of the JPEGs I have come across that use CMYK, not many can be useful for MarioWiki. I am opening the images in GIMP to make sure the color mode is RGB. If it is CMYK, I convert, which I learned when uploading those high quality Player's Choice boxes. This is usually TIFF images. As for File:DK64-Nintendo Power Pre-Release Logo.jpg, just leave that alone. It's more of a test than anything at this point. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 11:50, 31 March 2018 (EDT)

Reverting NIWA Links

Please stop reverting my edits to equivalent redlinks to other wikis. No one else seems to have an issue with it. See Rumble Pak. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 13:44, 3 April 2018 (EDT)

I did not see that. No need to be condescending over a simple mistake I thought could be considered edit warring. However the wikis want to handle coverage, the signal is dampened, which is why I wanted the link to stay. You know, help out other wikis that don't get as much attention. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 14:03, 3 April 2018 (EDT)

RE: 160px

Let's say someone uploads an image bigger than that. There is nothing preventing the page from embedding the entire image instead of a thumbnailed version, which can cause havoc on the article's layout and infobox. I've also seen this happen on 'Shroom pages. You could argue that a reversion or image update/recapture (if the larger version is found to demonstrate the subject better than the previous image) would take place. The code is preventative measures to ensure the page stays nice in such an event, at least until a better image is uploaded. I've also done this to check and make sure that high quality images are uploaded with my mass replacement projects. If the image appears blurry despite the specified optimal width, it gets replaced. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 11:56, 9 April 2018 (EDT)

Piranha Plant Gallery

Hey, could you make it so all the images you added are at least in release date order? Because they aren't. And why did you remove the YNI one? Doc von Schmeltwick (talk) 18:20, 12 April 2018 (EDT)

But still, why are they so out of order? Captain Rainbow came out before Brawl, let alone BiS and NSMBW, and MvDK:MLM came out before SM3DL. Doc von Schmeltwick (talk) 19:12, 12 April 2018 (EDT)

Colors were wrong

If the colors were wrong on an SMM image initially, why would you replace it with a .jpg, which in principle has more accuracy loss regarding colors? Seeing that happen to raster-style images honestly just kinda hurts my heart as a spriter :T. Doc von Schmeltwick (talk) 22:01, 12 April 2018 (EDT)

Rocky Wrench

Hiya! Since I'm unsure if you're going to view the proposal again, can you please tell me why it's a no-go to have moles derived from turtles, but perfectly fine to have a sea slug derived from a bat? Doc von Schmeltwick (talk) 18:28, 14 April 2018 (EDT)

"Humor"

Please avoid making jokes such as this one, we try to be serious here. Thanks. Doc von Schmeltwick (talk) 18:51, 24 April 2018 (EDT)

DKC levels table

Hey! Since you mentioned you renovated the DKC tables recently, I thought I might consult you on my current planned renovations to the table. They are located in section 2 of my sandbox. Section 1 shows my original plan, but it looks kind of messy, and there's not enough distinction between sections, so section 2 is my revised and currently planned version.

I also have an additional question about levels tables generally: I've noticed that they usually have widths of 99%, making them stretch artificially (about twice as long in DKC's case). Personally, this doesn't make sense: it makes the proportions finicky, and unnecessarily fills space. I've shown an example of what the non-expansive sections would look like in section 3 of my sandbox. --The Retro Gamer 01:04, 25 April 2018 (EDT)

Re: the combination of tagged tables and templates, I can fix the templates so they work with the default wikitable, improving readability (originally, my awareness of how to combine both was limited). I have answers to the other concerns, but I will fix the wikitable/tagging mess first before I continue with delving into some of the other issues. Based on your comments, I think I'll rollback the templates for now (EDIT:' I decided against rolling back for the moment because many simplicity improvements were made when it transitioned to tables (e.g. many, many verbose center stylings); feel free to revert back if you want, but I think it's at least better, if not perfect.), since I've solved some of the issues in the meantime anyway, and I want to improve the formatting before I add templates which may add complexity again, as you point out. --The Retro Gamer 20:47, 25 April 2018 (EDT)

Re:

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.

I think you may have missed what I intended you to preview. After applying the below CSS to your CSS file (User:Reboot/common.css), could you look at my sandbox again? Also, I note that the coloring is not random; very far from it. It's specifically derived from the original game's terrain colors, and was very carefully chosen to be both visually appealing and have high constrast. It communicates useful information: for example, I can clearly see that Kongo Jungle has a lot of jungle levels, and that Chimp Caverns has a lot of underground levels (implied by the names, but still, it's more obvious). It also shows the variety of terrains in an understandable way that goes beyond just listing them in text form.

/* The Retro Gamer testing - Brown DKC table styling */
table.dktable-brown1 {background:#fff;margin:1em 0;border:1pt solid #000;border-collapse:collapse;color:black}
table.dktable-brown1 > tr > th,table.dktable-brown1 > tr > td,table.dktable-brown1 > * > tr > th,table.dktable-brown1 > * > tr > td {border:1px solid #000;padding:0.2em 0.4em}
table.dktable-brown1 > tr > th,table.dktable-brown1 > * > tr > th {font-weight:bold;text-align:center}

/* The Retro Gamer testing - DK tables rows coloring */
table.dktable-brown1-rows {background:#fff;margin:1em 0;border:1pt solid #000;border-collapse:collapse;color:black}
table.dktable-brown1-rows > tr > th, table.dktable-brown1-rows > tr > td, table.dktable-brown1-rows > * > tr > th, table.dktable-brown1-rows > * > tr > td {border:1px solid #000;padding:0.2em 0.4em}
table.dktable-brown1-rows > tr > th, table.dktable-brown1-rows > * > tr > th {font-weight:bold;text-align:center}
table.dktable-brown1-rows > * > tr > th {background: #BB8855}
table.dktable-brown1-rows > * > tr:nth-child(odd) > td {background:#FFF8DC}
table.dktable-brown1-rows > * > tr:nth-child(even) > td {background:wheat}

Having had a proper look at {{DK levels table section}} and {{DK levels table row}}, 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?!

The row colors specification was mostly a consequence of adding the dktable CSS class to it, but I've revised and split the class so it's no longer necessary. More CSS styling may allow the table rows to be colored without any specification, but I'm not sure how to do that currently.

(switching from <table>s to a more responsive design style to justify it - there's nowhere near enough of a gain as it stands

It's no longer necessary in the latest working version.

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... 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 {{#if}}s and so forth): User:Reboot/LevelTable

I really considered implementing it as one template, but decided against it for several reasons:

Because of template coding syntax, coding and maintaining one template is very messy. Those {{#if:}}'s have to keep increasing every time you want to add a world, and every time you want to specify a level, and the parameters have messy names ("w2bonusno2"). From an actual usability perspective, it's much worse because of these names. What's the problem with one template per row? It's very semantically clear: every parameter is named based on its type of value, and there's no messy world/level prefixes. Instead of relying on column positioning, the row templates clearly name what each table cell contains, and templated rows allow things like having to specify less cells because it can automatically figure out the music based on the terrain.

The main advantage of the way I have currently implemented it is that it's very easy to modify the columns now; I only have to edit in two places to add or remove any particular column. It's not "complexity for the sake of complexity"; it allows centralized modification, as opposed to coupled row deletion.

Another option that I would be okay with is getting rid of the row templates but maintaining the section templates. The sections should be centralized, I think. But as I mentioned above, templating the rows has numerous advantages.

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.

Unfortunately, I cannot discuss mobile layout fully currently because the mobile CSS is pending an update, but based on how it looks currently, I suspect it's not affected by the fullwidth 99% (it doesn't appear to affect mobile rendering at all.) I don't necessarily agree that it's "consistent" to clog the whole width with the table, since the other tables are fullwidth because they have prose, but the levels table is pure data. --The Retro Gamer 01:07, 26 April 2018 (EDT)

PEotGMCE images

Excuse me, but did you alter the saturation on this digitally? I don't think that's allowed...cropping is one thing, but this is completely different. Or did you find it at some other source? Doc von Schmeltwick (talk) 13:52, 26 April 2018 (EDT)

I brought this up here initially because I didn't want to do anything particularly rash, but it kinda sat. I suppose one of us should probably ask WildGooseSpeeder about it, since he seems to know more about the image rules than most people on the wiki. Doc von Schmeltwick (talk) 17:16, 14 May 2018 (EDT)

Rocky Wrench on the Super Mario (series) page

Hiya, when I put those down, they weren't necessarily intended to be taken as derivative, but merely as similar, hence the term "relatives." The way that's structured is actually fairly similar to what you had proposed for the main species infoboxes, albeit unintentionally so. I just figured someone new to the series might have seen one of the creatures within any of the rows after playing a bit of any one game in the series, and might want to know more about similar creatures in the series, see? I'm not trying to push any "this derives from this" in this case, just list similar creatures. Doc von Schmeltwick (talk) 22:20, 30 April 2018 (EDT)

Shroom

You can leave a message on my talk page if you'd like, so you don't make several talk pages. I'm also watching the recent changes, so I'll fix any 'Shroom links you need. Also, way ahead of you on this one :P 15:42, 14 May 2018 (EDT)

You can probably leave the personal images alone then. Not much point in moving those. 15:47, 14 May 2018 (EDT)