Washington, USAWhat's good speedrunners, we have a fresh announcement for you
Starting today, we will be using an automated system to comb through our leaderboard submissions on the main leaderboard. If your submission does not follow the guidelines (e.g. it has milliseconds when it should not, or the platform fields are not filled out correctly), your run will be automatically rejected with a message listing what needs to be fixed. The rejection will also contain a link to a new wiki page that walks through how to fill out the run submission form: https://bthl.es/3s
What do I do if my run is rejected? Simply refer to the wiki page linked in the rejection message, and re-submit your run with the fields filled out correctly. As of now, your run will only be automatically rejected if it has errors that are easily fixed on your end. You don't need to wait for your next PB or anything like that. Why are you doing this? We are getting to the point where we are receiving 50 or more submissions every day and it's very difficult to keep up. By being more strict about the fields in the form, the moderators can spend less time correcting submissions and more time verifying the video and moving on. With the new system, we hope to be able to approve runs more quickly than we have in the past. I think my run was rejected by mistake If you think there is an issue with the bot, reach out to a moderator and let them know your situation and we will figure out what is going on.
If you have any questions, feel free to ask them in #lobby in the Discord server, or here.
After further discussions with other members of the community, I'm not longer in favor of allowing remapping/framewalking. Here's a breakdown of my original post and why I've changed my mind:
Speedrunning has a history of pushing the limits of what people think is "acceptable" to complete a game more quickly. Take any average non-speedrunner and you'll find it's likely that they hold the belief that any of the tricks/glitches we use in this game are unfair and should be considered cheating. I think these button remaps are the next step in a series of optimizations that speedrunners take to achieve their goal of completing the game as quickly as possible.
The first part of this paragraph is true, and the second part will be true if the remapping is ultimately allowed. However, the series of optimizations that speedrunners should take to beat the game quickly should involve themselves entirely inside the game. It's unfair to have a gameplay advantage stem from modified external hardware.
The trick itself is not toxic. It doesn't kill runs for stupid reasons, it hasn't blown the game wide open, and I wouldn't say it gatekeeps anyone from the game (emulator players have already had access to this sort of re-mapping, and the time save only matters at very high levels). There's an argument that this re-mapping is a can of worms that allows more re-mappings to occur for specific angles in the game. Some examples I've heard are the wallkick in Secret of the Haunted Books SS, and the single-jump wallkick in Shoot to the Wild Blue. I don't believe re-mapping buttons to the angles needed on these stars will cause any major advantages/timesaves. Both of them (and some other ones I've tried to think of) still require precise movement during or around the analog angle in question.
These two paragraphs aim to say that it's just one little trick and it won't cause much harm. It's true that remapping is currently only being used for one trick. I also still believe that there aren't a ton (if any) other timesaves that will stem from allowing remapping. However, a single small timesave being affected by external hardware isn't a reason to allow it. We can still use our best judgment at the smallest level of the game to ensure a fair and fun speedrun. This is especially true for the moderators of this community, who have devoted a huge amount of their personal time to fostering this community and its rules.
Additionally, Cheese's point in the video doesn't sit with me very well. He states that he feels bad because he has spent so much time on JRB cannonless and doesn't want it to go to waste. To me, that's just part of speedrunning at a high level. I guarantee there are several runners who have spent countless hours practicing/optimizing old routes of SSL 100 (one of the 100-coin routes that has changed the most over the years). You spend time learning what's fastest because you want to do the fastest thing available. When something faster comes along, you move to it. That's speedrunning.
This is still a poor argument, but I don't think Cheese was necessarily using it as one. He was just stating how he feels about missing out on a cool strat that he spent time perfecting. As far as I know, Cheese is neutral on the ban, and his time spent on learning some cool movement won't affect a vote he would make.
It's up to you whether you think this trick is "more exciting" than the previous JRB cannonless strat, but ultimately I think there's nothing wrong with the trick as it's being performed today for the reasons I've stated above.
For the reasons I've broken down above, I think it's best if this remapping is banned.
A few more points that I've heard involve worries about accessibility within the community (which is super important to me), as well as other potentially valid remapping situations. Considering those, I'm proposing the following rules change: Re-mapping is allowed in SM64, with the following restrictions:
- The re-mapping scheme at the beginning of the run must remain for the entirety of the run. That is, a runner using a controller that maps buttons to analog inputs (e.g. Boxx) must use a controller with that re-mapping scheme for the duration of the run.
- Swapping controllers to ones with the same re-mapping scheme (for example, swapping from OEM N64 to Hori Mini Pad) is acceptable.
- There cannot be two inputs mapped to the same output. For example, you cannot have two buttons that send the ‘A’ button to the console, nor can you have both an analog stick and a button that sends an analog direction.
I'm in favor of allowing framewalking/re-mappings.
Speedrunning has a history of pushing the limits of what people think is "acceptable" to complete a game more quickly. Take any average non-speedrunner and you'll find it's likely that they hold the belief that any of the tricks/glitches we use in this game are unfair and should be considered cheating. I think these button remaps are the next step in a series of optimizations that speedrunners take to achieve their goal of completing the game as quickly as possible.
The trick itself is not toxic. It doesn't kill runs for stupid reasons, it hasn't blown the game wide open, and I wouldn't say it gatekeeps anyone from the game (emulator players have already had access to this sort of re-mapping, and the time save only matters at very high levels).
There's an argument that this re-mapping is a can of worms that allows more re-mappings to occur for specific angles in the game. Some examples I've heard are the wallkick in Secret of the Haunted Books SS, and the single-jump wallkick in Shoot to the Wild Blue. I don't believe re-mapping buttons to the angles needed on these stars will cause any major advantages/timesaves. Both of them (and some other ones I've tried to think of) still require precise movement during or around the analog angle in question.
Additionally, Cheese's point in the video doesn't sit with me very well. He states that he feels bad because he has spent so much time on JRB cannonless and doesn't want it to go to waste. To me, that's just part of speedrunning at a high level. I guarantee there are several runners who have spent countless hours practicing/optimizing old routes of SSL 100 (one of the 100-coin routes that has changed the most over the years). You spend time learning what's fastest because you want to do the fastest thing available. When something faster comes along, you move to it. That's speedrunning.
It's up to you whether you think this trick is "more exciting" than the previous JRB cannonless strat, but ultimately I think there's nothing wrong with the trick as it's being performed today for the reasons I've stated above.
Are you trying to run the game on Linux? Project64 works on Windows, and OpenEmu works on macOS.
Part of our moderation rules require that we do not discuss bans. Thanks for your time.
There is a slight change to the timing rules on the Super Mario 64 leaderboards, effective immediately: Full-game RTA runs will be timed based on the logo at the start of the game, rather than console power on. Rather than console power on being 0.00 seconds, the first frame of the logo will be 1.33 seconds (40 frames at 29.97fps). This makes it much easier to determine the start time of a run on capture devices that don’t make it obvious, as well as standardizes runs that started from reset rather than console power on. More information on timing your runs under this new rule can be found here: http://bthl.es/1m
- What does this mean for me? Most likely nothing. You can continue running the game as you have been and if you’re not looking to time your runs to the frame, your splits will still be accurate to the nearest second as they have been.
- Should I start my splits at 1.33 seconds now? No, it’s still correct to start your splits at 0.00 and begin timing when you power your console on.
- Does this mean I can time from reset instead of power on? Yes, and your run won’t arbitrarily lose 1 second like it used to. That being said, it’s still recommended to time from power on unless something is physically preventing you from doing so.
- Will the existing leaderboard times be updated? This change will only affect runs submitted after this announcement. Keep in mind this is a very small timing change, so the accuracy of those previous submissions is not compromised.
- Does this affect emulator or VC runs? Nope. Emulator and VC will continue being timed as they were
- What does the first frame of the logo look like?
If you have any more questions, feel free to ask them in the SM64 speedrunning discord: https://discord.gg/0Si1OtnB7Ylmwkwr
