User talk:A gossip-loving Toad

STATUS: Semi-active.


 * 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. -- 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 and  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.

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

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 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 refers to the late Walkazo's brother as. He's called 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.

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... - Reboot (talk) 16:55, 4 October 2016 (EDT)

Rogueport
I actually have a proposal that aims to delete said category, so... 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.

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... — 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 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. :) 01:53, 14 October 2016 (EDT)
 * Yes, if they appear in the menu then yes they are key items. 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. 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.

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, as changes to the MediaWiki interface are ultimately up to him.

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. -- 14:38, 8 November 2016 (EST)