So, I've found that regular pause buffering enables this, which would turn W3 into a bit of a mess for RTA, as well as improve the TAS in W8. My experience has been: close to the wall - pretty consistent. Farther away from the wall - varying degrees of inconsistency, but just enough to make the skip in W3 viable. The one at the beginning of W3 - atrociously inconsistent.
I think it needs to be made clear whether this is a grey area and if it counts as FPS manipulation, and how reproducible it is across systems.
I think this is mostly considered FPS manipulation, because not every system is capable of working perfectly at 50 FPS, and most likely in your case there is a microglitch that allows you to shoot through walls. I think so, because using the example of my system, such manipulation of shots is impossible for some reason, only using drag-glitch. Accordingly, it can be concluded that this is unacceptable according to the rules of the RTA.
So yeah, I've got this glitch after some time. Anyways, I would be against using such a variation of drag-glitch, although in this case we do not manipulate the window, but we still force the game to make a shot through the blocks, which actually changes the philosophy of runs very significantly.
I think this discussion thread will be the main step towards making clear rules of the game, which will include rules for using the pause buffer and frame rate manipulation.
Also like 2 years ago was found another way to get Wrong Warp glitch through F3 (menu for changing characters), and then it may uses for 100% runs which also made a mess of this category
Let me just preface, I think this glitch sucks in its current form and will make getting optimal W3 consistently a major pain.
That being said, there's no "drag-glitch" (resizing the window) involved, and we're not doing anything we weren't doing before - pause buffering affects FPS, so that genie is already out of the bottle. I believe what causes this is when we get that still-screen as we're pause buffering. The game is probably updating the projectile position, but the information isn't checked against the collision until the projectile is actually drawn on screen.
Since you've been able to reproduce it standing next to the wall, I'm going to assume the collision behaves the same on diferent systems - I also can't sometimes get it from afar trying continuously for 10 minutes or so.
Anyhow, to reiterate - we're already affecting FPS by pause buffering. This isn't the drag-glitch. The new skip sucks. The community needs to decide if we want to arbitrarily ban this - because the pause buffering genie has already been unleashed and is allowed throughout the run - or if we're going to weather an inconsistent glitch.
The community and the mods need to decide if we want this.
Edit: corrected "drag-clicking" to "drag-glitch".
I would sugest name the glitch like "Pause-Glitch". Probably It's something new, but I don't still think so
You misunderstand me, Anso. I believe that the principles are the same as if you were resizing the game - the game can't draw the projectile so it doesn't get checked against the collision. But, this gets achieved without means that are external to the game/disallowed.
As for the TAS, no idea what their specific guidelines are. My main gripe is that this would make W3 pretty random for RTA, but it seems silly to ban a single 20s glitch just because we don't like it. The one at the beginning of W3 would definitely not be used in its current state, though.
So, I think we need to actually try and see how reproducible this is for everyone.
Could you guys do some testing based on these specific inputs? Anyone who's good at pause buffering, really. To replicate, you have to be doing 0-1 frame pauses, much like at the end of the Kracko skip. Otherwise, it won't work. It seems multiple consecutive pauses on a single frame will make the bullet glitch. (Go to YT for timestamps.)
just saw this development, and... I don't know. I still haven't performed this myself, so I don't know it fully, but to my understanding this isn't possible without pause buffering, right? We could technically say that every other strat that we use pause buffering for could "technically" be done without pause buffering, it's just that we use them to make the tricks easier/humanly possible. But for something that literally requires it, even for TAS? Not sure.
This is just my silly take on this, I don't know how useful my thoughts and this comment will be in affecting the decision on whether to allow this or not
It seems that to shoot through a single block, shooting every frame makes it possible, as evidenced by the test below. To make bullets pass through it from afar, you need good positioning for the bullet sprite and some way to freeze a frame. For example, reloading a save technically makes that possible.
If we disallowed strats not possible without pause buffering - like shooting every frame - some runs would be invalidated that exploit the trick to kill bosses faster.
Edit: I'm confused by "[strat required] even for TAS" - AFAIA TAS can exploit every feature of the game. It stands to reason Shar didn't use pause buffering because there was no need to.
Sorry, I got confused by your original explanation of how this works. That's my bad. I somehow inferred that the game needs to be paused for the projectile to not have wall collision detection.
It's all good, no worries. These are all interesting points to consider. But yeah, please do some testing and post some unedited vids.
If it's hardware dependent, then it shouldn't be too difficult to come to an agreement in the end.
Do please keep in mind that you need to have some muscle memory and conscious thought to go for frame perfect pause buffers to make this work, though.
