Home

Wishes v3/v4/etc

1. Source Interaction

• Different approach for giving items, one that can be used for all (most?) checks - rando changes branch is the proof of concept for this
• Piggy-backing on the above ^ attempt to be less invasive on vanilla code paths in every way possible
• ^ Also a piggy back. Cleaner ways to hook/replace original code functions for rando code paths (less in line changes, and more of a patch/redirect to handle the rando ideas) (ala 3ds rando patch system maybe?)

2. Data Optimization/Unification

• Unify all randomizer data structures under one umbrella (ala CheckTrackerData to CheckData)
• De-duplication - Creating a new option, check, item, etc should be as seamless as possible, I should only need to define things in one centralized place, one time
• Do we really need extendedVanillaGetItemTable? I get how those items are different, but is there any benefit to doing what we do now instead of them all just having a custom item entry in the randomizer table?
• Internals of randomizer playthrough utilize gSaveContext to simulate game playthrough (this will have benefits post-generation, and simplify some of our code, i think)
• Convert rando code to utilize SoH data structures, or other way around (target: live playthrough for check availability)
  • things like RCObjects as class with function members
• Extensible language support (more than just "OoT" languages)
  • 3DS Rando doesn't support German at the moment, and with PAL ROM support done, NTSC and the eventual Japanese translation will be next.
    Also, we should be able to make it so that the hints and such can be created on file create, or even on the fly, instead of relying on hint text in the spoiler, that way people who share spoilers across primary languages can still get the rando texts in their language.
• Spoiler file generation becomes optional
• Spoiler file settings section 1:1 with randomizer setting cvars
• Change spoiler logs to have both human friendly data, and computer friendly data, so we don't have to worry about doing parsing. Or at least have the "strings" be defined once so that typos aren't possible between parsing and spoiler log generation.
• Name parity with Archipelago (for spoiler file loading)
• What this might look like in practice

  RandomizerCheck rc = Randomizer_GetRandomizerCheckFromActor(this->actor.params, play->sceneId);

  if (rc.isShuffled()) {
    if (rc.isObtainable() && !rc.isObtained()) {
      this->actionFunc = En_CowIdle;
      rc.obtain();
    } else {
      this->actionFunc = En_CowReturnToIdle;
      this->actor.textId = 0x4011;
    }
  } else {
    this->actionFunc = En_CowCheckEmptyBottle;
  }

Logic

Rewrite logic to work based on a "room by room" basis with clear indications as to what is needed to beat the room. E.g. rooms which need certain enemies defeated to progress will have Can_Defeat(ENEMY_STALFOS, numEnemies).

General Rework:

• Currently certain sections of dungeons, particularly in Master Quest, will have logic which assumes you already have certain items or are adult/child at that point in the dungeon and will not include logical conditions for these items anymore (already currently an issue in fire temple with trick logic)
• Logical item conditions will often not use the CanUse() in cases where it should, or does but is not clear that IsAdult or IsChild is a necessary condition but is implied through the item conditions use
• This is absolutely necessary for the introduction of glitch logic
• This is also necessary to allow for inclusion of timeless equipments, but also for the significant rework that more easily implementing equip swap would require
• Ice traps -> traps
• Support latest DJ formats for sequences (i think they allow custom samples now?)

Playthrough Rework

• Refactor rando code to align with n64 code patterns/structures (not features)
  • One example is playthrough calculation/multiworld considerations so that things like Archipelago or multi-world are easier/free thanks to n64 kicking things off
• Built-in multi-playthrough logic support (multi world)

Enemy Defeating Rework:

• This is not necessary for glitch logic
• Currently the code is very inconsistent as to the clear conditions for rooms based on what enemies are in them, and often this makes it very difficult to understand the logic as well as know what to write for certain sections
• The aim here is to standardise the conditions for beating a room and make clear when certain oddities arise e.g. fire temple bk loop has a chest requiring adult but is not made clear by the code as only adult is expected to beat the flare dancer in other sections of the code.
• My personal hope for this is to potentially help a future for seeded enemy rando logic

Eventual Glitch Logic:

• Currently have notes up to fire temple but holding off until the general rework is implemented
• V1 glitch logic aims to include all major glitches excluding wrong warping/void warping/text transfer glitch/item manipulation/srm etc.
• Unlike the current n64 glitch logic (which is currently undergoing a rework) individual glitches will be toggleable with difficulty tags for each, as is done in trick logic currently
• V2 would aim to have closed/challenge option where woth items are delayed in the playthrough

General Gameplay

• Don't start twinrova flight until we get into the room (GH issue)
• Allow dpad boots in all situations (GH issue)

Hints

• Hint distribution/options parity with zootr (I'm not super familiar with this, but people always complain "our hints arent like zootrs") (something to consider is Peperoni is trying to do something around this)
• Why are gossip stones considered checks in some contexts?
• Dynamic hint - dynamically finds a woth item within reach

Developer Experience

• json junk hints (possibly loaded from soh.otr during seed gen?)
• Text box custom syntax (GH issue)
• Logic testing framework? (n64 does snapshot testing for example)
• Improvements to custom message system:
  • Most messages should be created on the fly (also means not adding them to the spoiler - Malk)
  • Messages expanded to support 4 languages (japanese)
  • Auto line break based on length

UI/Menu Interaction

• Move/refactor settings collision logic/setting group randomization to one place (think of indicating in the UI that a setting can't be toggled, but also the logic doing that for us. Currently 3ds does some safeguards for example)
• Randomizer settings UI is data driven (title, description, and combobox options come from tables, not hardcoded)
• Graceful handling of seed generation errors (ideally with useful error messages to help people adjust settings so it won't fail next time)
• Possible stretch goal: have pre-generation validation of settings?
• MUCH better error handling and messaging around seed generation and failure
• Full starting inventory options (GH issue)