User talk:A gossip-loving Toad

Kowai ne.

• 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 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. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 03:48, 28 August 2016 (EDT)

Re: some screenshot-related questions

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

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.

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 Template:Plainlink and Template:Plainlink 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 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.

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)?

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.

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?

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" – 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.

Shokora (talk · edits) 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. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 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.

Shokora (talk · edits) 09:29, 4 October 2016 (EDT)

Oh sorry, I overlooked the header. Well which license tag should these two maps have? They are currently tagged {{game-screenshot}} but the viewport got more drastically stretched than File:PMTTYD Rogueport Inn.png...

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.

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 {{User|Pantaro}}. He's called Pantaro Paratroopa (talk) on this wiki so these are actually red links in disguise.

Thanks for picking that up, it's been fixed.

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):

I don't think edits such as 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 this one, but I would not see any use in having to crop/make areas transparent in 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 change to the rules.

Shokora (talk · edits) 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...



• Chibi Robo.PNG
• Diddy KongSMM.PNG
• FalcoSMM.PNG
• Foreman SpikeSMM.PNG
• 
• 
• JumpmanSMM.PNG
• 
• Little MacSMM.PNG
• LucasSMM.PNG
• 
• 
• 
• Meta KnightSMM.PNG
• Mr GameWatchSMM.PNG
• Nikki.PNG
• 
• 
• Pit Updated Super Mario Maker.PNG
• RobinSMM.PNG
• Samus SMM.PNG
• ShellcreeperSMM.PNG
• ShulkSMM.PNG
• ShyGuySMM.PNG
• SideStepper.PNG
• 
• 
• 
• 
• 
• 
• 
• 
• SMM Donkey Kong Jr..png
• 
• 
• SMM Dr. Mario.png
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• Tom NookSMM.PNG
• ZeldaSMM.PNG

- Reboot (talk) 16:55, 4 October 2016 (EDT)

Rogueport

I actually have a proposal that aims to delete said category, so... Hello, I'm Time Turner. 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 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.

Shokora (talk · edits) 16:08, 10 October 2016 (EDT)

By the way, would edits like 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 primary sources and secondary sources... —A gossip-loving Toad (Talk) 10:44, 11 October 2016 (EDT)

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 {{bettersource}} attached.

I hope this helps ya. – 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 Fawflants still drop Supersyrup Jars and so on, I hope this helps. Oh and nice to see you again too. :) The RPG Gamer (talk) (edits) 01:53, 14 October 2016 (EDT)

Yes, if they appear in the menu then yes they are key items. The RPG Gamer (talk) (edits) 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. Hello, I'm Time Turner. 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 :)--

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.

Shokora (talk · edits) 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 Porplemontage (talk), as changes to the MediaWiki interface are ultimately up to him.

Shokora (talk · edits) 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). Emulators and 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. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 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. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 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. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 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. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 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. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 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 this glitch, specifically File:HerringwayGlitch.png. Who knows? Maybe angrylion will render exactly like the N64 when the glitch is triggered. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 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 {{image-quality}} (checked the edit history)! --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 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 Porplemontage (talk) (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. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 17:08, 24 November 2016 (EST)