PLEASE DO NOT VOTE WITHOUT READING BELOWPosting this thread on behalf of Mr Bean, who had again found another discovery in how the game handles collision. Specifically, what causes the wall riding mechanic that makes the ultra cut possible in Mushroom Gorge, as well as the final turn "wall ride" which is currently not allowed via Players Page rules.
Brief context;
- CTGP channel has automated leaderboards where the ghosts are uploaded.
- On tracks with SCs/lap skips, Bean essentially makes another checkpoint on the track treated as "key" so that if it is bypassed on any lap then it immediately goes into the SC/skip category.
→ He doesn't
change the checkpoints in the actual game, he just looks at which ones were passed and demands certain ones to be passed in order to filter them.
→ So for example, on Bowser's Castle, one of the checkpoints that isn't key on the spiral turn is treated as a key checkpoint on his check, and thus needs to be driven through on all 3 laps.
→ If it is, it goes into the Non SC/No Glitch leaderboard. If it skips it even once, it lands on the SC/Glitch leaderboard.
At the moment, CM has few runs that fulfil all of the current requirements for no glitch (pass all key checkpoints, including a few additional checkpoints Bean has treated as key) but are clearly glitched. They do this by going out of bounds near the start but still drive through all of the checkpoints, thus it is counted as no glitch. You can see that leaderboard here;
http://chadsoft.co.uk/time-trials/leaderboard/05/E4BF364CB0C5899907585D731621...The plan for this fix is easy, he plans to make many more of them treated as key via his check, to the point where driving out of bounds is much slower than staying in bounds, since you won't be able to cut as much of the track off whilst passing through all mandatory no glitch checkpoints.
TF also currently doesn't differ box clip from non box clip.
http://chadsoft.co.uk/time-trials/leaderboard/04/1896AEA49617A571C66FF778D8F2...An easy resolution, he plans on making one of the checkpoints on the turn the clip skips treated as a key checkpoint, thus it'll work the same as how rBC3 works.
─Mushroom Gorge, however, is a bit of a unique instance.
http://chadsoft.co.uk/time-trials/leaderboard/02/0E380357AFFCFD87223299948856...The current time at #1 on CTGP uses the mountain at the end of the track to cut the final corner.
Most people are familiar with this cut, but for those that aren't, it's performed by mushrooming off the last bouncy mushroom in the cave and then angling yourself in the air to wrap around the final corner by riding the mountain wall.
The current rules on the PP, and adopted by the mkwrs page are as follows;
- No riding on walls/mountain
- The 'Canyon Gap' that cuts the final turn is allowed, only if you don't ride the wall/mountain, clipping the wall is okay.In order for Bean to fix the leaderboard, since it doesn't skip any checkpoints of any kind, he had to look into what made the wall ride possible and how to detect it so that it would flag in a run and thus be moved to a different category.
To do this, he booted up his debugger and investigated how the locked speed mechanic worked. Basically, when you touch a locked speed ramp, a flag is set stating that your character is moving at a fixed speed and that the speed doesn't change until you touch the floor again (or another locked speed ramp, such as a bouncy mushroom). Using a mushroom prior increases the lock speed, and depending on the locked speed ramp is what your speed is locked to.
Slow ramp (rGV2, rSGB, rBC3) = 50.0 units per frame
Bouncy mushroom (MG) = 73.0 units per frame
Bouncy mushroom in mushroom boost = 100.0 units per frame
When colliding with any wall, after hitting a locked speed ramp prior to it, your vehicle is locked to that speed, even whilst on the wall. This is how the MG ultra works; without anything acting against you to decrease your speed, as long as you can defy gravity (i.e. the slope of the wall lets you angle yourself so you can propel yourself upwards) then you can ride them as long as you see fit.
Detecting that is easy enough, and he could filter those that use the wall ride apart from those that don't, purely based on the flag that occurs when you collide with the mountain.
The reason for this thread is because wall riding exists in another form, which is currently not banned on any rule set...Mushroom Peaks Wall Ride Binary (Twitch highlight from his stream)
To summarise, he turned on his debugger and told the game to freeze on any frame where it triggered the flag found on the wall ride (leaving a fixed speed ramp, followed by colliding a solid wall). In the highlight, you can see that the game freezes when colliding with the side of a mushroom, indicating that the physics that make the wall ride possible are also present with clipping the side of mushrooms.
It also happens when touching a bouncy mushroom, then lightly grazing the fence at the start.
Here's a clip of the debugger in action.The game freezes when the flag is hit that he's colliding with a wall after hitting a fixed speed ramp; the fence behaves the same way as the mountain on the last turn.
Here's another feature of the debugger showing what happens when you remove fixed speed.In this clip, his debugger freezes when hitting the wall, indicating the wall ride has started; he then turns off the flag for fixed speed, and gets different results.
And here's one last one, showing how you can trigger wall riding even when it looks like you don't ride the wall.In this one, you clearly see the back wheel of the bike go through the fence, but the flag is still triggered for wall riding; despite not getting any kind of launch from it. At real time speed, it'd be really hard to tell that this triggered the wall ride flag, but it's there.
But it doesn't stop there...This technique can be found in the Mushroom Gorge No Glitch TAS.Hitting the corner of the mushrooms in this way acts the same way as wall riding the final turn of the track. The boost you get from the corner is the exact same quirk of the physics engine; you are able to gain more speed and pass the locked speed (going from 73.0 to 89) and the TAS abuses this. This could very well be implemented into human runs, and there's a high chance a handful of the flaps on MG No SC make use of this exploit for the first mushroom at the start, even by accident. It's highly likely that
this run grazes the fence and gets pushed forward ever so slightly by it, and even runs like
this one may have even hit the fence and got a slight push, but it's impossible to know for sure without analysing the ghost file.
So before Bean can make a fix, he needs to know what the community decision is behind this. His own personal opinion on it is this;

But obviously it's not up to him, it's up to the community as a whole to decide what happens. He needs to fix the leaderboard in some way, and this could also mean that the current PP rule on this track needs revising, because at the moment, it's possible runs have been performed using this, despite it being a banned mechanic.
You could argue that the wall ride at the end and the bouncy mushroom wall ride are different; but the game treats them the same. If you turn off the physics that make riding the mountain possible, then "mushroom abuse" (as it has been dubbed in the TAS) also stops functioning, as does the fence on the bridge at the start when you graze it.
─Option 1: Allow all instances of wall ridingThis would basically make riding the corner standard for no glitch. Anything goes, as long as you aren't skipping key check points. It would be treated like a new strat and people would implement it into runs. All key checkpoints must be driven in order regardless, but riding the wall/grazing the fence/clipping the side of bouncy mushrooms are all allowed to optimise the time.
Option 2: Allow everywhere except on the last turnThis means the current rules are in place, and remain untouched. Wall riding on the last turn is forbidden, but doing anything else that uses wall riding on any other part of the track, such as the fence and the bouncy mushrooms is allowed. Arguably the most hypocritical and arbitrary, as you are essentially nitpicking between what you can and can't do with what is essentially the same mechanic.
Option 3: Allow against side of objects (bouncy mushrooms) but not walls (solid or invisible)This is the above rule, but being more specific. This basically means that using it as a way to gain time/momentum is fine, but only off of the side of a bouncy mushroom (like the TAS does). This would also be a rule that would make it so players that
may have accidentally clipped the side of a bouncy mushroom won't have their no glitch runs invalidated by Bean's check. However, still arbitrary and nitpicking between instances of the same physics quirk. Will also make flaps difficult to moderate, as video evidence/the ghost file/having it driven on CTGP would be the only way to check if any instances of wall ride were used during the run.
Option 4: Disallow all instances of wall ridingAlternatively, keep the rule as it is (i.e. ban the wall ride) but enforce it everywhere for consistency. Recognise that using the corners of mushrooms to be launched forward is wall riding, and ban all instances of that. Being brushed against the fence at the start after using the first mushroom for flap is also forbidden; meaning you would need to very evidently clear the cut and not touch the fence in any way. The only downside with this is that it's impossible to gauge runs which accidentally graze the fence, and all flaps/3laps that skip the opening would need ghosts/video/driven on CTGP to validate whether any instance of wall riding had occurred.
Bean can't proceed until he has a community decision, the same way as how he needed to know the stance My Stuff/Custom Music Mods before inventing the system to check and moderate that. I have direct contact with Bean and I can get him to answer questions about it if you're confused on anything. He's also accessible when live streaming on
Twitch.