While messing around with custom levels I found a new glitch that allows you to warp an entire room to the left or right. And for once it's actually useful in runs as well. Here is a video of me showing it off:
(I'm aware it looks edited, but it really isn't)
The set-up for this is actually fairly simple, and here's a picture that kinda shows what's going on.
(The blocks you see are from the corner of "Lost Mountaintop", and the other three rooms are "OOB")
The white lines show where the edges of the rooms are and the four tiles that are essential for this trick are highlighted in red. You need one of the bottom of the four to be solid, while all the other three need to be empty. And then all you have to do is walk into the corner of the solid block. You do this by walking of the block and then turning around pretty much immediately.
It seems it is somewhat random whether or not you get warped to the right or the left. I have at least not found any consistent way of influencing it, but there might be something that I haven't thought of. It's still a very new discovery.
This is my best theory as to why it happens. Whenever you try to transition to a room and end up in a solid block the game pushes you back to the previous room. You can see this a lot of places "out of bounds". When you do it between two rooms the game kinda freaks out, but it doesn't end up teleporting you anywhere.
We are essentially doing the same thing here, but since it's on the corner you are rapidly transitioning between four rooms rather than two. So my guess is that at some point the game get's confused about which direction you are entering the room from. In the first part of the video, the game knows you are entering "Lost Mountaintop", but it thinks you are doing so from the left, which then puts you up on the ledge. In the second part the same happens, but with the room to the right of "Lost Mountaintop".
As it stands, if you perform it quickly I'm guessing this might save somewhere between 3-5 seconds (crossing an entire room takes about 6 seconds), so it might be worth doing in runs. Also I can't think of anywhere else this might work, but I probably haven't looked everywhere, so there might still be some place(s).
Just for archival purposes - I accidentally observed something similar when trying to find a way above Strange Formation (which, by the way, wouldn't be useful anyway - measure once, cut twice, right? Kappa ). However, I don't think it's the same thing, just something screwy with loading transitions in the ¤rough approximation¤ of two borders. Along the Blue Lake/Strange Formation transition, it sometimes spits you out back at the beginning of Blue Lake. I don't 100% remember the circumstances in which I produced this, and I can't stream/play for another five days still, but I can try to demonstrate it if anyone is curious, and nobody finds a way to put it to use before then.
EDIT: By the way, I'm sure that as we find useful things, we'll post the results here, but Kobe and others, I highly suggest joining the OTS speedrun discord! That will also make it easy to schedule and plan races when we get those started again. :)
UPDATE: After talking about the glitch with BeardedBusker and thisishowmymindworks we found out that the glitch actually works everytime you can move quickly between at least three rooms that have a corner in common. For example, you can do it in the top left corner of "lost mountaintop" and it skips "lava pits".
Since the solid block doesn't matter for this glitch, it seems that what causes the glitch is really the quick succession of screen changes. The game probably can't keep up with all the loading/unloading it has to do and then changes your coordinates out of confusion.
With this knowledge, we can now use this glitch to save some time while falling from antenna relay by skipping a screen like this:
Combining this trick with TIHMMW's one gives us a time saved of around 7-9 seconds which is definitely a lot. Unfortunately, we still havn't figured out a way to do the trick consistantly yet.
Bonus: You can use the glitch to leave alien city without the gun. It's useless but funny!
I've been looking at the flash script to figure out the warp glitch and I think I understand it now. I can control the direction of the warp (but can't trigger it consistently enough yet), at least in the situation where all 4 edges of the corner are free air (there are some complicated push-back mechanics when 1 edge is solid and I don't 100% understand that yet). The important functions are:
game/world/level.as: Level.trackPlayer game/world/level.as: Level.gotoLevel flashpunk2/Engine.as: Engine.setWorld
Engine.setWorld(newWorld): Here world is what we refer to as a level in OTS. This sets a variable called targetWorld to our parameter newWorld. At the end of the frame currentWorld is updated to targetWorld. If setWorld is called multiple times in a single frame only the last call matters because targetWorld is just overwritten on each call.
Level.gotoLevel(x,y,side): Calls setWorld with the level located at (x,y). If side is LEFT or RIGHT, the player's x-coordinate is updated accordingly. If side is TOP or BOTTOM, the player's y-coordinate is updated accordingly.
Level.trackPlayer(): The code of trackPlayer is basically (stuff irrelevant for our purposes removed):
// Going to the right if(this.player.x > this.width) { gotoLevel(this._x + 1,this._y,this,LEFT); } // Going to the left else if(this.player.x < 0) { gotoLevel(this._x - 1,this._y,this,RIGHT); } // Going down if(this.player.y > this._height) { gotoLevel(this._x,this._y + 1,this,TOP); } // Going up else if(this.player.y < 0) { gotoLevel(this._x,this._y - 1,this,BOTTOM); }
Note here that if both player.x and player.y begin to exceed the bounds of the level on the same frame, then gotoLevel will be called twice. First in the x-direction (left/right), then in the y-direction (up/down). The y-direction is the second call so that will determine our final targetWorld.
As an example assume player.x < 0 and player.y < 0, i.e. Yuri is hitting the top left corner of the level. Let's say the level is (9,4), i.e. Lost Mountaintop. On the first gotoLevel (in x-direction) we set targetLevel to the level to the left of (9,4), i.e. (8,4) which is the level above lava pits. We also update Yuri's x-position to be at the right side of the screen. On the second gotoLevel (in y-direction) we set targetLevel to the level above (9,4), i.e. (9,3) which is the level above Lost Mountaintop. We also update Yuri's y-position to be at the bottom of the screen.
Together this means we will go to level (9,3) which is above Lost Mountaintop, and Yuri will be positioned in the bottom right corner. In other words he will be right at the OOB cliff where we can also do a warp (this is the red scenario in the following image).
To understand why we sometimes gets warped one way, and at other times another take a look at the following image:
If we hit the corner of Lost Mountaintop perfectly, then we get warped to the right as we wanted. If on the other hand we first hit the level transition to the empty level above Lava Pits (i.e. level (8,4)), but then turn around and hit the corner while going up and to the right, then we get transported to the left and to the level above the empty level above lava pits (i.e. to level (8,3)). This is the blue scenario in the image.
The following video shows me first following the red arrow a few times and consistently getting warped to the right, then I start following the blue arrow and consistently get warped to the left, and finally I follow the orange direction and consistently get warped to the right. While recording this I didn't get warped in an unexpected direction even once.
In general if we move left while triggering 2 level transitions in 1 frame, then we get warped to the right. If we move right while triggering 2 level transitions in 1 frame, then we get warped to the left. Since we usually want to get warped right, we usually want to approach a corner from the right (i.e. Yuri is moving to the left). Whether we are going up or down is not terribly important since it only makes a minor different in where we end up (see image).
On an unrelated note, we can actually do 2 warps on the Lost Mountaintop OOB route:
I suspect others have had the same idea, but I haven't seen it mentioned so I thought I would share. Might make sense for any%. Unless we get much better at warps I doubt it will ever make sense for the other normal categories though.
That's a very awesome breakdown of the glitch!
I've kept messing around with it and i found a consistant way of triggerring it a the top right hand corner of "Lost Mountaintop". It involves pause bufferring (i.e. quickly pausing/unpausing to advance the game a few frames at a time)
Basically, keep holding "right" above "lost mountaintop" then, when yuri is close to the edge, start pause buffering (but KEEP holding "right" while doing it) until either you can't see yuri's eyes anymore or the level just start transitioning (that's a time window of a few frames so even if, like me, you can pause buffer frame by frame that's still doable) then hold "left" (while paused), unpause the game and done!
Here is a video where i do it 7 times in a row using this method.
Of course, this method has two issues. First, you can't pause during the one frame of screen transition which can ruin the setup. Second, it only saves time in IGT runs and not RTA.
Also, even if it's technically allowed it kinda screw a bit with the principle of the In-game timer. :p
That's amazing! And you show off how, once you're comfortable, you don't even need to buffer too many times. Actually, I would bet that it still saves a little time in RTA runs - just not as much. Especially if this can be applied in every such instance of this glitch, now we have, I guess, four viable places to start implementing this in runs.
As far as how this would interact with the rules, I think this is pretty clearly allowed as our rules stand, and it's not an arbitrary line in the sand. SOG is banned because the IGT does not increase while Yuri is off-screen, and the framerate drop breaks its accuracy. Savewarps are banned because the IGT is not visible while you exit the game file. Pausing (like to turn off autosave) is allowed because it does not interfere with the normal operation of the IGT. Therefore, even if pausing is used as a meaningful part of strats, that's just part of the meta-game. Now, if it was found that there was a two-frame delay before the timer starts again, and someone pause buffered through the entire game, and got WR with a sub-6:00 IGT that was 80 minutes RTA... then we might have to talk. :P
If we're basing this off of IGT and there isn't a huge, if any difference in time by pausing, then that's a feature implemented by the devs. Dunno if anybody caught the glitchless run of OOT at SGDQ, but their reasons for why it was glitchless is what I'll apply to this: if pausing doesn't affect the IGT, then doing it over and over again is legit for an IGT based category since it acts that way purposefully. Just my 2 cents in case it helps.
Interesting. I don't see a problem with pause buffering as demonstrated by rezoons. It is within the rules and unless the category is broken by it (like the any% glitch) I don't see a reason to do anything about it.
By the way, are you using a controller for the pausebuffering? I'm using a keyboard and I'm having a hard time pausebuffering quickly enough to pull this off more than about 25% of the time, but maybe I just suck at button mashing and need to get better.
Yes, i'm using a controller but i thought it would be easier with a keyboard because it's completely unnatual to do it with a controller. You have to quickly press A and Start while holding the left joystick right. The only two possibilities i have are:
- Holding the left joystick with my left index, pressing Start with my left thumb and A with my right one.
- Holding the left joystick with my left thumb, pressing Start with my right index and A with my middle finger. And they are both annoying.
So is this trick faster to do with or w/o pause buffering? Anybody know?
Near as I can tell, it's equal or slightly faster IGT. You minimize the potential of any inefficient frames on the transition, and you can also buffer moving to the right after the trick. Every time I've gotten it in real time, I've come a tile to the left before I realize I got the trick, so I'm adding two tiles of lateral movement to the total trick execution time. I guess if you take (my) penchant for human error out of the equation, it's equal.
You have to be able to execute it in less than six seconds real-time for it to save time in the RTA categories. There was one time I got it with only two pauses, so I'm sure it would have still saved 3-4 seconds, but usually I spend close to 10 seconds getting the trick.
Gotcha, thanks! I've been finding it a bit easier for myself to get real time so seeing if i want to do either way for IGT.
