April 2026 edit: after quite a bit of research, spread over several months (on-and-off), this has finally been figured out by the wizard @BlastMagic ! It has been a while since he figured out that the clip is possible because the TAS engines use an outdated version (pre-v1.3) of the physics, specifically the fix player function; but now he narrowed it all the way down, and even debunked the touching block undeterminism theory. Here is his comment: "yo I'm doing more [TAS] CLIP study https://scratch.mit.edu/projects/1214319559 so I've found that you clip your left side rather than your head here, and on frame 306 your PLAYER X is ~2351.54 which rounds to 2352 which is the value used to draw the player sprite on the screen, and this is 0.5 pixels away from the level which is drawn at twice the resolution of the positioning system and so this is equivalent to saying you're 1 pixel away; and on frame 307 (the potclunk frame and the frame I would call the clip frame) and also the following frames, your PLAYER X is ~2350.24 which rounds to 2350 which is 2 pixels to the left from the previous frame. this would get fixed 2 pixels to the right if not for fix player missing its second cycle, so the outdated version that your tas was built on is unfortunately the cause of this clip. :'(" To add to this explanation just in case: "Fix player" is a script that runs when the player is touching the level when it's not supposed to, aka it seems to be stuck inside the level. In almost every case, the player is on the very edge of said part of the level, so this scripts tests a few nearby positions (a couple pixels away), hoping that player happens not to be touching the level there. The v1.3 update expanded on these tests, so that's why clips are so much rarer now. In fact, all recorded clips were on pre-v1.3 physics, except maybe the ones in the sideways diagonal mod, for which the version is unknown. Thanks @BlastMagic for all your work on this! Original desc: I got this clip accidentally 2 years ago when TASing the Backwards category. It's always been public, just not in its own project. This is HUGE for glitch-hunting or whatever you'd like to call the quest for understanding the code/mechanics (led by in his masterpiece GOI liter than ever ) because this clip is replicable as many times as you want, and it's not a replay code which only stored display variables - it's a TAS that actually executes the given inputs, so you can extract internal values from the game to have a more accurate view of what actually made the clip happen. That is, if you're lucky and your computer is like mine, and the collision detection on your side gives the same output as mine. The clip will *display* for everyone, but if you actually want to analyze it, click the first script in the first sprite (Info) to turn on the editor mode and see if it still replicates the clip. Relevant info: Long comment threads in the project linked above are undoubtedly the biggest source of info on this topic scratch.mit.edu/projects/805952022 scratch.mit.edu/discuss/youtube/pCCIuSUbs8s at 9:24 scratch.mit.edu/discuss/youtube/Ei44RKkepos at 1:38 and 4:30 There have been a few more vague instances of people claiming to have clipped, but these are the only known recorded ones. Referring to clips recorded above: they all hit a top corner of the player, and always during move hammer first (?). It also seems like the player sy needs to be negative. The contradiction-ish between criteria 1 and 3 could partially explain why clips are so rare. The hammer position is relevant!?!?! I would never have thought that. It is known that if the hammer isn't touching the level, the code runs the function "move hammer first" instead of "move player next", making the player hitbox slightly smaller somehow (which is how to escape tera), but why can a different hammer position *within* the air even matter here? ... Is it actually that? Adding one frame of hammer movement (far enough) while the player is in the air makes this script not clip. I can even move the hammer away and bring it back, getting the clip working again. ... Thanks to for suggesting to investigate this! To test: improve the "fix player function" (see GOI liter than ever for explanation on how it works / what it does). By "improve" I mean adding more outer layer(s) to the collision fix checks. This function supposedly only prevents issues related to scratch undeterminism but is this the problem here? It doesn't feel like it because this is replicable not only on my computer but I also got confirmation from others. Although this does seem to be the exact glitch that the "fix player" function was meant to prevent. Test the improved fix player function on other scripts as well to see if it changes behavior. This is complicated. Do ask any questions you have in mind!!!
