Where can I find an explanation or info regarding what is going on in the top 2  any% runs (16:38 and 16:40) and how to perform the tricks. They are on N64 and the route is completely different than all the other any% runs but I can't  find any info on it online. All the any% videos and routes are outdated it seems.

Can I have the 5 minutes of my life I spent reading this back?

Glad you guys added this rule, I actually noticed this awhile ago that the fps would go up during loading zones when "limitfps" is unchecked. But never used it to my advantage as I felt it was cheating/unfair.

Thanks for the response Alaris, you're dope

I've personally done comparisons between 1.6 and 2.3 and through my research my conclusion is 2.3 is in no way faster than 1.6. However 2.3 is alot more stable and runs better. I've done runs at a high level on both emulators and there is no significant difference in split times or xcam times. Runs on 1.6 or 2.3 have the exact same split times.  No difference at all. So 1.6 being the only emu allowed is super obsolete and needs to be changed to support  newer and more stable versions of PJ64. As mentioned 1.6 is literally like 15 years old and is far from being perfect. Actually runs like complete shit, Every "top" emu runner will tell you this. Your only other option is to spend hundreds of dollars on an actual n64 set up

https://www.twitch.tv/videos/1261935701
I believe this is faster than the current set up in the WR and imo its easier

My top 5 16 star emu run was verified yesterday and im listening to music the entire vod. Long as game audio is audible youre good. background music/sound is fine.

Super Mario 64

The Legend of Zelda: Majora's Mask

SM64 Sapphire

We are updating the emulator rules to explicitly ban the ‘Limit FPS’ setting from being unchecked. Normally, this setting is easily detectable (PJ64 would run at an absurd FPS), and it was commonly accepted that this wasn't allowed. It has since been discovered that with multiple different audio plugins (Shunyuan HLE Audio, or azimer 0.70 with prevent buffer overruns enabled are two known examples) and having the 'Limit FPS' setting unchecked, the game runs at a normal frame rate EXCEPT for during the loading zones, where it wasn’t operating under the FPS cap.

As a result of these circumstances, some runners were artificially gaining time on every loading zone, which over the course of a run adds up to quite an unfair advantage. It is important to understand that this setting could be enabled by complete accident through the F4 hotkey, and the game would be seemingly running normally everywhere that wasn't a loading zone. We want to make this distinction clear, as we don't want anyone to think we are accusing them of intentionally breaking the rules. Here is an example video that visualizes this issue/provides proof of the advantage (1:05 shows the direct comparison): https://www.youtube.com/watch?v=kO9_gijLxo4

Going forward, we have decided that the only fair course of action is to remove any runs from the leaderboards that have been found to have this loading advantage from the FPS being uncapped. Our reasoning for this is the following:

-it is essentially overclocking the emulator during loads, which conceptually would not be allowed if discovered on any platform, regardless of the previous verification status
-it is 100% conclusively and consistently detectable in any run, as it provides the same advantages every time when compared to normal loads, and is enough of a difference on each load that it simply cannot be argued as a recording related issue

Since there is several thousand emulator runs currently on the leaderboards, in the interest of getting this announcement out there, we have only checked runs that have either been noticed by us, or are below certain threshold times: 0 Star and 1 Star sub 9:xx, 16 Star sub 17:xx, 70 Star sub 52:xx, and 120 Star sub 1:55:xx. If you come across a verified run that you believe to have this issue, feel free to contact one of the moderators and we will look into it. Additionally, we will be checking every newly submitted emulator run for this issue, and have updated the emulator setup guide to provide specific warnings/discourage the use of the affected plugins.