Editing User talk:A gossip-loving Toad

 '''STATUS''': see [[User:A gossip-loving Toad|user page]].

*[[User talk:A gossip-loving Toad/Archive 1|Archive 1]]

== GIFs ==

I noticed you uploaded a new version of [[:File:PMHerringway.gif]]. Generally, it would be a waste of your time continuing to resize and crop those kinds of GIFs as I just replaced it with [[:File:PM Herringway.png]]. I know I can do this easily compared to screenshot taking but there are many single frame GIFs in [[:Category:Paper Mario Images]] that should be replaced with PNG counterparts. That would be tedious to perform for right now. Don't convert the GIF to PNG. GIFs have a limited color palette and are not favorable for static images. Animated is OK. There are hundreds of sprite sheets [http://www.spriters-resource.com/nintendo_64/pm here] (I used it for [[Herringway]]). It isn't as high of a priority as the terrible screenshots that need replacing because the GIF sprites are OK in quality for now. --{{User:Wildgoosespeeder/sig}} 03:48, 28 August 2016 (EDT)

== Re: some screenshot-related questions ==

Hi there, gossip-toad! I'll do my best to answer your questions.

<blockquote>
Wildgoosespeeder mentioned that the some of the screenshots on [[List of Star Pieces in Paper Mario]] had issues due to conversion from JPEG and GIF to PNG. Would it be worthwhile to retake them? I'm not sure if it's good to bloat up the file histories for little quality improvement.
</blockquote>

If we've got the resources and ability to re-take those screenshots, then I would encourage doing so. Most screenshots on that list page are visibly low in quality, with a lot of JPG compression artefacts. Compare the same {{plain link|1=[http://www.mariowiki.com/images/archive/5/5b/20160417061741%21PM_Star_Piece_KoopaVillageBrick.png JPG]}} and {{plain link|1=[http://www.mariowiki.com/images/5/5b/PM_Star_Piece_KoopaVillageBrick.png PNG]}} screenshot. The latter is definitely sharper, clearer and more ideal. And don't worry about bloating up the file histories: the properly captured PNG version appear to have a [[:File:PM Star Piece KoopaVillageBrick.png|much lower file size]] compared to the JPG. So recapturing the images would also be good for the page's loading time.

Additionally a captured PNG is definitely preferred over a GIF, due to the limited color palette as Wildgoosespeeder said in the section above. The colors of a GIF Nintendo 64 screenshot wouldn't be accurate to the actual game.

<blockquote>
If a 640x480 ''Paper Mario'' screenshot is of higher quality than a 320x240 one, is it OK to upload a 640x480 one (if it does not break page consistency)?
</blockquote>

Still using the "List of Star Pieces" page as an example, I'd prefer to see all images used on such page having the same resolution (especially because they all appear sharp and clear at the current lower resolution on that page). But certainly, if a higher resolution screenshot for a home console doesn't break page consistency (such as a screenshot on a character page, rather than a list page), then feel free to upload it.

<blockquote>
A lot of ''Paper Mario'' screenshots have been uploaded to the wiki and some of them, if compared with the hardware output of the same scene, lack the black borders present in the latter. The problem is that it's not sure if they have been cropped, since many uploaders just state the game name in the source parameter without mentioning where they got their screenshots. (I would guess emulators for most of them, though.) Is there anything that needs to be done to existing screenshots that are borderless in this sense?
</blockquote>

If the actual hardware output shows black borders, then screenshots without them must have been edited in some way before being uploaded. I understand that if people don't state it themselves, we may not be sure exactly how they have modified the screenshots. So rather than adding specific information in aboutfile on the file being cropped (as you would if you cropped it yourself), when the original uploader has not specified it, I think it's still worth stating in a more general way: ''"The black borders shown in the original hardware output are not shown"'' &ndash; Something more general and broad would be acceptable, rather than assuming that they've cropped them out. 

I hope I have clearly and adequately answered your questions.

{{User:YoshiKong/sig}} 07:37, 26 September 2016 (EDT)

== RE: Super Mario 64 HD ==

Probably Glide64 or some variant of it. I have seen settings that go to 960x720 or 1440x1080. Just be sure to set filtering correctly like my screenshot WIP says. --{{User:Wildgoosespeeder/sig}} 14:30, 2 October 2016 (EDT)

== Re: about maps ==

Hey there. The WIP is focusing more on ''published'' game guides, such scans coming from [[Prima Games]]. The game maps found around the internet (including those that Peardian makes), are acceptable to upload. Although the original artist should be credited, and preferably with permission.

{{User:YoshiKong/sig}} 09:29, 4 October 2016 (EDT)

<blockquote>
Oh sorry, I overlooked the header. Well which license tag should these two maps have? They are currently tagged {{tem|game-screenshot}} but the viewport got more drastically stretched than [[:File:PMTTYD Rogueport Inn.png]]...
</blockquote>
No worries! And I think they should still maintain the screenshot license. Because unlike a game-sprite, the images still use the background assets/character sprites layed as they would appear in a regular game screenshot.

<blockquote>
By the way, I'm not sure where to report this but [[The 'Shroom:Issue 112/Pipe Plaza#The 'Shroom Report]] refers to the late Walkazo's brother as <code>{<nowiki/>{User|Pantaro}}</code>. He's called {{user|Pantaro Paratroopa}} on this wiki so these are actually red links in disguise. 
</blockquote>
Thanks for picking that up, it's been fixed.

<blockquote>
While we're at it, there are also these PMTTYD screenshots that have the black borders removed. In contrast with the black borders in ''[[Paper Mario]]'''s which are hardly-noticeable on real console, the black borders in ''[[Paper Mario: The Thousand-Year Door]]'' are part of the cutscene effect and thus part of the "content". Cropping them out results in images that look like this (awfully "bald" in my opinion):
</blockquote>
I don't think edits such as [[:File:Koops and Kolorado's Father.png|that]] should be done when a game element overlaps a black border. I understand the benefit in cropping black bars which are just taking up space, such as [[:File:PM Outta Sight screenshot.png|this one]], but I would not see any use in having to crop/make areas transparent in [[:File:WL4-White Cat.PNG|this ''Wario Land 4'' screenshot]], for example. The white newspaper is intended to sit in front of a black border (same with dialogue boxes in the ''Paper Mario'' games). White newspapers and dialogue boxes aren't meant to be given a transparent surrounding, and wouldn't look ideal when placed on an article's white background. I would be perfectly okay with allowing the black bars to remain when an element overlaps it. But that would require a [[MarioWiki:Image use policy|change to the rules]].

{{User:YoshiKong/sig}} 11:15, 4 October 2016 (EDT)

== Screenshot->Sprites ==

Hi, I noticed you were fixing sprite images mistagged as screenshots. There's a few in the Super Mario Maker category...
<gallery heights="32" widths="32">
Chibi Robo.png
Diddy KongSMM.png
FalcoSMM.png
Foreman SpikeSMM.png
Ganondorf Super Mario Maker.png
Inkling Girl Super Mario Maker.png
JumpmanSMM.png
Kicks Super Mario Maker.png
Little MacSMM.png
LucasSMM.png
Mahjong Super Mario Maker.png
Mario (GLA) - SMM.png
Mega Man Super Mario Maker.png
Meta KnightSMM.png
Mr GameWatchSMM.png
Nikki.png
Pac-Man Super Mario Maker.png
Peppy Super Mario Maker.png
Pit Updated Super Mario Maker.png
RobinSMM.png
Samus SMM.png
ShellcreeperSMM.png
ShulkSMM.png
ShyGuySMM.png
SideStepper.png
SMM Blathers.png
SMM Bowser.png
SMM Captain Olimar.png
SMM Celeste.png
SMM CptFalcon.png
SMM Cyrus.png
SMM Dark Pit.png
SMM Digby.png
SMM Donkey Kong Jr Sprite.png
SMM Donkey Kong.png
SMM Dr Lobe.png
SMM Dr Mario.png
SMM Duck Hunt.png
SMM Greninja.png
SMM Ike.png
SMM Inkling Boy.png
SMM IsabelleWinter.png
SMM Jigglypuff.png
SMM Kapp'n.png
SMM King Dedede.png
SMM Kirby.png
SMM KK.png
SMM Link.png
SMM Lottie.png
SMM Lucario.png
SMM Lucina.png
SMM Luigi Costume.png
SMM Mabel.png
SMM Mario Kart.png
SMM Mary O.png
SMM Mega Yarn Yoshi.png
SMM Mewtwo.png
SMM Palutena.png
SMM Pikachu.png
SMM Pink Yarn Yoshi.png
SMM Reese.png
SMM Resetti.png
SMM Rosalina.png
SMM Rover.png
SMM Sheik.png
SMM Slippy.png
SMM Squid.png
SMM Statue Mario.png
SMM Timmy & Tommy Nook.png
SMM Tingle.png
SMM Toad Costume.png
SMM Villager.png
SMM Wii Fit Trainer.png
SMM Woolly Yoshi.png
SMM-SMB-Luigi.png
Super Mario Maker Ashley.png
Super Mario Maker Toon Link.png
Tom NookSMM.png
ZeldaSMM.png
</gallery>
- [[User:Reboot|Reboot]] ([[User talk:Reboot|talk]]) 16:55, 4 October 2016 (EDT)

== Rogueport ==

I actually have [[MarioWiki:Proposals#Create_or_delete_categories_about_an_area.27s_citizens|a proposal that aims to delete said category]], so... {{User:Time Turner/sig}} 20:32, 6 October 2016 (EDT)

== Re: citation ==

Hi there. I believe that North Americans structure the dates as MM/DD/YY, whereas us Australians arrange it as DD/MM/YY. According to [https://twitter.com/jdaster64 jdaster64's Twitter account], he is from New York, and would therefore likely use the North American way to arrannge the date. So I'd use April 7, 2016 to reference those particular statistics.

{{User:YoshiKong/sig}} 16:08, 10 October 2016 (EDT)

<blockquote>
By the way, would edits like [http://www.mariowiki.com/index.php?title=Dizzy_Dial&curid=5532&diff=2073299&oldid=2073293 this] be appropriate when citing a document that says "Please do not redistribute/reuse the contents of this guide anywhere without my consent and due credit"? I'd also like to know that document is considered trustworthy. It seems to be something between [http://www.romhacking.net/documents/680/ primary sources] and [http://themushroomkingdom.net/pmttyd_j2e.shtml#areas secondary sources]... —{{User:A gossip-loving Toad/sig}}  10:44, 11 October 2016 (EDT)
</blockquote>

:Normally when there is an explicit disclaimer against redistributing the content without permission, we would make some effort to seek consent from the author or person who derived a set of statistics like that. However in this case, I think it's reasonable to use the information (although still with due credit). It's not as though you copied/pasted his exact work for use and commentary: it seems to me that you've interpreted the statistics that he has provided (correct me if I am wrong). And regarding the dependability of these statistics, I personally think jdaster64's reputation on providing such statistics is enough to provide a fairly confident reference. However, if you weren't sure about the reliability of any calculated statistics from a particular source, you could still use it for the time-being if there is no other information currently available to compare it to. It would be preferred that such information have {{tem|better source}} attached.

:I hope this helps ya. &ndash; [[User talk:YoshiKong]] 18:11, 12 October 2016 (EDT)

== Re: Bowser's Inside Story  ==

Thanks for the message also, It's completely random as to whether the enemies drop items. the [[Shroobs]] sometimes drop [[Shroob Boots]] but I rarely get them for some reason (lol). Yes the bosses do drop the same set of items a perfect example would be [[Midbus]] drops [[Fiery Drumsticks]] and regarding the question about unskippable enemies, yeah they drop the same items as any of the regular optional counterparts eg. The [[Fawflant]]s still drop [[Supersyrup Jar]]s and so on, I hope this helps. Oh and nice to see you again too. :) {{User:The RPG Gamer/sig}} 01:53, 14 October 2016 (EDT)
:Yes, if they appear in the menu then yes they are key items. {{User:The RPG Gamer/sig}} 21:49, 15 October 2016 (EDT)

== BIS ==

First of all, do the keys even have articles? Considering that they're collected and used by the player, they should receive articles before worrying about whether or not they're on lists. {{User:Time Turner/sig}} 23:23, 15 October 2016 (EDT)

== RE: MLBIS maps ==

I'm pretty sure the game doesn't distinguish between the areas, aside from the obvious fact that you reach the second floor after you go up the stairs in the first floor. The names are not official, I corrected the styling of them, thanks for noticing that :)--{{User:Megadardery/sig}} 14:48, 17 October 2016 (EDT)

== Re: categorization ==

Hi. I think the game subcategories that you mentioned would be a good thing. I generally consider "special items" as those which have an influence with the game's story or interact with the actual RPG world, whereas "Items" are those which are used immediately in battle, and may be kept in large numbers within an inventory. "[[Green Key]]" and similar objects would best fit within "special items". Hope this helps.

{{User:YoshiKong/sig}} 11:16, 18 October 2016 (EDT)

== Re: about the image category reminder stuff ==

I really like that idea: it would be a good way to help users remember. I suggest that you bring it up with {{user|Porplemontage}}, as changes to the MediaWiki interface are ultimately up to him.

{{User:YoshiKong/sig}} 12:36, 23 October 2016 (EDT)

== RE: trying angrylion ==

If an emulator uses the same plug-in spec as Project64, the plug-in is likely compatible, but I wouldn't recommend using emulators other than Project64 or Mupen64Plus (or variations that use those cores, such as BizHawk using Mupen64Plus and Glide64) because their cores are highly outdated and inaccurate (four plug-in types; graphics, sound, RSP, and input). [http://emulation.gametechwiki.com/index.php/Nintendo_64_emulators#Emulators Emulators] and [http://emulation.gametechwiki.com/index.php/Recommended_N64_Plugins plug-ins]. In general, emulators that are closed source tend to lack high level development than open source emulators. Project64 is the most developed but has a major con of being closed source and behind the times due to a donation paywall during 1.7 phase when 1.6 was the most commonly used version. That's not the case anymore since its 2.0 release and 2.1, 2.2, and 2.3 following soon after. This is as good as it gets for now. Recently, Project64 had its code put on GitHub by its authors so hopefully there are much more rapid and active development to get Project64 caught up with standard emulator features. --{{User:Wildgoosespeeder/sig}} 14:38, 8 November 2016 (EST)
:How fast is angrylion allowing ''[[Paper Mario]]'' to run? In general, the devs have stated that it is processor intensive to be as accurate as possible with N64 graphics so it runs between 1/3 to 2/3 the speed of its normal frame rate for me. --{{User:Wildgoosespeeder/sig}} 20:14, 8 November 2016 (EST)
::Then you must be using a more powerful build than me if FPS isn't phasing you like it is me using angrylion. Glide64 doesn't slowdown for me though. --{{User:Wildgoosespeeder/sig}} 23:04, 8 November 2016 (EST)

== Re: placement of categories on file description pages ==

I don't think it matters as much where the code is, as long as the image is categorized. It's not like the main articles where they are at the bottom and formalized. I put them there tough if I have the chance though. --{{User:Wildgoosespeeder/sig}} 23:17, 22 November 2016 (EST)

== Re: MLBIS screenshots ==

I can only do so much screenshot replacement with ''[[Mario & Luigi: Bowser's Inside Story]]''. Beginning and end is all I can do with the use of saves from GameFAQs. I haven't played the game at all so I have no clue how to trigger certain events to replace those terrible screenshots. Also RPGs are very tricky because of their linear, scripted, and mostly only once-event-trigger nature. --{{User:Wildgoosespeeder/sig}} 00:17, 23 November 2016 (EST)

== Paper Mario Replacements ==
Heh, now that you are trying out angrylion and you are in [[Flower Fields]], maybe you can replace images involving [[List of Paper Mario glitches#Herringway Glitch|this glitch]], specifically [[:File:HerringwayGlitch.png]]. Who knows? Maybe angrylion will render exactly like the N64 when the glitch is triggered. --{{User:Wildgoosespeeder/sig}} 16:59, 23 November 2016 (EST)
:I don't think the hex numbers really matter all that much. Probably a few variable values differed from the older version of the screenshot relating to coin count, Mario's ''x,y,z'' coord, etc.. As long as the debug screen is visible and what is behind the debug screen match the old screen. I bet that it is awesome to other users to see the image finally get a good replacement after 6 years being tagged with {{tem|image-quality}} (checked the edit history)! --{{User:Wildgoosespeeder/sig}} 14:28, 24 November 2016 (EST)
::I had a feeling that angrylion would render it correctly. When I was replacing images for [[List of Paper Mario pre-release and unused content#Debug Rooms]] (using Glide64), I accidentally randomly triggered the debug screen and I noticed it was rendering improperly compared to [[:File:HerringwayGlitch.png]]. Real hardware [[Paper Mario]] doesn't play nice with Gameshark sometimes so those accidental triggers are still accurate to emulated execution but the rendering of Glide64 is still wrong. Months later, I was replacing a bunch of images from the start, up until [[Boo's Mansion]] using angrylion. One image was skipped at the time and I couldn't backtrack ([[:File:Pm btl 01.png]]), so I cheated to skip right to [[Buzzar]] still being active in a new save file. This too triggered the debug screen randomly as I was trying to teleport myself to the battle. Huzzah! The rendering of the debug screen was correct in emulation! But one problem remained and that was playing up until chapter 7. At the time, I got discouraged with the whole black borders talk with {{user|Porplemontage}} (which was since resolved with the current compromise we see today) so replacing the glitch image was put off until further notice. Thanks for getting it finally! There are more replacements that can be done, such as [[:File:KoloradoTreasure.png]] and [[:File:Hammer.jpg]], but those should be easier. --{{User:Wildgoosespeeder/sig}} 17:08, 24 November 2016 (EST)
:::Upload it anyways. That might be what real hardware produces anyways. Real N64 can sometimes have graphical quirks when running. Doing proper 3D graphics in a game engine might have still been a challenge back then compared to the next gen. --{{User:Wildgoosespeeder/sig}} 23:19, 24 November 2016 (EST)
::::[[:File:KoloradoTreasure.png]] Looks fine to me (except for that dialog bubble issue, which isn't a big deal). The bigger deal wrong with the image was blurry/smudgy and JPEG artifacts before your upload. Now everything is as sharp as can be. Good job. --{{User:Wildgoosespeeder/sig}} 05:08, 25 November 2016 (EST)
:::::When you get to Bowser's Castle, replace [[:File:Koopa Bros. in Bowser Castle.jpg]]. --{{User:Wildgoosespeeder/sig}} 19:47, 25 November 2016 (EST)
::::::The quality of [[:File:KoloradoTreasure.png]] is fine now or at least we can be sure it was captured cleanly thanks to your efforts. Don't let your eyes play tricks on you. If I did that, I would think a few images for ''[[Yoshi's New Island]]'' would be worse than the previous upload, like [[:File:Egg Island.png]] for example. Trust the plug-in. The older version of that image had some blur, filters (against [[MarioWiki:Image use policy|policy]]), and wasn't sized correctly (even the cropped 320x237 image would be 592x408 if enlarged). Now the file is lower in file size and is as sharp as can be minimally. --{{User:Wildgoosespeeder/sig}} 15:29, 27 November 2016 (EST)
:::::::I think you are reading too much into it. I wouldn't waste your time thinking about screenshots in that regard. Pixel accuracy really refers to how accurate an emulator is able to replicate the hardware on the visual side of things minus any analog conversions to make it compatible with those old CRT TVs or new TVs with backwards compatibility for that standard. Also removing that conversion means a clean image output that is easily compressible. For example, an uncompressed 256x224 screenshot of an NES game would be 172032 bytes. I have seen it go down as low as 5120 bytes on average. That's ~97% compression efficiency when it is uploaded! That's really something if screenshots are captured as clean as possible. That Paper Mario screenshot you submitted has a compression efficiency of ~87%. That's pretty good for people with slow or metered internet connections. --{{User:Wildgoosespeeder/sig}} 02:07, 28 November 2016 (EST)

== PM2 Title Screen Test ==
[[File:PMTTYD Title.png|thumb|right|Dolphin under ''software rendering''. Click the picture to see file history for my thoughts.]]
I think the internal resolution for ''[[Paper Mario 2]]'' is 608x480. Instead of using OpenGL or DirectX as a backend, I selected ''software renderer'' (savestating before switching backends because software rendering is VERY SLOW). The title screen to the right is a test. --{{User:Wildgoosespeeder/sig}} 00:27, 3 December 2016 (EST)
:The whole screenshot thing with Dolphin is screwed up anyways. The images you have uploaded now should be sufficient. Not worth the time redoing them again. --{{User:Wildgoosespeeder/sig}} 00:34, 3 December 2016 (EST)
::[[User talk:A gossip-loving Toad/Archive 1#PPTTYD Screenshots|I was wrong about 640x528]]. I took the 608x480 to the right to have a width of 640px (keeping it to scale). Then I center cropped to be 640x480. Tested the title screen on real hardware and the image I resized matches pretty closely to what real hardware does, at least for me. That part of the mystery is solved. I wonder why Nintendo did that? The image can already fit in 640x480 with [[Wikipedia:Composite video|composite video]] at the time... --{{User:Wildgoosespeeder/sig}} 03:01, 3 December 2016 (EST)
{{br}}

== Superstar Saga bestiary ==

I finished the first of the bestiaries, [[Paper Mario: Sticker Star bestiary|Sticker Star]]. I wanted to know if you wanted to do one of the bestiaries?--{{User:Eldritchdraaks/sig}} 00:34, 3 December 2016 (EST)

:Here's the template you'll need: [[template:MLbestiary]]
:Everything should be self explanatory since it's almost no different from placing the enemy boxes. But, I do have a few pointers:
*Whatever you put next to <code>|altname=</code> needs to be exactly what you replace <code>NAME</code> with. However, no two enemies on the page can have the same <code>NAME</code>.
**Don't worry about setting up the link. By default, <code>|name=</code> is used to link the Enemy's name to it's article. If you get to an enemy that uses extra text like <code>Bowser (2)</code>, use <code>|altname=</code> To display it that way. The link is setup link this <code><nowiki>[[name|altname]]</nowiki></code>.
*Please don't alter the code of the template.
*Oh, and for the <code>|role=</code>, this is the replacement method for using Bold, Italic, Bold and Italic, and Bold First Letter to indicate what kind of enemy it is. 
**Use these: <code>common, miniboss, boss, support, optional</code>
*Finally, don't change <code><nowiki>|align={{{align|right}}}</nowiki></code> because this is the way to change the alignment of the enemybox.
:If you want to replace the enemybox on every page, replace them with this 
<pre><nowiki>
{{:Mario & Luigi: Superstar Saga bestiary|transcludesection=NAME
|align=
}}</nowiki></pre>
:If you have any questions, feel free to talk to me. Other than that, Good luck!
:--{{User:Eldritchdraaks/sig}} 01:13, 3 December 2016 (EST)

== Excel for bestiary? ==

What's this I'm hearing about using excel on the PiT bestiary?--{{User:Eldritchdraaks/sig}} 15:38, 8 December 2016 (EST)
:If that method allows you to quickly convert the bestiaries, you can go ahead and do the rest of them.--{{User:Eldritchdraaks/sig}} 15:44, 8 December 2016 (EST)
::Okay, go ahead and convert [[Super Mario RPG: Legend of the Seven Stars bestiary|Super Mario RPG]] and [[Mario & Luigi: Dream Team bestiary|M&L: Dream Team]]. Everything else is already being worked on by other users and I'd need to talk to them first. Also, starting numbering each enemy as you go down the list. Ex: <code>|#=1</code>, <code>|#=2</code>, <code>|#=3</code> etc.--{{User:Eldritchdraaks/sig}} 19:21, 8 December 2016 (EST)
:::Originally I gave the [[Super Paper Mario bestiary]] to [[User:Ultimate Mr. L]] to do, but recently he informed me he's been busy. So, since you've got the speedy method, I'm giving this to you too. [[User_talk:Ultimate_Mr._L#Super_Paper_Mario_bestiary_2|here]]'s all the info I gave him at the time. Hope you're up for it.--{{User:Eldritchdraaks/sig}} 00:14, 18 December 2016 (EST)
:::I forgot I also asked you about doing Dream Team.--{{User:Eldritchdraaks/sig}} 00:19, 18 December 2016 (EST)
:What's up with the background edit to the Dream Team bestiary template?--{{User:Eldritchdraaks/sig}} 00:04, 27 December 2016 (EST)
::There are only two bestiaries left to convert: Super Paper Mario and Bowser's Inside Story. The later is being worked on by someone else but I need you to do this last one for me, The SPM bestiary.--{{User:Eldritchdraaks/sig}} 20:16, 7 January 2017 (EST)

== RE: Deleting Bestiary Leftovers ==

I have to no problem in my opinion, but you should ask {{User|Eldritchdraaks}}?
{{User:L151/sig}}
:Is this about the gifs? I fully support using the gifs in the bestiary, but if there's a strong opposition they could just show up in the enemy boxes. Speaking of which, I'll need to move the enemy box templates so they share the same naming format.--{{User:Eldritchdraaks/sig}} 11:16, 9 December 2016 (EST)

== RE: image category ==

I'm going to say yes, but there isn't a category for it yet. Many pictures like that one need a category. [[:Category:Photos]] ({{tem|photo}}) needs to be gone through amongst other [[Help:License|copyright tags]]. Question is, what category should be created for pictures of people? I would ask {{user|Porplemontage}} for advice (or even ask him to remove the <code><nowiki>[[Category:Photos]]</nowiki></code> code temporarily to force affected images into [[Special:UncategorizedFiles]], like it was done several months ago with sprites and screenshots). --{{User:Wildgoosespeeder/sig}} 16:56, 15 December 2016 (EST)

== Replace Images ==

I just noticed [[User:A gossip-loving Toad/Sandbox]]. Word of advice. Make sure to use ''SoftRasterizer'' instead of ''OpenGL'' for 3D settings because I noticed that the map layer (environment) below the sprite layer (Bowser, Mario, etc.) is not rendered correctly for BIS. You can see the difference: [[:File:MandLBISss4.png]] --{{User:Wildgoosespeeder/sig}} 00:54, 18 December 2016 (EST)
:I don't have any set way to detect those kinds of images (JPEG to PNG). It gets harder with more complex screenshots. My best advice is to be on the lookout for files around 50KB or more for sprite-based screenshots, especially if the image is 256x192. Any screenshot that isn't 256x192 (or stacks the two screens to produce numbers 256, 192, or 384) needs to be redone anyways. If you really have doubts, you could do some intense analysis of the image or just screenshot anyways. Very rarely do I produce near-similar results as the upload I suspected was JPEG to PNG. --{{User:Wildgoosespeeder/sig}} 04:50, 18 December 2016 (EST)
::You are doing great work for MLBiS. Keep it up! --{{User:Wildgoosespeeder/sig}} 16:45, 29 December 2016 (EST)
:::A quick Google search brought up [https://www.youtube.com/watch?v=Eo6o0KUhZ04 this]. If that doesn't work, [https://www.google.com/search?q=desmume+fawful+express here is my search query]. --{{User:Wildgoosespeeder/sig}} 22:24, 29 December 2016 (EST)
::::Download [http://www.mediafire.com/?teowvwr2h2y3nvc this file] and use it as the audio sample for mic control for DeSmuME. --{{User:Wildgoosespeeder/sig}} 00:00, 30 December 2016 (EST)
:::::Turning off 3D makes [[Baby Mario]] disappear. SoftRasterizer is buggy in this case. I found out that OpenGL works better. 3D is harder to emulate accurately. Real hardware doesn't do this. A sprite using 3D transformations can distort the sprite a little bit, like ''[[Paper Mario]]''. As for '''TXT hack''', this could be similar to [[Bulbapedia:Pokémon Colosseum|Pokémon Colosseum]] and changing the '''texture cache accuracy''' in Dolphin to make the text render properly. --{{User:Wildgoosespeeder/sig}} 01:26, 30 December 2016 (EST)

== Bean spots ==

Hey, great job on that! The page is looking good so far.

{{User:Shokora/sig}} 03:33, 31 December 2016 (EST)

== RE:MLBIS Key Items ==

Along with adding in the missing item description, I just simply italicized what was already there. If it wasn't the actual in-game description, that would be the fault of another user(s). I have the US version myself, but I didn't check the description of the other items to see if they were correct, mainly because I didn't have all of the key items myself at the moment. Apologies for the mistake. 

(Additionally, I missed italicizing the first item on that list :P) {{User:Alex95/sig}} 22:03, 3 January 2017 (EST)

== Re:Image Replacement ==

Alright, thanks. I'll get right on that. {{User:Tails777/sig}}


==re: Weird question==

I know this is a rather strange and random questions, but considering your sporadic addition of Japanese names and thel ike, I wonder if you know if there's anywhere I could get a Japanese text dump of Paper Mario TTYD? More specifically, I only need the final RDM issue. --[[User:Glowsquid|Glowsquid]] ([[User talk:Glowsquid|talk]]) 23:55, 6 January 2017 (EST)
: Hmm. That's unfortunate. <br> Do you know if Rew's text dump include other language beside English and Italian. I found it, but whem I try to open it, it crash Firefox! --[[User:Glowsquid|Glowsquid]] ([[User talk:Glowsquid|talk]]) 09:44, 7 January 2017 (EST)
::Omg, that's exactly what I wanted! <br> Well, to be exact, before you upload the image, can you tell me if there's an extra section if you scroll down to the bottom for a bit? --[[User:Glowsquid|Glowsquid]] ([[User talk:Glowsquid|talk]]) 11:12, 7 January 2017 (EST)


'''Amazing'''! This is super helpful to me: I got wind about the extra section from the folk at the Italian wiki, but I wanted confirmation it was in the Japanese script before writing something on the wiki's twitter feed about it. Thank you so much. --[[User:Glowsquid|Glowsquid]] ([[User talk:Glowsquid|talk]]) 11:43, 7 January 2017 (EST)

== ''Partners in Time'' screenshot ==

I saw that you uploaded {{file link|MLPiT Petey Piranha battle.png}}, however it looks like part of Luigi's cap is cut off. Was this an emulator glitch?

{{User:Shokora/sig}} 04:51, 12 January 2017 (EST)

:No worries. The [[:File:Petey partners in time battle.jpg|JPG]] hasn't been deleted yet, but I'd suggest just keeping your version on the wiki until you're able to recapture it: that would save the trouble of going back and updating the links again.

:{{User:Shokora/sig}} 05:22, 12 January 2017 (EST)

Just like Dolphin Emulator, there isn't a set and forget solution to what is the best settings to use. DeSmuME, 0.9.12 is in the works that could have fixed the slight issue but don't hold your breath for a release. The developers relish in the idea of annoying users by delaying releases and withholding much needed features for the emulator because they had a bad time with the more obnoxious users. So they punish everyone, even if those users are innocent where the minority are the obnoxious ones. They aren't very nice. Two wrongs don't make a right sort of deal.

The detail is so little that the current version of that PNG is better than the JPEG so I think the JPEG is worth deleting. If you really want to test things out, does SoftRasterizer render that part of the image correctly? Maybe you can stitch the two better halves of that screenshot together. I heard some good things about DraStic (iOS and Android DS emulator and $5 to own a copy of the software). --{{User:Wildgoosespeeder/sig}} 21:29, 12 January 2017 (EST)
:Honestly, I don't think many articles exist with files using the <code>Media:</code> prefix. I might be wrong though. I could only verify that [[Nintendo Switch]] and [[Electrodrome]] used it. Use a bot to perform the switches. Use care though! There could be intentional uses of the prefix, such as {{tem|file link}} itself as a demonstration of its limitations. I would make sure to specify a specific namespace with your bot replacements.

:<code>python replace.py -ns:0 -catr:Main -regex '\[\[Media\:(.+)(\|.*)?\]\]' '<nowiki>{{file link|\1\2}}</nowiki>'</code>

:Be sure to test this regex before committing changes. --{{User:Wildgoosespeeder/sig}} 16:02, 15 January 2017 (EST)

== Image To Replace ==

I'm shocked that [[:File:Shrowser M&LPiT sprite.png]] isn't in [[User:{{BASEPAGENAME}}/Sandbox]]! --{{User:Wildgoosespeeder/sig}} 17:59, 18 January 2017 (EST)

== iQue ==

Looks good! Nice work.

{{User:Shokora/sig}} 05:45, 24 January 2017 (EST)

:Sure, a history section would be good. If you're referencing information from that Chinese webpage, I think it's best to include the sentence in its original Chinese as part of the reference (so people can easily compare their own translation if necessary). When an entire section on the wiki can apply to a single reference, what I normally do is use the reference after the first sentence. And then at the end of each paragraph thereafter. This way, readers don't have to go back to the first part of the section if they wanted to view the reference again. The <nowiki><ref name=></nowiki> code should also be used if the references are exactly the same, so that they are grouped together and not coded as separate references.

:{{User:Shokora/sig}} 16:30, 24 January 2017 (EST)

==iQue-related inquiry==

Yo.

Someone on another site I go to is curious about the iQue, and most specifically, the download links on [http://www.ique.com/products/M_athome.htm this page]. If I'm not too annoying, would you able to tell what the downloads are for? Automatic translations aren't giving anything comprehensible. --[[User:Glowsquid|Glowsquid]] ([[User talk:Glowsquid|talk]]) 22:27, 28 January 2017 (EST)
:Thank you very much! --[[User:Glowsquid|Glowsquid]] ([[User talk:Glowsquid|talk]]) 09:28, 29 January 2017 (EST)

== In-game hypothesis ==

As long as you preface it by saying that the information comes from ''x'', yes. {{User:Time Turner/sig}} 23:01, 3 February 2017 (EST)

== Re: upscaled screenshots ==

Hi there. Sorry about the slight delay in responding to you.

I've seen Wildgoosespeeder lately uploading native resolution Nintendo 64 screenshots, which is perfectly acceptable according to policy. The only issue I see is that smaller parts of the image become much more difficult to see. Compare [http://www.mariowiki.com/images/archive/1/11/20170206043834%21FallOntoTheCagedIsland.png this] with [http://www.mariowiki.com/images/1/11/FallOntoTheCagedIsland.png this] for example. But the same could be said about small game sprites, which we always recommend uploading at the correct resolution. But if you were wanting to zoom in and crop a particular part of the image (like an object or character), high quality upscaling should be absolutely okay.

I'd say that it's not always strictly necessary to convert HD-rendering screenshots to their native hardware resolutions. But it's acceptable to do so.

{{User:Shokora/sig}} 07:59, 8 February 2017 (EST)

:I agree with {{user|Shokora}}. I think I have said somewhere else on this wiki that if you do it to get a {{tem|game-3Drender}} instead of a {{tem|game-screenshot}}, minus HUD elements, that could be a good enough exception to the general rule. At the time, for example, I felt compelled just to leave [[:File:Goomba Village.PNG]] alone compared to the rest of screenshots of [[Goomba Village (place)|Goomba Village]]. Also, I am debating leaving [[:File:SM64 CG Peachscastle.png]] alone as well. Just be sure to avoid common pitfalls as described in [[User:Wildgoosespeeder/sandbox#Glide64 settings to more closely match real N64 hardware internal resolution|my guide]] and [http://emulation.gametechwiki.com/index.php/Nintendo_64_emulators#High-level_vs._low-level_graphics this page] (HL vs. LL graphics and texture filtering). --{{User:Wildgoosespeeder/sig}} 00:17, 9 February 2017 (EST)