Editing User talk:A gossip-loving Toad

<!--For the next few months I will be having military training, adjusting to university life, etc., so might be unable to respond. Also, it's time to archive.-->
 Kowai ne.

*[[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 {{Plainlink|1=[http://www.mariowiki.com/images/archive/5/5b/20160417061741%21PM_Star_Piece_KoopaVillageBrick.png JPG]}} and {{Plainlink|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..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|bettersource}} 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)