I added an image to the link to clarify the proposed functionality
The pitch is simple: We have filters; one filter can have numerous variables. But the filters allow the site users only to filter all but one variable per filter at a time. This works exactly the same when using a filter as a subcategory, but the filter displays as a single-click filtering choice at the top of a category. What I like about using subcategories as filters is that the subcategory button is directly between the category tabs and the time tables and that they are single-click to apply. The limitations are the same as filtering in the drop-down menu -- we can only select one. Is it possible to allow subcategory filters to have multiple defaults (ON) and multiple selections (ON)? This would the site user to more easily and view and select the runs they want to view.
This picture simplifies what I'm asking. https://imgur.com/gallery/BAegp
Background for the request I moderate Zelda 1, and we would like to improve our category layout but we can't serve our speedrunning community as well as we could with the suggested feature.
One issue is that the NES cart version of the game has slightly more slowdown than the Famicom (JP) cart version, but our community has a predisposition to running on the NES version. So we set the software version as a subcategory with the most popular one as the default because we didn't want to force everyone to buy Famicom versions just to compete.
Another issue is that it became more popular to run the game without using death warps. For example, we have Any% and Any% No up+A. We didn't want to invalidate deathless runs by merging the categories, nor ignore the fastest completion category. The game also has two quests that are run individually.
Zelda1 basically has six speedrun categories: Any%, 100%, Low%, Swordless, ACE (2nd quest, FDS only) and Extreme rules (which is semi-pacifist, swordless, low%, 100% map completion). For five of those basic categories we have two quests: First Quest and Second Quest. Then we have three deathless versions of categories on top of that. Altogether, we have 14 categories and each category still has 3 subcategories for software version.
What I'd like to be doing is bringing that down to 6 categories. 5 of those categories would have a "Quest" subcategory, a software version category, and a single subcategory filter for deathless that could be turned on of off.
I know that someone will give the opinion that using the drop-down menu to sort filters is good enough. I agree that for certain defaults like Showing Obsoleted runs it is great, and for sorting to view specific Hardware platforms as well. However, the issue we're trying to solve has to do with evenly conveying what the community deems important in terms of gameplay and guiding new viewers of the board in a way that is not off-putting or bloated looking while also helping the veteran users sort through runs quickly.
First and foremost, the reason for extra categories is to expand the community's enjoyment for speedrunning TLOZ with new types of challenges. I encourage you to participate in the community by joining the Discord, and following the game and its players on Twitch, and also to invite others to join you in this activity.
**Discord: https://discord.gg/n3SQKFs ** **Twitch: https://www.twitch.tv/directory/game/The%20Legend%20of%20Zelda **
GAME PLATFORMS The allowed official releases are listed in the left side panel. To date, all the official releases are allowed.
Play the NA English version if you can† The Japanese cart is the fastest version, but almost entirely due to text length which adds up to as little as 12 seconds in some full game categories. Otherwise the gameplay is nearly identical. Nevertheless, it is the fastest version. However, most of the leaderboard's users are using NTSC-U hardware, not NTSC-J.
There are a number of ways to play another region's version. Flash carts, pin adapters, imported game and console, etc, but those are more prone to failure than using native hardware. We don't want to negatively impact our runners by requiring them to spend more money and take additional risks for the sake of text differences.
Yet, fair competition is essential, and we'd also be as inclusive as possible. So, a little compromise required to make that work. Additionally, moderators don't want to re-time a lot of runs to keep it fair, so please use the English version if you can.
If a player is in the NTSC-J market, they may submit runs on Japanese language versions. Submissions in Japanese text may have their times adjusted based solely on the time difference between English and Japanese text.† So, for the sake of the moderators, please use the English NA version if it doesn't negatively impact your attempts.
†Japanese is used for Co-Op. Since it is emulation-based everyone has equal access to the fastest version.
EMULATION Unofficial NES emulation is allowed. No emulation of Gamecube, GBA, Wii, etc. Your NES emulator should be accurate. Here is a list of reasonably accurate emulators: Mesen, Bizhawk (Neshawk), Nintendulator, puNes, FCEUX, Nestopia. Get the latest versions. Don't use overclocking features, don't use lag helpers (e.g. RunAhead), don't remove sprite flicker by allowing more than 8 sprites per scanline. Don't use any features that don't exist on the original game
CATEGORY DESIGN / GAME OVER WARPING Speedrunning is measuring how fast you can get from the beginning to the end of a game. The whole idea of this board is still to do that, but add an unusual restriction or requirement that provides an interesting speed challenge. Adding "No Up+A or Deaths" restriction to beating the game has already been done. We'll be focusing on other ideas here.
Between attempts, you should always reset or power cycle the console. Failing to do so will change enemy drops, spawn positions, etc., and your run will be rejected because your game environment was not even with other players in the field. For Online Co-op, you should be disconnecting from your partner between runs so that item sync info is reset.
Take care to get a proper reset when using virtual platforms (e.g. Switch) or emulation-in-a-box (e.g. NES Classic Mini). If enemy formations on the same screen are different from run to run, that's a sign that their formation value is not resetting between attempts as it should.
VIDEO SUBMISSION GUIDELINES Complete video of the gameplay is required, including the last reset or power on. Please submit a Permanent Video -- Twitch Past Broadcasts are not permanent.
ViruseReturns, I think you are misunderstanding what PresJPolk is explaining. Here is an example:
Acmlm has on this board a 100 lines time of 3:56 with level 18 start. Acmlm has on this board a 100 lines time of 4:03 with level 0 start.
The current leaderboard settings will by default display only Acmlm's 3:56 time with level 18 start. Acmlm's 4:03 time with level 0 start will never become visible to each individual user unless the user specifically selects the Level-0 Starting Level filter from the list or the user specifically changes the Obsoleted Runs filter to "shown".
Here's my issue as a speedrun.com user with this requirement -- even assuming that the average user does like to mess around with the filters in order to get the information they are seeking (which is by a large amount not the case), it is not user-friendly. Every time the leaderboard page is reloaded the filters return to the default settings, not the settings the individual user most recently viewed. At least in Chrome, it is not possible to click on the various fields (such as the video link) in the leaderboard display and open the desired link in a new tab, so the user is constantly funneled into loading an entirely new web page in the same tab or navigating the web page in other inconvenient ways. This makes the filters (of which there are 33) far less desirable to use than the one additional tab requiring one click that every sensible leaderboard uses to sort its categories, which is how the board was organized through even last weekend.
Now, one user preferring 0-start or 19-start runs may be a matter of opinion, as may be preferring how the board is now. But, it is a matter of fact that the majority of the users here prefer 0-start and that they prefer it to have its own tab on the leaderboard without navigating the filters.
"So at this point with everyone combined; the 0 start times are basically bottom and everyone is now encouraged to run the fastest level possible to move up?"
In other words, rather than letting the majority of the community decide what way it finds competing enjoyable, one moderator (seemingly unilaterally) is trying to dictate how the community should be playing.
Manhandla gains one speed up stat on every frame that an appendage dies. If you kill three of them on the same frame he only gets one speed up.
Sprites are sorted a certain way in the ROM and the sprites are called based on if you are in a dungeon or overworld. So it's calling the overworld sprites instead of dungeon sprites.
The specific cause is having two different palette changes called on the same frame. In this case, a palette change is called on the frame an Armos goes live and moves and another is called by entering a dungeon staircase.
One very small thing to note is that between runs there should be a console reset or power on (this applies to emulators as well). Using "RETRY" in the death menu does not reset all current data. As long as I can see the death that led to the game over screen, I'm not going to reject runs based on this unless they are competitive times and gained an unfair advantage, similar to the "no death warps" rule.
For most games, when the system (the hardware) and game (software) is powered on the game's software tells the hardware to insert specific values into memory. These specific values determine some things that will happen in the game, such as where enemies will be placed and what they will drop. In The Legend of Zelda, the Retry feature on the death screen does not reset the global drop table (seen here: http://redcandle.us/The_Legend_of_Zelda#Drops), consecutive kill counters, enemy formations cycle or last recorder warp location.
So, it would be possible to route time savings before timing a run. In theory, this would include having a file with sword, recorder, bombs, and Triforces. You would visit specific screens to set up formations, kill a certain number of enemies to set up drop counts, and toot the recorder to set up its next warp location. Then you could Up&A retry, start your run and timer and reap your drop counts on favorable patterns. Combining all these things, pre-run manipulations could lead to saving even 10 seconds, but the setup between each run would be much longer.
Rules are not consistent across all speedrun communities. Example of strong manipulations and how communities differ on their use: In Final Fantasy (NES) the enemy encounters are pre-determined from a table that is the same every time the game is powered on; but when the RESET button is used the enemy encounters continue where they left off. In Final Fantasy IV, a value that changes every frame at the title screen is locked in when you press Start (aka a "seed"). Each seed changes the enemy formations and the number of steps between each encounter.
edit: 14November2017 -- same content, clearer more concise language.
We have created subcategories for this game's leaderboards to differentiate between certain program versions of the game. They are labeled as "FDS", "NES" and "FC" (Family Computer or Famicom), analogous to the system on which the versions were originally released. Note that this is different than the hardware or emulation software on which the run was performed. For example, one could run the FDS version on NES or Famicom using a flash cart but the appropriate subcategory is still FDS. All times will be sorted into their appropriate subcategory.
FDS will include all versions based on the Famicom Disk System ROM, notable for Japanese language and thinner font. The most relevant re-release version is for Wii VC which has the fastest loading times. ACE runs work only on this version. when viewing the ACE category, click the FDS subcategory to view the runs.
NES will include all versions based on the English language NTSC release, including PRG0 and PRG1 NES versions. This is the most run version because it is the most ubiquitous among NA speedrunners. As such, it is the default version in the listings.
FC will include all versions based on the Japanese cartridge-based release from 1992 on Famicom. This version is noted for having Japanese language but maintaining the thicker font face for numbers and Roman alphabet. Where applicable, this is the fastest version. For reference purposes, exact text time differences are tabled: https://goo.gl/t89Txm
I intend to improve this list to detail where all versions belong, barring discovery of any further changes. For now there are other resources on the subject including: http://redcandle.us/The_Legend_of_Zelda/Version_Differences https://tcrf.net/The_Legend_of_Zelda/Console_Differences www.google.com _
Background:
While it's long been known that the original Famicom Disk System release has longer load times entering dungeons and doesn't have as much general lag due to FDS hardware differences, the NES and Famicom versions were thought to be the same in all but language text differences and the reverted Pol's Voice vulnerability to arrows (irrelevant to most speedruns). Thanks to some disassembly done separately by Fiskbit and Zzewt, more knowledge has come to light about the differences between the NES release and the later Famicom cart release. The first difference relevant to speedrunning was a very small bug fix to shopkeepers, who prior to the Famicom re-release would hold on to timer values generated by enemies on the previous screen which could cause the shopkeeper to spawn up to 4 seconds late, though just under 2 seconds was normal in speedruns. Subsequently, strategies were developed to reduce the time loss from this bug in the NES versions, but the Famicom version is simply faster and easier.
Fiskbit's disassembly has been a tremendous source of technical information, providing us with the cause of many unintended behaviors and general knowledge about certain routines that are particularly burdensome on the CPU, such as HUD updates and pushing on certain objects like Armos (and also why the routine that should prevent Armos duplication fails). He also discovered that the Famicom version has engine improvements to fix minor graphical glitches that happen when entering caves and when changing rooms during an "adjacent boss roar." In the case of cave and dungeon loads, the fix adds one frame to load times.
In the process of discovering this info, Fiskbit hypothesized the cause of graphical glitches long present with my EverDrive running certain MMC1 games were related to NMI handler which is the subject of an engine change from NES to Famicom ROMs. This was evidenced by the Famicom version not presenting the same graphical glitch as the NES versions on my EverDrive. While testing that, I noticed that under conditions that in my near 30 years of playing this game would be likely to cause lag, that in the Famicom version the weapon sprites in the HUD would flicker.
Given what Fiskbit told us about burdensome HUD updates and engine improvements, I began to suspect that the engine changes may be reducing the gameplay lag present in screens with a high number of sprites. Subsequent speedruns on the Famicom version resulted in some unexpectedly fast split times where text differences were not involved (gold split from Silver Arrow to Gannon by 2 seconds). Obviously, that alone is wholly unscientific.
So I resolved to put this theory to the test in FCEUX running side-by-side the NES and Famicom versions in a room known for heavy lag, the 5 Blue Darknuts and 4 turrets room in Level-8, dubbed the Blue Lagoon by LackAttack. Over approximately 60,000 frames mostly spent holding Up+Left while running an invincibility cheat, the NES produced 1890 frames of lag to the Famicom's 864. This test was only meant to be a precursor to an RNG perfect test that would spawn the room with exactly the same RNG for posterity. However, this test alone was enough to convince the lead moderator that there is a significant difference between the versions that we could never accurately calculate.
While running the fastest and best version of the game certainly has its appeal, the general feeling in the community is that an arms race for the fastest version is not fun and/or that most people would prefer to play the version they grew up with (you know, if they grew up in an NTSC region). This change will also provide the opportunity and space to list FDS videos of non-ACE runs and perhaps even put some Japanese videos on the board.
question is answered here: http://www.speedrun.com/The_Legend_of_Zelda/thread/60qvp
"All times are welcome as long as they follow the rules. If you're going for a WR you'll want to try to get off of emulator and onto VC, Gamecube, NES, or similar. "
I put together a table with the text differences and here are the current results: (In all instances, the original English text version adds the respective amount of time)
any% Blue Candle routes: 164 characters, 984 frames, 16.373 seconds any% Red Candle routes: 121 characters, 726 frames, 12.08 seconds 100% routes: 275 characters, 1590 frames, 27.455 seconds low% routes: 112 characters, 672 frames, 11.182 seconds each Medicine Shop text: 1.398 seconds each Money Making Game text: 1.298 seconds
The any% results I got are different from anything listed on redcandle.us so I'm not sure if I've made a mistake or not. I put my table on a google doc though. https://docs.google.com/spreadsheets/d/1Gaa4Ta4U5_X3iqGfeXUOJdfvLLGZjaiXT4DZaIr7o8g
I'm wondering if we're going to adjust times accordingly for Japanese (cart) version submissions, noting in the rules that adjustments will be made for text differences.
Offering to chart the differences for every cave's text if that data isn't already available somewhere, and handle those submissions as a mod if no one else wants to.
edit: This proposal may seem like it's taking the subject too seriously, but my interest is in keeping speedrunning this game simple and inclusive for newer players. By informing them that it doesn't matter on leaderboards which NTSC version they play because text times will be adjusted, there will be no need for newer players to have a hardware arms race.
2nd edit (May 9 2017): Famicom version probably has significantly less lag. We made subcategories. See new thread.
