Editing Talk:Glitches in Pikmin 2

==Boulder Glitch==
To Espyo's edit - if it "serves a use," as you say, wouldn't it warrant a move to another section? After all, if it's potentially useful, it's no longer cosmetic; but perhaps such is the case with such a puny use; I didn't get to look through the other cosmetic glitch to see if something similar has happened. -{{User:Los Plagas/sig}}
:Ah, I knew in my mind that I had more to do than just set the danger to "Helpful", but I eventually forgot. Yes, it's no longer cosmetic, and the truth is that it's purely cosmetic for just about every normal player, but not so for split-segment and tool-assisted speedruns. Normally, unless the runner trained the timing and positioning really well, and is lucky with the boulder's placement, it's better to take the gate down normally, because of how hard it is to do the glitch. But in split-segment runs and tool-assisted speedruns, pulling the trick off would be more trivial. So yeah, out of the cosmetic section it goes. — '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 07:07, 19 November 2013 (EST)

==Split==
This page and the ''Pikmin'' glitches page load slowly for me on this laptop. This isn't the laptop I normally use, it's weaker, but it's really noticeable. Everything lags, and the page takes a good 30 seconds to be done loading. Some viewers won't have much of a problem, but others, specially on mobile devices and the like will hate navigating through this interesting list. We have to do something to fix this. We can either split each section into its own subpage, or find another way to show the videos, because I think the main cause of the slowdown comes from all the video metadata requests the page does. — '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 07:19, 19 November 2013 (EST)

:Perhaps a slight difference from the first idea - split all the videos off into a sub-page, and just supply a link to each glitch's video on that page on their section. -{{User:Los Plagas/sig}}

::Yes, we used to have links to the videos, instead of having them embedded, but it's less convenient to click on a link... Also I think either of the two solutions would suffice, no need to combine them. Isn't there a way to only get video information after, say, clicking on a link? We could still have the video on the page, and the user could watch it without leaving or opening a new tab, but it wouldn't load at page load, so less slowdown. — '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 20:20, 19 November 2013 (EST)

:::Could probably fairly easily write a JavaScript thing to do that. <span style="font-family:times;color:#080">'''''[[User:Greenpickle|G]][[User talk:Greenpickle|<span style="color:#050">P</span>]]'''''</span> 17:03, 21 November 2013 (EST)

::::AJAX and the like would probably be involved. ...Good luck. But really, when I asked if there was, it was more along the lines of "I remember seeing some sites that had the videos load only after clicking on something, and their method didn't look like it was a custom-made script". We would just have to search to see if it exists. — '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 06:13, 22 November 2013 (EST)

::::[http://stackoverflow.com/questions/1156794/the-youtube-video-in-my-hidden-div-only-starts-to-load-after-the-div-is-shown This guy] has the opposite problem, but the top reply points out that stuff with the display:none rule isn't even loaded at all, and it's only loaded when the rule changes to something else. So, make a quick script that hides the video from the start, and has a link like "[Show video]" to show it. In fact, don't we have some CSS class or JS function that hides and shows stuff? I'm thinking of some of the navboxes. — '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 08:16, 22 November 2013 (EST)

:::::Well, yes, that was exactly the idea.  The stuff we already have to do that works via a class, so ''display: none'' only happens once the JS has loaded, which probably comes at the end of ''<body>'' (too lazy to check) - so it will get loaded before it's hidden.  To make it start fully hidden, I expect we'd have to write something new.  Also, I guess I was thinking more a placeholder with the same size as the video rather than just a link, to avoid making the content reflow. <span style="font-family:times;color:#080">'''''[[User:Greenpickle|G]][[User talk:Greenpickle|<span style="color:#050">P</span>]]'''''</span> 14:46, 22 November 2013 (EST)

::::::Ah, right right. In fact, I think I envisioned that, but ended up saying a link would be better. — '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 10:00, 23 November 2013 (EST)

==Broken Breadbug Glitch==
I was showing my friend ''Pikmin 2'' this week and she made it to the Glutton's Kitchen. Something odd happened on sublevel 2, the one with the railroad layout. There were two Breadbugs, one carrying the
[[Massive Lid]] and one carrying the [[Imperative Cookie]]. She had Pikmin take both of them back to the research pod, and the Massive Lid one was gaining on the Imperative Cookie one. Both of them got to the research pod at nearly the same time, such that both Breadbugs appeared but not the Massive Lid when the Imperative Cookie was taken first. During the cutscene, the Imperative Cookie Breadbug was sucked up as normal and received its damage, but the Massive Lid Breadbug seemed to be in its regular carrying animation as though no Pikmin were there (probably since Pikmin weren't present in the cutscene). Afterwards, that Breadbug appeared to start dragging the Massive Lid back for one or two seconds, and then the Massive Lid collection cutscene happened. The Massive Lid was outside the ship's ring of light, but it still got beamed into the ship normally; the Breadbug carrying it wasn't there. What happened afterwards was the really glitchy part. The Breadbug that was carrying the Massive Lid seemed to loop its "looking around" animation after it is hurt, but had sustained no damage. It was slowly sliding backwards until a wall stopped it, with no change in direction and with about the speed it would have while carrying something. Once it hit a wall, we hit it with a Purple Pikmin and the trance broke: it went into its hurt animation and received all the damage that the ship would have given it (and not the extra damage from the Purple Pikmin). Then it returned to normal.

I doubt I could repeat this easily; I'd have to line up two Breadbugs to have their treasures absorbed near-simultaneously. But I just wanted to point out that oddity; I don't think Breadbugs were programmed to be in the treasure collection cutscene without having their treasure actually collected. [[User:Scruffy|Scruffy]] ([[User talk:Scruffy|talk]]) 08:49, 12 August 2015 (EDT)

:That's messed up. Hey, when the Pikmin were nearing the research pod, did the treasures overlap? Like, normally, if Pikmin are carrying something, and they bump against other Pikmin carrying something, the two treasures just push each other off (I don't think the Pikmin count for this collision detection process), but because of the "special" way of carrying when a Breadbug has something, collisions might be ignored altogether. That's why I'm asking. If they overlapped (meaning the collision checks really aren't made), then what likely happened was that both treasures got sucked in at once.
:The problem likely came from that in particular, not so much because the second Breadbug was in the cutscene. It should be somewhat easy to test: just get two Breadbugs carrying treasures, and have one treasure be delivered while the second Breadbug is carrying its treasure nearby. You know, just close enough that you can see the second Breadbug on the cutscene of the first treasure. If there's no glitch then, then surely your bug had to happen because the treasures got delivered on the same frame. I'll test it on Snack Pit with Dolphin when I can. &mdash; '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 10:48, 12 August 2015 (EDT)

::Now that you mention it, I'm pretty sure they did overlap. That's not normal at all; thank you for opting to test it.
::Also I keep seeing an oddity in Purple Pikmin that I don't think is a glitch but just an unexplained peculiarity. When you throw them on to any type of Dwarf Bulborb they home in and instantly crush it, like other PIkmin. But often (if not every time) I find that Purple Pikmin latch onto the Bulborb even while it's dying; you can whistle them and they acknowledge the whistle but they don't actually come back until the Dwarf Bulborb is finished with its dying animation. I found this does not happen if another enemy is nearby; the Purple Pikmin will attack that enemy instead. And so far I've only found this to be true with Dwarf Bulborbs and that specific dying animation. Would you call that a glitch or just something unique to Purple Pikmin, perhaps emphasizing their weight? [[User:Scruffy|Scruffy]] ([[User talk:Scruffy|talk]]) 13:10, 12 August 2015 (EDT)

:::Ok, it's on my todo list, but who knows when I'll take care of it. A lot of people already realized that about Purples, but not about how they home in to different enemies instead. I honestly wouldn't know what to call it. It seems deliberate. The Purple stands there and looks at the enemy below it. Does the same happen with other one-hit-ko-from-the-back enemies, like mandiblards? &mdash; '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 14:10, 12 August 2015 (EDT)

== Spicy Bitter rocks ==
User [[User:WhoTheFlower|WhoTheFlower]] added this glitch to the main page, but with no information. Given how insane the glitch is, and how nobody's ever heard of anything similar, and how there's no real way to reproduce it or any documentation, it shouldn't go in the main page. Maybe one day if it gets reproduced, it can be added, but for now, it could well be some hardware problem that caused it. I've moved the glitch from the main page here, so it's still documented anyway. &mdash; '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 17:13, 19 March 2018 (EDT)
{{glitch | reproducibility = Unknown | danger = Very Helpful | p2 = Yes | npcp2 = unknown |
| effects = makes the pikmin start attacking the ground as if there were rocks there, [[nectar]], [[ultra-bitter spray]], and [[ultra-spicy spray]] pop out crazily like with normal rocks but with more than a few.
| howto = Go to [[Awakening Wood]] unknown steps, then go to Hole of heroes, break eggs and walk past the hole pikmin will start breaking rocks that don't exist.
| notes = Did not record this glitch but it did give me a lot of Nectar, USS, and UBS, could be useful in speedruns if it could be reproduced easily.
}}

:Hah! I asked around to see if anybody heard of any similar glitch, and I instantly got told that this was likely just an encounter with the [[Ujadani]]. I completely forgot about them, for a second! &mdash; '''{''[[User:Espyo|Espyo]]''<sup>[[User talk:Espyo|T]]</sup>}''' 17:19, 19 March 2018 (EDT)

== Onion menu/End of day cutscene crash ==

I was playing ''Pikmin 2'' a while back, when, on the third day, I checked the Onion to deposit Pikmin at the same time the screen was fading out to show the cutscene that explained the end of the day. The screen had either just turned or almost turned pitch-black when the Onion menu came up, making the screen fully visible again while I messed with the menu. When I closed the Onion menu, the game crashed. This glitch is probably easily reproduced, but I don't have the means to record proof of it working. My suggested method to reproduce it would be:

-Get to the third day.

-When it nears the time for the "Hurry up!" message before sunset, enter a cave and exit it. This saves the game partway through the day, allowing several tries if necessary.

-Make sure you're standing under the Onion when the message appears.

-When the screen starts to fade out, press A to open the Onion menu.

-Close the menu. The game should crash.

I don't know the exact timing on pressing A, but I believe the time I happened to press it was when the screen was fading out. If anyone can reproduce this, it'd be greatly appreciated.