That can happen (see 50 Star Room Stairs ABC strat), but there's a height limit of 239 units on the glitch, which isn't all that high.
Cool, didn't know that but glad to know I wasn't totally off base ;)
The only other suggestion I have is writing some sort of brute-force algorithm to fling mario at that spot at every possible speed and angle and record the results.
And Mario wasn't even jumping at the time, he was landing.
I did a bit of testing and my guess is that Mario might actually have been jumping at the time (the same frame he lands.) I managed to land in roughly the right spot with speed such that I can jump and hit the wall 1 frame later. I would theorize that this happens at the same time that the height of the ceiling is changing, and the game is getting confused about what Mario is colliding with. Mario also reflects off the wall at a different angle, this might also have some impact. I don't know the tools enough to do serious testing though.
I noticed the original video came out in 2013, and pannenkoek2012 says it was shown to him a 'short while' ago. I'm guessing since he put $1000 on it he put considerable effort into reproducing it. Is there any documentation about what ideas were being tested at the time?
When I asked Kyman about it early July, he said he'd shown it to the ABC guys last year and didn't get a response: https://gyazo.com/2e453274c902b374839c09f4b639dab6
He asked again though and this time it did, obviously. So this "short while" will have been in the past month, however, there have been other things discovered like PUs so I guess that may have delayed working on it at all.
Yeah we knew about this months ago before getting public lol
Yeah, pannenkoek mentioned this glitch to me a while ago.
A brute force bot may be a good idea, it could be very specific. Is there any SM64 TASers with experience at that?
Yesterday night I found something interesting by messing up with the spot
http://imgur.com/a/eAwDv
I definitely didn't know lag frames could've been graphically (and not only I think) different from the previous input frame. Shoutouts to Biz
Well, pannen's bounty video has been featured on a ton of popular news website like IGN, Kotaku and Forbes. Maybe this will help get the glitch reproduced? :P
Yeah we knew about this months ago before getting public lol
but did you all do any work on it? Is there a prevailing theory? Or was what was in the video the extent of what was thought up?
I looked at the original video again and looked at the MHS data. I think at the point mario hits the wall, he is under the higher (-173) polygon. This sets his horizontal speed to zero. Then it looks like at the point he hits the ground he is back under the lower ceiling (-2641) you can see him inch to the right in the video. So the control stick is being held in the opposite direction, and since mario's speed got set to zero he can go backwards.
I think maybe recreating this will be a step in the right direction, has it been tried yet? I didn't see it in pannenkoek's video comparing warp to ceiling to warp to changed bit value.
I tried but can't control mupen well enough to get just the right state
Edit: Do you think a Mupen inaccuracy effecting the glitch?
I've been wondering the same. Also, does anyone know if DOTA_Teabag was playing it on an emulator or on console in that Twitch video? If the latter, is it possible he unintentionally did a cartridge tilt glitch or something maybe? And what version of the game was he playing on? 1.0 or 1.1 (aka Revision A, Shindou Edition)?
I've been trying to reproduce every frame the way he played it from the start of the course until the glitch occurs on Mupen, and I'd say it looks nearly identical at this point, and I've been at it for more than a total of 3 hours myself now without any success. Obviously I'm not the only one trying to reproduce it either, so... I don't know... if he did play it on console, I'm really starting to think at the very least it's not reproducible on Mupen.
Edit: Do you think a Mupen inaccuracy effecting the glitch?
I've been wondering the same. Also, does anyone know if DOTA_Teabag was playing it on an emulator or on console in that Twitch video? If the latter, is it possible he unintentionally did a cartridge tilt glitch or something maybe? And what version of the game was he playing on? 1.0 or 1.1 (aka Revision A, Shindou Edition)?
I've been trying to reproduce every frame the way he played it from the start of the course until the glitch occurs on Mupen, and I'd say it looks nearly identical at this point, and I've been at it for more than a total of 3 hours myself now without any success. Obviously I'm not the only one trying to reproduce it either, so... I don't know... if he did play it on console, I'm really starting to think at the very least it's not reproducible on Mupen.
Dota was playing on a Japanese console. Accidental tilting is very unlikely considering there were no other glitches throughout the run, so unless the cartridge tilted and then untilted again quickly, it wasn't tilting. Also, current "glitches" known to be due to tilting are all graphical, and none involve random warping either, so it's highly unlikely to be tilting.
Current TAS:
[SNES] Jelly Boy
[NES] Street Fighter 2010
https://www.dropbox.com/s/et5t623yv7mha26/interesting?dl=0
I think I found something that might at least be a hint.
I tried a little more to achieve the state I mentioned in my previous post, and something interesting happened.
The save state above starts 3 frames before it happens. (after you load the savestate just hold the control stick in a direction, most directions except forward seem to work.)
The first frame my x-pos is ~1002
The next frame it is ~1001
But then curiously it gets clamped to exactly 1000.5 on the next frame, even though that doesn't match up with the velocity and Mario is not even against the wall.
The interesting part is that this is the same frame that both mario lands on the ground and the ceiling tile switches from -173 to -2641.
It obviously doesn't reproduce the glitch, but maybe looking at the code will give a bit of insight into what's going on? Any thoughts?
I'm no SM64 guru, and I can't test this so easily for myself, but for those glitch-seekers, maybe this approach can help:
Don't go looking for an upwarp. Perhaps the action he committed was one that would normally result in a downwarp. However, due to something below Mario, the downwarp couldn't be done, so the game decided to push Mario elsewhere instead. Maybe the game pushed Mario as far up as it would down before it noticed a problem with the warp, maybe it pushed Mario to a preregistered vertical position.
Basically, while recreating this, I would say to try known methods for downwarps, with random factors (such as perhaps that bob-omb explosion) interrupting landing positions.
Sorry that I can't offer anything besides postulation.
Yeah we knew about this months ago before getting public lol
but did you all do any work on it? Is there a prevailing theory? Or was what was in the video the extent of what was thought up?
I looked at the original video again and looked at the MHS data. I think at the point mario hits the wall, he is under the higher (-173) polygon. This sets his horizontal speed to zero. Then it looks like at the point he hits the ground he is back under the lower ceiling (-2641) you can see him inch to the right in the video. So the control stick is being held in the opposite direction, and since mario's speed got set to zero he can go backwards.
I think maybe recreating this will be a step in the right direction, has it been tried yet? I didn't see it in pannenkoek's video comparing warp to ceiling to warp to changed bit value.
I tried but can't control mupen well enough to get just the right state
Personally I just tried for 10 minutes or so, couldn't get any result.
Here's the opinion of the bois:
From a month ago. Someone probably changed their idea.
Rather, finding a new glitch in a game like Super Mario 64 can mean seconds shaved off a world record-setting speedrun. Given how hard this seems to be to reproduce, it will probably mostly benefit Tool-Assisted Speedrun (TAS) which use a computer to calculate every single movement of the character, in this case Mario, for absolute maximum efficiency.
I knew it! You guys are all robots in real life confirmed!
Seriously what lol
Rather, finding a new glitch in a game like Super Mario 64 can mean seconds shaved off a world record-setting speedrun. Given how hard this seems to be to reproduce, it will probably mostly benefit Tool-Assisted Speedrun (TAS) which use a computer to calculate every single movement of the character, in this case Mario, for absolute maximum efficiency.
I knew it! You guys are all robots in real life confirmed!
Seriously what lol
I suppose to someone not 'in' on all this, it'd be pretty hard to grasp what's going on.
Is there another component to Mario's speed besides the h-speed variable in the MHS file? He seems to be able to move perpendicular to the direction he is facing even when h-speed is zero (like jumping while standing right next to a wall and moving parallel to it.)
I'm curious since I tried locking h-speed to zero in my savestate above but mario is still being moved about by something else. The game also changes what ceiling triangle Mario is under even when I lock his position and set his h-speed to zero.
Joined: 11/26/2010
Posts: 454
Location: New York, US
I have another thought I guess I should say. Mario takes damage when he gets ported up so maybe it has something to do with the game thinking hes falling. I hope you guys can recreate it because I'm really excited to know the reason behind it and if it will have implications for future TAS'. I also want someone to win $1000.
I have another thought I guess I should say. Mario takes damage when he gets ported up so maybe it has something to do with the game thinking hes falling. I hope you guys can recreate it because I'm really excited to know the reason behind it and if it will have implications for future TAS'. I also want someone to win $1000.
He takes 2 damage when he hits the ground, which is fairly standard for the amount of distance fallen after the warp. I don't think this really has much to do with the warp.
Current TAS:
[SNES] Jelly Boy
[NES] Street Fighter 2010
I did some testing on how the game decides what ceiling triangle Mario is under.
The result (pictured above) is that it breaks the triangle's down into whole units. In the above picture X is vertical and Y is horizontal, sorry for lack of convention. Anyway solid lines mean that edge is included for mario being under the ceiling tile, and dashed lines mean that edge is not included. At exterior corners, Mario is outside, at interior corners he is inside.
This seam does happen exactly where Mario lands in the video, so I imagine it must be involved somehow.
But this isn't the whole story. It turns out that if I just put Mario under one or the other tiles using MHS, the game updates the tile the next frame. However when Mario is moving, what tile he is under actually lags behind a frame.
As it happens, Mario's speed is extremely small after hitting the wall just before landing. Maybe the combination of all these factors is enough to get an edge case where the game is confused about what tile Mario is under and as a last resort to resolve the conflict ejects him.
Can we find more areas in which this info is applicable? It may be easier to perform in those areas. This TTC upwarp seems very difficult to replicate, so if we can find another area that it could occur, maybe that can allow us to discover this glitch quicker.
I used pannenkoek's MHS script he included in the video. I just set Mario's X and Y to different values until I figured it out.
I also found it helpful to add 00C258C8 , 00C258D0 to there, which seem to be other components of mario's movement. Does anyone know exactly how Mario moves?
@MartyOak: what levels in Mario have ceilings below other ceilings ? Maybe that is a good place to start. Although it must be extremely precise for it to be so rare and for no one to have figured it out yet, so my guess is that it won't particularly be easier in another spot.
My current guess is that mario is moving across the triangle boundary in some way such that when he lands and his speed gets clamped to zero something goes awry in ceiling detection.
I used pannenkoek's MHS script he included in the video. I just set Mario's X and Y to different values until I figured it out.
I also found it helpful to add 00C258C8 , 00C258D0 to there, which seem to be other components of mario's movement. Does anyone know exactly how Mario moves?
@MartyOak: what levels in Mario have ceilings below other ceilings ? Maybe that is a good place to start. Although it must be extremely precise for it to be so rare and for no one to have figured it out yet, so my guess is that it won't particularly be easier in another spot.
My current guess is that mario is moving across the triangle boundary in some way such that when he lands and his speed gets clamped to zero something goes awry in ceiling detection.
Off the top of my head BiTFS, BiTS, Whomp's Fortress, I think SSL has some in the pyrimid, HMC probably does. That's all that comes to mind, but I probably missed some.
From a month ago. Someone probably changed their idea.
I did some testing on how the game decides what ceiling triangle Mario is under.
The result (pictured above) is that it breaks the triangle's down into whole units. In the above picture X is vertical and Y is horizontal, sorry for lack of convention. Anyway solid lines mean that edge is included for mario being under the ceiling tile, and dashed lines mean that edge is not included. At exterior corners, Mario is outside, at interior corners he is inside.
This seam does happen exactly where Mario lands in the video, so I imagine it must be involved somehow.
But this isn't the whole story. It turns out that if I just put Mario under one or the other tiles using MHS, the game updates the tile the next frame. However when Mario is moving, what tile he is under actually lags behind a frame.
As it happens, Mario's speed is extremely small after hitting the wall just before landing. Maybe the combination of all these factors is enough to get an edge case where the game is confused about what tile Mario is under and as a last resort to resolve the conflict ejects him.
