Please read
This is a working page for me to work on the new wiki page for glitch logic 2.0, so that we can preserve the page for 1.0 until 2.0 has released.
Please do not treat this page as an accurate resource for glitch logic 1.0. While it should be a helpful resource for learning glitches in general, it should NOT be treated as a 100% accurate picture of what's currently expected for people playing 1.0, as 2.0 will expect additional tricks and have a significant number of changes.
Please also remember that this is a work in progress. I cannot promise that it will be 100% accurate for what's currently expected in 2.0, due to delays in updating the wiki and due to the fact that I may make changes here before making them to the actual code. I will do my best to keep this page accurate, but I cannot promise it will always be accurate. Because this page may be ahead of 2.0, please do not modify this page - especially to remove or correct information - without notifying me first. A simple notification in #dev-glitch-logic is fine. If you just want to fix the formatting for something (because it'll probably suck because I don't know wiki formatting yet) then that's fine, just please do not change the underlying content without letting me know.
Thank you for reading, and for your patience in me working on this.
Regards, Dusk the Umbreon
Glitch Logic is a different set of logic files to the normal Glitchless Logic files. These take into account a massive amount of tricks, glitches, clips, etc. for placement of items throughout the world. This option is a somewhat middle ground between the Glitchless Logic, which expects only what the player can normally perform with no special knowledge, and No Logic, which randomly places items throughout the world without regard to potential softlocks. This set of logic files was designed around the DDR and No IM/WW rulesets.
Guidelines
As the No IM/WW ruleset is effectively the upper limit of what can be allowed while still remaining platform-agnostic and within the purpose of rando, anything outright banned by that ruleset will never be logically considered.
Additionally, logic itself must be strict enough to stop players from softlocking themselves except through significant and deliberate self-sabotage. This means every glitch must be infinitely repeatable (i.e. the player cannot be locked out of it) until it is no longer relevant.
- However, glitches CAN still be allowed if you must execute the glitch in a way which we have clearly stated can lead to a softlock (e.g. using damage boosts/hovering/various other glitches to skip waking Talon, or doing DoT skip without a way to return) and which requires deliberate action on the player's part to cause the softlock (e.g. cannot be done through mere poor execution).
Finally, several glitches are excluded for either keeping the logic bearable to use (as they are overly RNG-reliant or simply absurdly tedious or precise) or because they violate the spirit of rando.
These criteria mean that the following glitches are never considered in logic:
- RBA, BA, GIM, WWs, and SRM - Not in logic due to No IM/WW requirement. Use of them may lead to a softlock.
- Accessing child Zelda without waking Talon/Skipping weird egg - Not in logic due to softlock potential. Do not do this, ever. Many glitches allow this to be done, but doing so can lock you out of a significant number of checks. If you ignore this warning and get softlocked by doing so, we may not be able to help you without save editing. For your safety, ALWAYS wake Talon up and move him by talking to him before going to child Zelda.
- Collection delay - Not in logic due to non-repeatability. Certain applications (e.g. the hookshot jump to FAs) are still safe to use, however, other applications may lead to softlocks.
- Any system-exclusive glitches - Not in logic due to No IM/WW requirement. These should all be safe to use if you want.
- Currently, this only includes OoB chus, which crashes n64 and all n64 emulators.
- Note: sticks as adult has been patched to NOT be exclusive to VC, and therefore can be in logic.
- Superslide teleport - Not in logic due to non-repeatability (cannot be used if player has strength).
- Blank A - Not in logic due to non-repeatability (cannot be used if player has equipped sword).
- Note: There is a method that doesn't require a blank B button. This may be required in logic, but is still under consideration.
- Item/location/bottle duping - Not in logic as it violates the spirit of rando. Overwriting items (yes, even your claim check!) may lead to softlocks.
- Hovers involving more than 20 bombs and 50 chus - Not in logic due to technical reasons. Logic considers all three levels of bomb bag to be equal. While we could change this, it would likely lead to a worse experience overall.
- Most glitches that involve enemy manipulation - Not in logic due to RNG. Most enemies are hard to manipulate reliably, and glitches involving them are generally awful. The exceptions that exist are either grandfathered in from glitch logic 1.0 (all of these are exclusive to All Uses Enabled) or involve stationary or very easy to predict enemies, such as gold skulltulas or withered babas. These are all safe to use.
- Actor pushes, unless a reliable setup exists. Not in logic due to absurd difficulty and precision. These are all safe to use.
For tricks, as an initial guideline, we use the DDR ruleset as the upper limit for what can be in base logic, as that ruleset's goal and the goal for the base level of glitch logic are the same (providing a more casual-friendly glitched experience). Anything that is banned by DDR must be a trick (or outright excluded from logic, if excluded above) for this reason.
All tricks from glitchless logic must be in base logic, unless the trick's difficulty changes significantly within the context of glitch logic.
Aside from those two, difficulty is the primary factor for what is and is not a trick. More precise or complex glitches will generally be tricks. Specific glitches which are significantly harder than the basic trick (e.g. itemless forest escape, which is significantly harder than the other methods of forest escape) will be made part of the "All Uses Enabled" setting.
Obscurity of a glitch may be a factor in whether or not a glitch is a trick. Exceptionally obscure or counterintuitive glitches may be made into tricks. The majority of these will be listed here rather than being trickified, however.
The consequences of failing a glitch are also a factor in whether or not the glitch is a trick. If a glitch causes a notable amount of damage when failing, or requires a significant amount of time or ammo to retry, it will likely be a trick. Additionally, if any failure of a glitch (even if said failure must be deliberate and against specific instructions) could possibly lead to a softlock, it must be a trick.
Finally, the tedium and/or required reading for a glitch is a factor. Exceptionally tedious glitches, or those that require consulting a chart, detailed instructions, or specific information before executing (e.g. heap fragmentation, which is both tedious and has required reading) will generally be tricks.