I'll one more time mention it would be cool to see an encode with the item delays cut out. More importantly this time, since I've watched it, I'd like to say that this was an awesome TAS! I loved it. I have never seen Super Metroid broken in this particular way before and I thought it was pretty interesting. The previous post with the 'fixed' camera was interesting too, since I honestly could not tell what was happening at many points. I do agree that these new glitches are a bit hard to follow, but I still don't think they count as a "Major" glitch. The overall progression in this TAS is the same as the normal game (beats all bosses, beats the game), so that is fine. But it would be nice if there were a way to make it easier to track what's happening when the glitches mess with the camera.

Going to go over explanations of some of the content of the TAS (part 1): Ceres is the same as in the recent any% glitched TAS (outside of messing around in Ridley's room), and has the initial moonfall as improvement over the last any% TAS. Aswell incorporated into the any% glitched TAS but missing in the previous any% TAS: The 3 moonfalls on the way down to Blue Brinstar. And further such moonfalls happen throughout the run. Before Bomb Torizo, at 6:30, instead of continuing under normal circumstances faster armpump running until Samus is closer to the tunnel and to then mockball, the diagonal upwards slope is used to help for being able to start morphing a bit earlier to start the mockball, and thus be midair for less time. Now this allows to build up bit more running speed into the next room while keeping the same pace as the older method. But this slightly larger running speed is what allows the new approach of shooting Missiles at the door to gain a few frames avantage over the default approach which wouldn't be the case otherwise (and would just be equally fast). The long diagonal room after Bombs, together with the green pirate room and Kago hive room afterwards (right before the elevator down to Brinstar) constitute an annoying (and now, due to moonfall applications being yet another option to move through the green pirate room, slightly altered) segment to optimize since it provides many different drop sources to get back to the maximum of 5 Missiles (after having used all of them up to open the door to Bomb Torizo) before taking the elevator (technically 4 Missiles would also suffice since in Brinstar afterwards, 3 crawlers are farmed for another 6 Missiles to have enough for the next 2 red door shells, but then 1 of those crawlers would have to be killed with multiple beam shots instead of with 1 Missile), and among those, the fastest combination had to be found. With the soft unmorph at 7:05 (to prevent fall speed from being reset) so slope tiles (which almost fill the entire floor of the diagonal room with the E-Tank) will not slow down Samus anymore, which means Samus moves so fast that one couldn't just shoot enemies far ahead of Samus and get the drops if one doesn't stop running for a slight moment (or has the run speed built up to the max until that point). So the relevant farmable bugs in this room each carry their own slight time costs forced upon the player if one decides to farm them. The same goes for green pirates since one could farm some of them aswell, and for the Kago hive bugs in the next room that jump out in different ways depending on RNG (and RNG is set back to a fixed value when the green pirate room is entered, due to a special enemy type, Beetoms, also existing in the room, from where it continues running normally again, so one doesn't have all too many options for going fast and making the Kago bugs jump in suitable ways (to the left, mostly) while also giving the wanted drop type (Missiles, instead of health or nothing). So the resulting change was to leave out the 1st drop for which one would have had to wait a bit in the diagonal E-Tank room (to only get 2 drops here) and substitute that 1st drop with a later drop from a bug that jumps out of the 1st Kago hive appropriately. In the green pirates room inbetween, 2 soft unmorphs (to prevent fall speed reset upon landing, so to store fall speed) happen to then continue from this fall speed with quick moonfalls for which it each time was necessary to turn around twice (away from the edge and then for the moonfall setup towards it) since starting a moonfall (with already somewhat built up fall speed) by turning away from the ledge wouldn't allow Samus anymore to move sideways in spinning pose fast enough to make it past the edge and would hence land back on the same platform. Saturn already pointed out the existence of this type of approach ( https://youtu.be/mXmcCJj742o?t=8 ) of farming the 3 crawlers (at 7:52 in the TAS) when the low% TAS (which doesn't have moonfall techniques incorporated into it yet) was submitted ( http://tasvideos.org/forum/viewtopic.php?p=444095&highlight=#444095 ), and the method was further optimized here. Then at 8:32, in order to be at all able to gain enough moonfall speed, one needs to do the initial fall speed build up at the very top platform (any lower platforms wouldn't allow for it anymore) as has been calculated given the fixed rate of fall speed increase per frame and the minimal required fall speed at the end for the clip. Furthermore, the manner in which the turnaround wiggling at the top happens has been adapted to fit and not go beyond the needs (at the beginning, one doesn't need to initiate the next turnaround as soon as later on, since it still would take Samus longer until she would bonk the ground), so the number of turnarounds was minimized, and their timing adapted so the last turnaround ends with the speed wanted that allows to soft unmorph (which requires pixel perfect y position) during unmorph on the lower platform. On earlier attempts with slightly different inputs, it wasn't possible to store the moonfall speed yet another time on the floor past the floor that one clips through, because there'd need to be enough time to morph and unmorph again, and the speed value would need to line up yet another time, but with more experimentation, it was achieved (and on top of it, a Super Missile could be fired through the floor early on because Samus' movement speed adds to its initial speed, to kill and farm the crawler beneath). Meanwhile, off-screen moving enemies are killed to farm a bit and reduce lag. At 9:42, morph unmorph is done and crawler is killed as soon as possible to reduce lag from the powerbomb. More enemies are farmed in the next room. A good rule of thumb is: If a drop costs ~5 frames to collect, it is worth getting it (outside of when E-Tanks make the health jump to max soon afterwards anyways, and near end-game where the amount of ammo+hp management to be planned ahead is significantly reduced already). On one side, the speed of a powerbomb's hitbox size growth increases over time and if a powerbomb is layed from further away it can be layed earlier, on the other side if one lays a powerbomb 1 or more frames later than at the furthest possible distance, (then one first of all loses that 1 or more frames and) one can get closer by the amount of Samus' current speed and possibly doesn't need to wait for the last step of the pb hitbox's size increase when it breaks the 1st bomb wall tiles that one would pass with meanwhile built up movement speed (which would be what one would hope for at this point to turn out to cut more than the initially delayed frames). This means the question is by how much can Samus' movement speed keep up with (or even surpass) the powerbomb's acceleration around the barrier that constitutes Samus' 1st obstacle that she has to wait for (and in some cases it also depends on how much speed can be built up with which one passes through said 1st waiting time obstacle in the remaining time as soon as a pb was layed, and this time gets smaller the closer/later one lays the pb). So a balance was found between those 2 opposing principles at 8:50, 10:43 (and in this case, a beetom is carried into the explosion early on to not cause lag, but more importantly to lose another 10 health during waiting time for hp adaption so the R-Tank gets only barely filled for later), 11:31, 12:06, 17:06, 20:07, and 21:04. At 10:01, the 2nd moonfall in the 3-moonfalls-chain is stalled (by turning away from the edge of a platform, which works because only passive collision occurs during those, so speed isn't actively reset during turnaround animations) for a moment to adapt Samus' height in order to make her line up with the ground to allow for the soft unmorph that enables the 3rd moonfall. At 11:20, a forwards damage-boost is done (by pressing backwards the same frame as getting hit) which keeps Samus' dash/running speed to make her fly forwards instead of being knocked back, which in this case nicely lines up so one lands on top. At 15:55 there's some free time to farm enemies, because the only enemy that can be used for the setup involving X-Ray and an R-Tank triggering from getting damaged through a door after the transition is that red ball (Multiviola) which moves off-screen, has a fixed movement trajectory (it bounces off of surfaces at fixed angles, and only 1 door shell that it bounces off could be opened beforehand which would make it slower), and takes a while to get to the top left door. By charging up the beam for a quick pseudo-screwattack spinjump, Samus' i-frames are cancelled to be able to get hit by the Multiviola shortly afterwards a 2nd time. When a new room is entered with X-Ray icon active so one can use X-Ray on the 1st possible frame in the room while R-Tanks trigger, and releases the Dash button (used to keep x-raying) after the reserve energy refill finished, then some part of the routines that handle the behavior of X-Ray are cut off, don't get to ''clean up the x-raying state'', which allows for Samus being put into a forced standing pose instantly and anywhere in any previous pose as soon as Reserves trigger yet another time while this game state (called Reserve-Mode, because R-Tanks on top of X-Ray are involved, and X-Mode as name for a purely X-Ray related glitch already exists, but I guess one could also call it RX-Mode, or ''greyout glitch'' which is the original name that Kejardon gave it) with darkened screen is active, but this feature or property is lost as soon as a new room is entered (which happens here). However (as for a long time unknown special case of R-Mode that I found), if one releases Dash not just at any arbitrary frame after the R-Tank refill finished, but does so within an at most (I think) 4 frames range when the refill ends, further routines are cut off, allowing for a variety of more funky stuff to be possible due to the game then keeping to handle many game elements the way it would handle them while Samus is x-raying (which is the reason for its name God-/Grey-Mode). More details describing this glitch's potential and consequences can be found in my description and comment of this video: https://www.youtube.com/watch?v=uHxK6J-fQ1M&index=4&list=PL5If8zSOO37bcgBr6XeWNtZMrxHn6fARx&t=0s . When G-Mode (which isn't lost/cancelled after room transitions, but by using X-Ray 1 more time) initially was found, we thought one needed to get hit after the setup (which ended with Samus immobile standing in the room where one could turn around but neither shoot nor move or jump around) was done. But eventually Sniq figured that remaining knockback frames from enemy knockback involved in the setup itself allowed to get out of this immobile state, provided one would have a small enough amount (4 or less iirc) of reserve energy (otherwise the knockback frames run out during the energy refill and no knockback is initiated afterwards anymore), which allowed for this sped up method using the Multiviola. For this purpose, the R-Tank was barely filled up with 2 hp with an initial fireflea drop at 10:49, right before Samus would start to take a lot of damage throughout the next segment, so this slight R-Tank refill happens at the last reasonable point in time possible, considering one also wants to lose health on the way right until the setup starts for which the R-Tank needs to be triggered for which the usual health needs to be emptied at that point. Now there exists some counter for block interactions or ''the current number of blocks that are busy doing things or reacting to Samus or her attacks'' and it has a limit, a maximum that it cannot surpass. Whenever this maximum is reached (for example if there would be a whole lot of ~ 20 to 30 respawable powerbomb blocks that one wants to destroy, then not all will break, because some remaining blocks will not react anymore, will act like solid tiles until the counter decreases away from its limit again which happens when the destroyed pb block respawn after a while), and in G-Mode time is frozen for tiles so if one interacts with some block (among a certain class of blocks, it doesn't work with all types) by interacting with it multiple times, then the interactions that the game keeps track of (even though they are the same, initiated by the same block just at different frames but just don't end) keep adding up. In the TAS, this is done with a special air tile (called Scroll Continuation PLM, it exists as trigger upon Samus contact to change the behavior of map squares from not letting the camera enter certain areas to letting the camera move into them, mostly used whenever the developers wanted to make hidden passages) as can be seen in this screenshot of what the room looks like in the game's editor: https://cdn.discordapp.com/attachments/171753856378732544/416397690860208139/LNF_Exit_room.png The ''S'' air tiles are those interactive tiles used to max out the block interaction counter, and once this is done, the bomb and crumble blocks further in the room will not anymore interact with Samus, except that their ''default'' interaction with Samus is not to behave like a solid block but to behave like an air tile (maybe because they are blocks that can be broken, i.e. can turn into air tiles), fortunately. After those are passed (since the door on the other end with its tiles would otherwise never open to allow access to the next room as long as G-Mode is kept), the state is cancelled by x-raying (turning all blocks back to normal). Note that (as visible in that mp4 that arandomgameTASer posted), X-Ray is used at a rather strange moment, but this didn't cost any time, and was done this way to let the screen line up to a multiple of the minimal distance to the right door at which it will not permanently mess up room graphics afterwards. In the next room at 16:22, one has to wait a bit anyways for the acid to move away (with its fixed starting height and movement not based on any global timer, but room internal), and due to the nature of the sequence break to get here, Samus will barely have any health so one couldn't just tank the damage. So the short free time is used for getting rid of 2 of the 3 off-screen moving, over time quite lag-inducing Ki-Hunters, and for their drops. The mockball into the acid is slightly rushed such that 1 hp is lost, which will turn out to be the maximum the TAS can deal with at this point without slowdowns. And as has been mentioned before, there's this special inverse continuous wall jump (ICWJ) where Samus rolls up into a ball to immediately shrink in size to go under the coloumn instead of bonking it, saving Samus from an acid dip. At 16:45, the TAS charges a spark, and the beam aswell (for i-frame reset shortly after the boulder damage-boost) for what's called Slope-X-Mode, and then sparks during it. Let me explain this: Spikes give 10 knockback frames, enemy contact and projectiles 5 (except at projectiles, Samus is stunned for 1 frame so it is effectively only 4 there). During every knockback frame, the game tries to initiate a knockback pose and corresponding movement for Samus (so getting hit while turning around, morphing or unmorphing, which are animations that have priority over the knockback pose induction, will first finish such animation and then initiate knockback pose unless knockback frames already fully ran out beforehand), but as soon as knockback is initiated, one is enabled to turn the knockback animation into a damage-boost animation at any knockback frame. If one does so, the knockback counter keeps running down to 0, doesn't try to initiate a knockback pose anymore. When the counter reaches 0, the game in that 1 frame runs a routine that sets Samus state into a falling state (which can lead to race condition problems in the code when other Samus state changing events are triggered on the same frame). Spikes would give the player a lot of time from getting hit to landing on ground to be able to start X-Ray the same frame as this timer runs out (which causes X-Mode, a situation in which Samus is considered x-raying except that one can change Samus' pose and move around in a very restriced manner as long as Dash for x-raying is held), but with an enemy like the lower boulder that's used, one needs to change the knockback into a damage-boost on the 1st frame, and needs some high grounds right behind Samus (achieved with a diag. slope) to land fast enough in time to start x-ray when the 5th knockback frame occurs to enter X-Mode. When X-Ray is released, the game puts Samus back into falling pose. During any shinespark, Samus has Blue-Suit, has the Blue-Suit state (but is heavily restricted in what one can do, normally), and this state is cancelled as soon as the shinespark crash animation starts, but what if it's left out, doesn't ever happen, maybe by releasing X-Ray if one sparked during X-Mode which instead of spark crash animation puts Samus into falling pose? Exactly, it keeps the state. It is noteworthy though that this being possible at all isn't straight forward to find out since under any other circumstances, the usage of X-Ray instantly kills, cancels the shinespark charge, puts its countdown timer to 0, but this didn't prevent me back then from testing it anyways if it would still do this in X-Mode's case, and by cosmic chance, for whatever reason it doesn't cancel it there. A long time afterwards, unnoticed by me and Sniq, SUPERMETROIDFTP messed around with this technique aswell and observed an outrageous behavior which we call Superjump 1st source material of it here ( https://www.youtube.com/watch?v=clSaoHFJE2g&t=0s&index=93&list=PLuSvjvyMNAlnGgn5NiFB6iYW79M0aeXCP ). Soon after, SMFTP discovered its main application (from a sequence break viewpoint), the acquisition of Plasma beam via Superjump ( https://www.youtube.com/watch?v=9JJ0eLwRWSI&t=0s&index=92&list=PLuSvjvyMNAlnGgn5NiFB6iYW79M0aeXCP ). While I'm at it, might aswell go a bit into Superjump details at this point already: Shinesparks during X-Mode behave like normal shinesparks, move just like them, but as soon as the Dash button is released to exit it, the game applies a speed value that it normally doesn't ever apply during sparks. Namely: There's a vertical speed address which increments by about 7 (together with some subpixel speed value) every frame during non-horizontal, so diagonal or vertical sparks for as long as the spark goes until spark crash animation where it is reset. The game uses this address for normal Samus pose speeds, then combine this with exiting X-Mode putting Samus into falling pose, and there you have your Superjump (which can only go straight upwards with that speed, it doesn't work towards any other direction). I've no idea though why they made shinesparks increment the vertical speed address value by 7 (pixels per frame movement) every sparking frame. Tiles have 16 by 16 pixels size, so you'd need to just spark for 3 frames to exceed that amount, that size. But since this doesn't apply for horizontal X-Mode-Sparks, the game just drops Samus at the end of these. With the obtained Blue-Suit (and 1 health remaining after 1 hp acid damage and 2 boulder hits, and not a previous damage-boosts earlier since horizontal movement with Blue-Suit is rather slow, so one wants to create it late) a few close by enemies on the way are killed/farmed for desperately needed health (among them 2 Ki-Hunters to again reduce accumulating lag), and both morph tunnels can be taken without having to wait for any bombs or powerbombs to get rid of them. At 17:16, the final wanted health drop appears to survive the upcoming, damaging spike-platform clips (with usual damage values being multiples of 10, bringing Samus back to the previous 1 health remaining). At 17:42, a neat bouncing trick was applicable: Speed echoes protect Samus from enemy contact and kills them instead, but this protection isn't active during morph (1st bounce) or unmorph (2nd bounce, with adapted trajectory to get here from the 1st bounce) animation, while the dash speed is kept throughout. About the Ridley fight: The 4 Wave-beam particles can easily create a lot of lag, especially when Ridley spits fireballs meanwhile, so this is avoided to the best of Sniq's ability, and further lag is reduced by morphing to reduce the amount of sprites used for drawing Samus. Other than that, attention was payed to the cooldown times that only apply to firing Missiles/Super Missiles afterwards, but doesn't apply to charging the beam which takes 60 frames to be charged and another 60 for the X-Factor attack (cooldown time before next projectile can be fired afterwards: 10 for Missile, 20 for Super Missile). Because of this, one wants to make the best use out of the cooldown times, done by charging the beam each time after firing a Super Missile, and by finishing Ridley off with an attack that would cause a large cooldown waiting time for any consecutive attack. One also wants to keep Ridley to stay close to the ground, by either (i) repeatedly triggering his pogo animation (by breaking out of spin when Samus' body-center height being high enough relative to Ridley's center, while Ridley is moving up from a pogo stomp), or (ii) having the RNG at the end of a pogo make Ridley decide to start another, or (iii) jumping higher up to lengthen a pogo phase, where the former methods every time it's done has a chance to make him spit fireballs, but this would still be better than having him fly up where an X-Factor couldn't be centered around him (unless one climbs up the wall, but this would delay the charging process proportionally to the climbing time until breaking out of spin) so that all particles uniformly arrive at Ridley such that the last particle is gone as soon as possible to be able to continue with other attacks since the game doesn't allow for any other projectiles being fired as long as at least 1 such X-Factor particle is remaining. Last but not least, one wants the whole process to line up at the end such that the final blow hits Ridley during the upwards movement during pogo, because (only) close to the peak after a stomp when Ridley's vertical speed is low enough, a death-grab can be triggered this way instantly. At 19:01, Sniq times and positions the damage-boost (off of spikes which give the longer lasting 10 knockback frames) such that Samus' feet afterwards line up with the top of the spike-platform at the right time to initiate X-Mode and superjump out of it. 19:05 is my favourite, by most viewers surely unnoticed detail application of an obscure mechanic that saved a whopping 1 frame, but it was so worth it lol. So, after the tunnel, one wants to shoot open the door at the top as soon as possible to move past it, and charged beam projectiles are larger than uncharged ones. On the other hand side, to morph with charged beam (no time or reason to charge it after the tunnel), one normally would need to either switch from walking/running to crouch (via crouching animation) and then morph (morphing animation) which is slow, or by turning around midair in unspinned pose with cannon at low angle to enter morph animation right when the turnaround animation is finished (because it counts as pressing down twice; once with down or angle down held for the turnaround, and another time at frame perfect down input afterwards), but there's no time to turn towards the opposite direction either, so what do? As long as the Shot button is held, the game prevents Samus in unspinned midair pose from morphing, because in order to do so, one would need to first switch from forwards facing to downfacing pose, and from there one would need to release and press Down yet another time, but once Down is released, holding Shot makes Samus instantly face forwards again. However, our buddy X-Ray, if one first toggles its icon on, then charges the beam up, allows to keep the charged beam by holding the Dash button instead of Shot button, and this button doesn't force Samus' pose back into forwards facing one, so a charged beam can be carried through the tunnel and fired to open the shell on the other side earlier xD Will also go over the ruleset and why it fits and makes sense to do it exactly like that, but that post isn't finished yet.

The Book! The Book cometh. Praise be to the Book!

Going to go over explanations of some of the content of the TAS (part 2): At 19:14, the typical X-Ray-Climb motion (turning in crouch while x-raying and releasing it to make the game put Samus into standing pose, omitting any collision checks, so it does it even inside of walls), followed by a (spin)jump inside the 2 tiles gap and breaking out of spin while the top of Samus' bodybox is close to the solid pixels of the block above her, which makes the game (generally) do the following check: It takes the y position of Samus' body-center (normally around her chest, at the pixel-wise center if one counts from top and bottom of any bodybox size and the same from the sides, consisting of a square of 4 pixels due to even pixel size numbers I think), then it checks the current extention value that determines by how much Samus' current bodybox extends up- and down-wards (can be found in the Samus Pose editor which looks like this: https://cdn.discordapp.com/attachments/171753856378732544/416456613134729226/Samus_Pose_editor.png ) starting from that center (her width is always the same 10 pixels), then takes the new extension, compares it with with what's above Samus, and if there isn't just pixels of air in the range above Samus that is the difference of the sizes (new size that one wants to transition into being the larger one), then the game pushes Samus' center downwards by that difference before it extends her, which in this case puts Samus into crouch pose about 2 pixels into the ground. From there, the (invisible) collision check box above Samus isn't filled with pixels from solid tiles, so the game allows Samus to jump from crouch. And now there's a thing that would be relevant and interesting to know for how Superjumps work aswell, namely the behavior of this checkbox above Samus' head, since it isn't placed at a fixed relative distance hovering close to and above the top of Samus' bodybox, but instead moves further up, is shifted further up the faster Samus is currently moving upwards, so it can happen that it applies its check at a seemingly unrelated higher area. Anyways, crouchjumps (unless in angled crouch during which Samus is considered in a different state not on ground which allows for the temporary Blue-Suit effect) give Samus an initial 8 pixels upwards shift in position before the actual jump starts (due to the same reason as before, where the game compares bodybox sizes and positions Samus accordingly), and together with the initially largest upwards speed that the jump provides, the checkbox above Samus' head it in the 1st frames shifted up far enough to entirely be located past the 1 tile solid block ceiling, doesn't check solid tile pixels, only air tile pixels, and hence the game allows Samus to continue moving up. For Superjumps, one can still bonk the ceiling midways (when the checkbox is located somewhere higher up containing solid pixels part of whatever platform), and Superjump speeds need to be chosen carefully because of that to make it all the way to the top, but there's 2 more mechanical tools that help here. One is the turnaround animation during which the constant loss of upwards speed bit by bit still keeps being applied (to change the vertical displacement, the amount by which that checkbox above Samus is put above Samus) while only having passive collision happening but no active reset of the speed back to 0 in an instant, to hope that after the turnaround finished, the checkbox is outside of solid tile pixels so the Superjump can be continued. And the other part is what happens at the last visit of the Plasma beach room (at 26:29), where the vertical speed isn't reset either when Samus is in angled crouch pose (and luckily, that is the pose that the game forces Samus into when in the frame of landing on ground, Samus' upper bodybox contains solid tile pixels and not just air, which is observable when door-stuck setups for X-Ray-Climbs fail) in the middle of a wall (so even though the ceiling stops Samus somewhere higher up, the speed is stored), and in such crouched pose, Samus will just stay in place, but turning around will make the game apply the vertical speed so Samus jets up further through the rocks (which can be chained until no speed is left anymore, or Samus doesn't end up in such angled crouch pose anymore). A remaining, unavoidable effect of this is observable in the next room after the Plasma beach room. On top of all this, there's 1 more aspect to Superjumps needed to understand that Plasma beach Superjump, and that is that Superjump speed can be stored into standing positions of Samus (similar to storing speed with soft unmorphs), provided that a few things fit. First of all, it has to be a horizontal or diagonal X-Mode spark (necessarily in the direction that Samus faced the last time she used X-Ray, because the game remembers this, keeps some information stored about it) before X-Ray is released (which makes the game want to immediately apply the accumulated upwards speed). The reason for this is that Samus needs some sideways movement speed in the frame in which X-Mode ends, so that this speed is applied aswell and gives Samus a sideways position shift (while still being in the initial standing pose that lasts for 1 frame before Samus rockets up in falling pose). And secondly, if this slight forwards boost puts Samus on ground, she will stay on ground with the speed stored, and can unleash it by losing contact to ground without a jump or crouching (or initiating a moonfall, since that's the only type of jump that doesn't update or force its own new initial vertical speed value upon Samus). If the previous direction of x-raying isn't the same, then this boost at the end of an X-Mode spark (which is the beginning of a Superjump) will not be applied. So it is worth mentioning that the fact that Samus faced to the right during the creation of the X-Mode Blue-Suit (when X-Ray is started) at 16:47 made the very 1st Superjump at 19:02 apply this boost so Samus switches instantly from the spark into walking animation (I think this happens before Samus would bonk the upper spike-platform during X-Mode spark), instead of possibly jetting past the ceiling, then walks to the right, crouches to unleash the speed (which also charges a spark) and I think she then is placed in crouch inside of the solid statue and Sniq jumps out afterwards. At 19:18, Samus faces left for the Superjump, no sideways boost applied, Samus bonks the ceiling that stops her in the end, and at 19:24 use of that is made by boosting onto the left platform from the spikes to be able to reposition Samus for unleashing the Superjump at a place where it can pierce through the heavens ;) . At 23:32, Samus initially faces to the right for the X-Mode Blue-Suit method, allowing the necessary boost to be applied at 23:55 (where Samus faces right aswell) to get through the grey door, which then conveniently allows at 24:39 for Samus to be boosted sideways onto the ground platform and not jet upwards and fall back down again. Then Samus faces left at 26:07 required for the Superjump storage at 26:25. And another option to shift the checkbox above Samus' head up and down a bit is to switch between the more shrunk downaiming pose and the extended pose during a Superjump. With precision it is also possible in some cases to use an enemy (with the short 5 knockback frames that it gives) to enter X-Mode without having some higher ground to land on, by turning the enemy itself into this ground if one has Ice-beam and freezes it appropriately right after getting hit by it, which is done in Maridia a few times. The room at 19:42 with the 3 Ki-Hunters can quickly get so laggy that it turns out to be better to stay in morphball longer to roll past them, and the amount of acid damage taken to rush through the room is maximized so Samus ends up with 1 health shortly afterwards. At 21:23, it barely was possible to hit and farm 1 of the crawlers with an early Wave-beam shot before enering the tunnel that allows the screen to move further. Using a Superjump to go up the Brinstar-Norfair elevator isn't possible, because the last direction of an elevator ride that happened was downwards (and the game keeps track of this direction), so that instead, Samus would get stuck in an infinite loop of riding the elevator up and down repeatedly. At 22:14 Samus does a noticably high jump (just like it was done in the previous any% TAS, except there, Samus didn't have Wave-beam so the bug had to fly up higher to be able to freeze it past the gate), which is done to avoid entering the rectanglar range in which the refill bug would be triggered to fly up facing left since Samus is coming from the left, in which case one would have to wait until the bug respawns so that it can then fly to the right. An alternative would be to trigger the bug and then kill it as soon as possible and have it produce a nothing drop so it can respawn on its own shortly after, but this would be slower. With the stored shinespark from 19:29, Sniq triggers the door at 22:32 in such a way that he would land and get stuck inside the closing door shell and get knockback from the crab in the previous room which allows to land on the bottom part of the shell (it consists of 4 tiles and the outer 2 spawn first) fast enough to set up a Blue-Suit generating X-Mode spark at this place, and fortunately there's no platform further right at the height of the door in this room or one would bonk into it and would have to stop earlier. To visualize the Superjump situation towards Plasma-beam, here is a hitbox-viewer screenshot (that was put together by SMFTP) of the inbounds rectangle for the room, together with a large part of its surrounding OoB area: https://smethack.f5.si/?plugin=attach&refer=%B5%BB%B0%EC%CD%F7%2FNBMB%20%25%20Glitch%20run&openfile=maridia_plasma_beam_route_004.png (the screenshot is pulled from the description of this video, the link at 4. : https://www.youtube.com/watch?v=VmGSMxSgyuM&t=0s&list=PLuSvjvyMNAlnGgn5NiFB6iYW79M0aeXCP&index=112 ). The 6 worms before the Plasma room are farmed twice because they constitute an excellent farming opportunity for all the health that is needed (and a shinespark can be charged during the 2nd farm), and in both farms, a decent set of drops could be produced with proper RNG values. In Plasma room on the way down, the bottom right pirate is manipulated with beam shots to make him enter a blocking pose instead of preparing a shot which would be in the way when Samus climbs back up. Oh, and I guess it might also be interesting to know how Samus' jump heights with Speedbooster generally depends on run speed, since even normal jumps aren't always that trivial to optimize (like it was the case for finding the fastest running jump to get back to the upper left door in Plasma room): https://imgur.com/a/VP5jP (chart from Galamoz with data source provided by PJBoy a long time ago on TASVideos). At 23:50, the range in which the bugs are triggered to spawn is so large that it cannot be prevented, so they are killed and farmed as fast as possible. They will fly up until they reach the height of Samus' bodycenter, which is why Sniq morphs in the sand to make the right-most bug start flying sideways as soon as it barely moves past ground height, then freezes it sufficiently deep behind the door shell (but not too deep so that the collision checkbox in front of Samus that is shifted forwards relative to Samus due to high sideways movement speed to the right wouldn't contain the far left part of the frozen bug anymore within the checkbox's range), and X-Mode sparks towards it with a boost that aligns Samus in standing pose to the frozen bug instead of the wall, because solid/frozen enemies take priority in scenarios like this. And the door can be triggered with the (iirc) 8 pixels wide walljump checkbox afterwards. The range of locally available RNG values at 23:59 (in this section, the RNG can only advance by different amount of steps within a fixed looping path of RNG values, as opposed to behaving much more unstable in rooms that have either acid or lava set to exist in the room, where an XBA instruction is applied to the RNG value every frame exactly once, while the RNG advancing routine can be called multiple times a frame, allowing for much greater variance of the RNG's pathway to get the RNG wanted, but on the other hand side makes room strategies prone to quickly desynch and not work anymore after slight changes were made) allowed to make the top cacattack spit out spike projectiles early on for a damage-boost (with Blue-Suit that doesn't actively protect Samus anymore during the unmorph animation, to get hit by it) that barely makes it past the platform in the next room. At 24:28 and 24:32, inverse CWJs off of frozen mocktroids are applied, which is possible (without turning around or bonking them), because as opposed to walljump checking walls, Samus' subpixel value isn't normalized to its max (when moving to the right) or min (when moving leftwards) value when an enemy instead is walljump checked, so that this allows to keep a slightly larger distance to them so Samus doesn't bonk them before they die. At 24:39, Samus in X-Mode interacts long enough with the sand tiles until the block interaction counter reaches its maximum (possible because time freezes for tiles while x-raying) to prevent the sand from instantly cancelling the Blue-Suit state (needed to spark back up after Draygon is killed) as soon as even just a shinespark is started inside the sand, because then the sand tiles will just behave like air tiles. At 24:52, the screen is shifted maximally downwards to keep the Plasma-shot on screen long enough to fry the shrimp when it is close to its destined death spot. At 25:40, the jump speed can be kept and carried past the ceiling because of the game not resetting it during morph animation while Samus grinds the ceiling (and the same mechanic is applied at 35:19). At 25:45, Sniq ballbounces on the corner of the pillar so that unmorphing on the spike afterwards will align Samus' height to the spiked ground so that Samus can keep and continue her run speed, and the procedure is adapted such that this can be chained into the same trick applied once more at 25:48. At 26:03, Sniq does a short running jump into (dash speed keeping) forwards damage-boost, lands in the higher up platform to the left, enters X-Mode, and is able to continue running for echoes due to having entered X-Mode with nonzero dash speed. Furthermore, Samus' position can be shifted bit by bit with armpumps to the left (while still being considered as running on ground, so Samus runs midair via X-Mode). One could move faster to the left by first entering walking animation in X-Mode and then releasing Left which makes Samus to walk to the left automatically, but doing so would get rid of the dash speed needed to charge a spark at the end of X-Mode that is needed for the leftwards X-Mode spark right after. At 26:09, Sniq jumps out of the water to bounceball through the tunnel (using ''bouncekiller'' to slow down the rate at which the morphball sinks after the bounce to make it past the full tunnel instead of landing inside), instead of just rolling through the tunnel which would have been equally fast as has been told to me. Iirc, the spark-timer of the spark that's charged at 26:44 and used at 26:50 (to shorten the elevator ride) would have ran out the next frame after the X-Mode spark started. And the Superjump into the elevator works the way it does, since only its lower part is filled up with solid tiles, and higher up it is air tiles in the shaft, as visible in this screenshot from the editor: https://cdn.discordapp.com/attachments/171753856378732544/416618166232416268/Maridia_elevator.png . Note that the Superjump's speed was chosen in such a way that Samus' bodybox would not for a single frame at least partially exceed the upper boundary of the inbounds rectangle of this room when the transition blocks at the top are touched and triggered. At 27:12 yet more planets line up in favour of the TAS, since it was achievable to first fire 2 beam-shots up into the Kago hive above with the first shot fired from further left and the 2nd from higher up and further to the right in such a way that both hit the hive at the same frame (possible because the size of beam-shots that include Wave-beam oscillate slowly in time, so that the initial shot to the left shrinks, avoids the hive for a bit, and extends into it right when the 2nd shot connects). This causes 2 Kago bugs to jump out at the same frame and overlap each other perfectly, because Kago bugs all share the same RNG value that is applied to all Kago bugs that initiate a jump on the same frame (instead of each bug calling the routine to produce an individual RNG value to decide its own jump type). And the timing was adapted so the RNG value would cause a leftwards jump allowing to collect the drops barely (as visible in this temporary mp4 that Sniq made: https://puu.sh/zlOnw/441ddb7f26.mp4 ) without delay. Regarding the phantoon pattern: The 1st pattern Phantoon gives loops through 16 options over and over, and luckily, no frame delay of entering his room had to be done to get the most favourable fast pattern with a lot of flames for drops. Any previous improvement would need to be at least 16 frames up to this point to save time (outside of lag reduction and possibly arriving at Phantoon with the RNG value being in a different range of its looping path), according to Sniq. At 29:35 a crawler was killed and the appearance of echoes was delayed (by leaving out Dash inputs at few certain animation frames) to reduce more lag than the marginal amount of time that's lost by this adaption. At 31:47, Sniq builds up enough fall speed with moonfall to clip through the 8 pixels tall rectangular slope tile's left part to be able to start running earlier from a bit further right when the room event allows progression. At 32:32, the solid enemies around MB1's pedestal that look like (and overlap with then despawned) solid tiles start sinking out of the screen (but still keep existing throughout the boss fight and surely contribute a lot to the reason for why this fight can be so laggy), and MB1's lower part doesn't do any damage (and has a body type like Kraid and Crocomire (if one moves towards Crocomire further above at OoB) have it where their bodies will not allow Samus to move past them, but don't put Samus' walking/running animation to a halt either) but provides knockback frames to run up against it to charge a spark (similarly to how Cpadolf does it in the 100% TAS) and create a free shinespark that later can be used to force the spark crash animation upon Samus after rainbow beam ends instead of rainbow beam putting Samus into a forced crouch pose (called Stand-Up-Glitch). The MB2 & MB3 fight is quite complicated, but to summarize it: There's a frame-wise countdown timer for rainbow beam initiation that at some point after MB2 reaches 0 hp starts at 240 and makes MB2 fire rainbow beam at 0 (so that once MB2's hp reaches 0, one wants the delay until the timer starts counting to be as close to 0 as possible), and preventing MB2 from firing any redbeam at all (as it happens in Saturn's RBO TAS done on Snes9x 1.43, https://www.youtube.com/watch?v=2tse9ytU3dA&feature=youtu.be&t=2606 ) would require a bit check of the RNG value (3rd bit from the left in binary representation) to be correct at specific frames 3 times in a row for another frame-wise countdown timer that starts at value 64 and checks if it shall do another loop or not (in which case it makes MB2 fire redbeam) based on said bit check. And this was not achieved, and even in Saturn's case, if he had fired the last beam-shot 1 frame later, MB2 would have fired redbeam and not given him the optimal result of 0 rainbow beam delay time. Meanwhile, the best previous result using bsnes core was by Cpadolf with 40 frames delay in the 100% TAS. Sniq settled with a delay of 22 frames or less (together with 2 more frames, 1 lag frame and 1 frame of waiting to change RNG), but also almost entirely up to 1 remaining lag frame avoided lag from that 1 redbeam which was 22 lag in Cpadolf's case. At MB3, Samus jumps into the head early on for lag reduction, and for the 10 multi-onion attacks, according to Dan who disassembled the corresponding routine, there's 1 frame of delay for every frame in which the RNG value is strictly smaller than 0x8000, between each multi-onion attack. At 34:49, the total health is adapted to make the escape climb room spark stop where Sniq wants it to stop. In the escape, (after the usual RNG grind at this final section) some pirates are killed at chosen frames to make the RNG go different paths to end up with an RNG value that allows for a suitable steam pattern in the final 2 rooms. Finally, the TAS is finished with a mandatory homage to Cpadolf's Missile shot at ship entry.

I watched the 'fixed graphics' version. In my 15 years, I've never rated a TAS as a 10 in both entertainment and technical quality, but I've always reserved that possibility for a Super Metroid TAS. The platform-adventure genre in general is the most entertaining and prime for creative tricks of all genres, and Super Metroid is the best for both aspects within the genre. With this TAS, I think that it has reached the dream of E:10/T:10. The cut into the elevator shaft (26:48) removed any doubt for me. This TAS is the shining example of kino. It is the absolute aesthetic of TASing on the basis of complete separation from casual gaming and speedrunning. It uncovers truths previously inaccessible to the human eye and possible only through a TAS. It should be the #1 Star. Entertainment: 10 Technical quality: 10

This has been my most anticipated thing since Sniq announced that it was going to be a thing. It delivered and more! The sheer amount of new trickery going on here is mindboggling. Easily a 10/10. I also agree that this makes the current RBO kind of pointless. True, the graphical glitches are a bit jarring at first, but I didn't mind at all when I watched a second time. There's something special and pure about "normal" movement executed perfectly in this game, but there's still plenty of that left in the run, with the totally broken rooms just adding icing on the cake.

Best Super Metroid tas I have ever seen. That super downfall was a pleasant surprise along with a lot of other things. Yes vote and I also vote this run obsoleting the RBO run. I also would vote for giving this run a star.

Since when did Super Metroid speedruns have Sonic-style zipping and require CamHack to watch the run in a reasonable manner?

Since when did Super Metroid speedruns have Sonic-style zipping and require CamHack to watch the run in a reasonable manner?

Ever since Samus' brake button broke.

Nice and well optimized run that demonstrates some of the latest tricks pretty well. The glitches used here are acceptable I guess, except the X-Ray ones, which are clearly major, as the screwed up graphics also indicate. Although cool to see as a demonstration, zipping to pretty much any destination with grey doors and solid blocks no longer being a factor, seems just too much to be called a „no major glitches“ run. Eventually it might become possible (if it isn't already) to skip all bosses and enter Tourian right away instead of just Norfair backwards, and we would have another „notable improvement“ of the so called NMG category if this trend continues. Also I don't think it should obsolete the RBO TAS solely based on the alleged similarity suggested by a few here. There is no suitless heat-run through entire Norfair, or Crystal Flash required to survive, which are one of its main exclusive features not present in any other run. The only similarity is Maridia without GravitySuit, and even there it's vastly different due to the glitchy mess involved, while throwing some of the more tricky strategies out the window (e.g. Draygon). Either way, voting yes for the solid general improvement, which even without the X-Ray glitches would probably reach a 0:21 IGT, but IMO it's not suitable for the no major glitches category as long as they are included.

Eventually it might become possible (if it isn't already) to skip all bosses and enter Tourian right away instead of just Norfair backwards, and we would have another „notable improvement“ of the so called NMG category if this trend continues.

That...already exists. It's the old X-ray scope run. Nice slippery slope fallacy tho.

Way to just ignore his entire point there. As an actual answer, I don't think that would happen, Saturn, as part of the rules require beating the four main bosses. Even if possible, I don't think it fits the ruleset.

All right, going to address all the points he made.

The glitches used here are acceptable I guess, except the X-Ray ones, which are clearly major, as the screwed up graphics also indicate.

Screwed up graphics =/= major glitch. That's at most a stereotype. The biggest glitch in Ocarina of Time, Wrong Warp, doesn't mess up the graphics at all.

Although cool to see as a demonstration, zipping to pretty much any destination with grey doors and solid blocks no longer being a factor, seems just too much to be called a „no major glitches“ run.

The word you're looking for is clipping, not zipping. A zip would be like a warp from Brinstar to Tourian. In any other game, skipping a room or backtrack via a glitch wouldn't be considered very major. Moderate at best.

Eventually it might become possible (if it isn't already) to skip all bosses and enter Tourian right away instead of just Norfair backwards, and we would have another „notable improvement“ of the so called NMG category if this trend continues.

[1978] SNES Super Metroid "X-Ray glitch" by Cpadolf in 21:25.12 Whole point of this run is to beat all the bosses without the various ACES/clips to Tourian that have already been discovered. Doesn't mean X-Ray and its various utilities should be banned entirely. Here's a published example: [1686] NES Mega Man by Shinryuu & finalfighter in 12:23.34 [2601] NES Mega Man "game end glitch" by pirohiko & finalfighter in 00:32.11 Both runs exploit pausing to achieve different goals. Does that mean pausing should be entirely banned because it can lead to ACE? Obviously not. Both runs kill things to achieve different goals. Does that mean killing things should be entirely banned because it can lead to ACE? Obviously not.

Also I don't think it should obsolete the RBO TAS solely based on the alleged similarity suggested by a few here. There is no suitless heat-run through entire Norfair, or Crystal Flash required to survive, which are one of its main exclusive features not present in any other run. The only similarity is Maridia without GravitySuit, and even there it's vastly different due to the glitchy mess involved, while throwing some of the more tricky strategies out the window (e.g. Draygon).

That's assuming a new RBO TAS would be exactly the same to the old TAS, when in reality it would use the exact same glitches in Maridia and Norfair. It would end up being derivative, it's easier to just combine the categories if like 3/4 of the bosses are fought in the same order anyway.

The word you're looking for is clipping, not zipping. A zip would be like a warp from Brinstar to Tourian. In any other game, skipping a room or backtrack via a glitch wouldn't be considered very major. Moderate at best.

Why does this sound to me like trying to introduce significant glitches into a "low-glitch" run, abusing definitional technicalities?

Why does this sound to me like trying to introduce significant glitches into a "low-glitch" run, abusing definitional technicalities?

Yes because my ultimate goal is to ruin Super Metroid TASing forever, obviously.

Yes because my ultimate goal is to ruin Super Metroid TASing forever, obviously.

> calls other people out on using a slippery slope fallacy > uses a straw man two posts later

well holly fuck, didn't expect that, now the game really look like metroid 1 yes vote on entertainement alone but real question is , does the 7min xray scope run warp directly to the ending (aka it change memory until the ending flag triggers ) or does it ZIP to the ending (reaching a room that triggers the ending flag) ? if it's the latter then this movie cannot obselete the other one but still, holly fuck it gets a stars from me

real question is , does the 7min xray scope run warp directly to the ending (aka it change memory until the ending flag triggers ) or does it ZIP to the ending (reaching a room that triggers the ending flag) ?

The current 7-minute run doesn't even use X-Ray scope. The 7-minute run goes OoB using pause/unpause, then moves towards a block that enables ACE access and messes with it, thus closer to your former guess I suppose. This is the last X-Ray run, it was just under 13 minutes.

Why does this sound to me like trying to introduce significant glitches into a "low-glitch" run, abusing definitional technicalities?

Yes because my ultimate goal is to ruin Super Metroid TASing forever, obviously.

Not really any sort of argument or response. What your post sounded to me like is akin to this: Suppose that in some game the end of the game is in a room immediately adjacent to the starting room. Normally you need to play for hours to get there. However, due to a glitch you can clip through the wall and reach the end in a couple of seconds. Would you call this a "low-glitch" category? I don't think many people would agree with that. But then, you say, "in the low-glitch category you have to get this object, which is on the far end of the game". That doesn't change the nature or "severity" of the glitch in any way, shape or form. Putting additional requirements to the category doesn't somehow change the nature of the glitches being used. After all, if it's a "low-glitch" category, glitches that can be argued to be quite severe in nature ought to be banned, even if additional artificial goals somewhat limit how much the run can be shortened by those glitches.

I don't know much about X-ray glitches, but how does this compare to the "cloud" issue in Super Mario World? RTA runs of SMW use the cloud for "low glitch" runs but the possibility of TAS doing that has been ruled out several times because grabbing the cloud is the starting point of ACE runs. Is this a similar run? Is there any point in the run where an ACE-potential gltich was used in another way?

I don't know much about X-ray glitches, but how does this compare to the "cloud" issue in Super Mario World? RTA runs of SMW use the cloud for "low glitch" runs but the possibility of TAS doing that has been ruled out several times because grabbing the cloud is the starting point of ACE runs. Is this a similar run? Is there any point in the run where an ACE-potential gltich was used in another way?

No, nothing remotely related to ACE happens here. I think inbounds xray climbing has been left out before because it has the potential to be used to go OOB, and you could make the same argument about superjumps here, but that's something I disagree with entirely. I don't think glitches should be banned because they can be used in a more gamebreaking way. If OOB/ACE are the things to avoid, then ban OOB/ACE, not things that can lead to OOB/ACE.

I don't know much about X-ray glitches, but how does this compare to the "cloud" issue in Super Mario World? RTA runs of SMW use the cloud for "low glitch" runs but the possibility of TAS doing that has been ruled out several times because grabbing the cloud is the starting point of ACE runs. Is this a similar run? Is there any point in the run where an ACE-potential gltich was used in another way?

No, nothing remotely related to ACE happens here. I think inbounds xray climbing has been left out before because it has the potential to be used to go OOB, and you could make the same argument about superjumps here, but that's something I disagree with entirely. I don't think glitches should be banned because they can be used in a more gamebreaking way. If OOB/ACE are the things to avoid, then ban OOB/ACE, not things that can lead to OOB/ACE.

When you're actively taking precautions with your glitching so that you can say "I didn't technically go OOB doing X" that's a bit much, don't you think?

I don't know much about X-ray glitches, but how does this compare to the "cloud" issue in Super Mario World? RTA runs of SMW use the cloud for "low glitch" runs but the possibility of TAS doing that has been ruled out several times because grabbing the cloud is the starting point of ACE runs. Is this a similar run? Is there any point in the run where an ACE-potential gltich was used in another way?

No, nothing remotely related to ACE happens here. I think inbounds xray climbing has been left out before because it has the potential to be used to go OOB, and you could make the same argument about superjumps here, but that's something I disagree with entirely. I don't think glitches should be banned because they can be used in a more gamebreaking way. If OOB/ACE are the things to avoid, then ban OOB/ACE, not things that can lead to OOB/ACE.

When you're actively taking precautions with your glitching so that you can say "I didn't technically go OOB doing X" that's a bit much, don't you think?

You can also get oob by simply pausing, should all TASes of Super Metroid be banned from pausing?

I don't know much about X-ray glitches, but how does this compare to the "cloud" issue in Super Mario World? RTA runs of SMW use the cloud for "low glitch" runs but the possibility of TAS doing that has been ruled out several times because grabbing the cloud is the starting point of ACE runs. Is this a similar run? Is there any point in the run where an ACE-potential gltich was used in another way?

No, nothing remotely related to ACE happens here. I think inbounds xray climbing has been left out before because it has the potential to be used to go OOB, and you could make the same argument about superjumps here, but that's something I disagree with entirely. I don't think glitches should be banned because they can be used in a more gamebreaking way. If OOB/ACE are the things to avoid, then ban OOB/ACE, not things that can lead to OOB/ACE.

When you're actively taking precautions with your glitching so that you can say "I didn't technically go OOB doing X" that's a bit much, don't you think?

You can also get oob by simply pausing, should all TASes of Super Metroid be banned from pausing?

Pausing is not a glitch. Superjumping is very much a glitch. Reread what I said.