Talk:Glitches in Pikmin 2

From Pikipedia, the Pikmin wiki
Revision as of 08:49, August 12, 2015 by Scruffy (talk | contribs) (New glitch? I don't know if I can repeat it.)
Jump to navigation Jump to search

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

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. — {EspyoT} 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. — {EspyoT} 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. -Los Plagas
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. — {EspyoT} 20:20, 19 November 2013 (EST)
Could probably fairly easily write a JavaScript thing to do that. GP 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. — {EspyoT} 06:13, 22 November 2013 (EST)
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. — {EspyoT} 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. GP 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. — {EspyoT} 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. Scruffy (talk) 08:49, 12 August 2015 (EDT)