Shuffle dungeon rewards

[fenhl]

Fixes #265. Fixes #1250. Fixes #1318. Closes #1833.

Special thanks:

• To @Nax who wrote the code for splitting the dungeon reward models into individually addressable blobs as part of the OoTMM project, which was required to fit them into the get item memory slot.
• To @mracsys who identified and fixed a bug in my translation of that code and contributed the code for rendering the models.
• To @engineer124 who contributed the changes to blue warps.
• To @rrealmuto who contributed the change to the Big Octo item model.

Issues keeping this in draft state

• The interaction with pre-completed dungeons needs to be tested. I think the behavior that makes the most sense would be to give rewards in pre-completed dungeons as starting items with “Vanilla Locations”, “Own Dungeon”, or “Dungeon Reward Locations”, and prevent them from being placed in pre-completed dungeons otherwise.
• The item model in the Big Octo cutscene needs to be updated to support non-dungeon-reward items. An implementation of this should ideally not simply check the override of the boss location behind the Jabu boss door, so it can work with mixed pools boss ER as well. Instead, an override value could be written to a new symbol specifically for this purpose by the section of Patches.py that already handles the text box.

Nice to have

• There is a bug where a blue warp can fail to activate after its item is received. Reloading the boss room will fix the blue warp but also duplicate the item. Even though the blue warp changes have been enabled unconditionally on my branch since January 2023, there have only been 2 reports of this happening as of May 2024, and I have been unable to reproduce it, so I think this is something that will have to be debugged on main Dev. Tracked as Blue warps sometimes don't activate #2230 and fixed in Adjust blue warp item behavior #2251.
• The Big Octo item model changes should work with ice traps. With this PR, the text box is changed to “Princess Ruto is a FOOL! But why Princess Ruto?” which has the advantage of not potentially requiring a bunch of additions to the censor list. So the item model should behave like freestanding items picked up by Link: It should display as the ice trap's cloak while it's on the ground, and disappear once picked up by Ruto if it's an ice trap. I also think it would be funny if we could freeze Ruto and skip the rest of her dialog, but that's probably really difficult to implement.
• This PR includes a Boolean setting to control whether the Links Pocket/ToT Reward from Rauru location is skipped, but it should be extended to add an option to skip it but force it to be a dungeon reward, as described in Shuffle dungeon rewards #1833 (comment). Tracked as Option to force skipped reward from Rauru to be a dungeon reward #2225.
• For convenience, we may want to have the Sheik in Kakariko cutscene trigger even if you receive the last of the 3 required medallions while you're already in Kakariko as adult. Tracked as Trigger Sheik in Kakariko cutscene while already in Kakariko #2226.
• Multiple people have requested a variant of the setting where there can be a maximum of 1 dungeon reward in each hint area. This could be implemented as a separate toggle, displayed with dungeon rewards set to “Overworld”, “Any Dungeon”, “Anywhere”, or “Regional” (where it would prevent a stone and its corresponding medallion from being placed in the same hint area). Tracked as Add “At Most One Dungeon Reward per Hint Area” setting #2228.

[fenhl]

@engineer124 said this about the blue warp activation/dupe issue:

Interesting, I’d guess it’s very precise then. I had one idea but never got around to testing. Both blue warp and getItem have separate ranges. I was wondering maybe if you grab the item on the very edge of the range, would it be in range if the GetItem but outside the range of the blue warp? I could be off base. But you could increase the range to test and it should be easier to get the glitch. And likewise maybe decreasing the GetItem range would fix it? Just a random idea though, never got around to testing

[r0bd0g]

I think the bug where loading zones don't work for a while after arriving from a blue warp is too intrusive and probably does have to be fixed, if it hasn't been.

I don't like that the get item changes the optimal way to enter the Jabu blue warp. Honestly maybe there's some way to just remove the part where you have to turn and face Ruto.

[fenhl]

I've tried decreasing the distance check in DoorWarp1_PlayerInRange to 30 units and increasing it to 120 units (the actual value in this PR is 60 units) and was unable to reproduce the bug where the blue warp fails to activate either way.

[fenhl]

This PR replaces the vanilla blue warp cutscenes with custom implementations that currently explicitly set time of day to match vanilla behavior. We should consider not setting time of day in some situations (e.g. if the blue warp goes to an area where ToD doesn't pass, or if the settings are such that it might) to reduce nonrepeatable ToD access, which can lead to nonrepeatable access to the Spirit temple for one age, which can lead to softlocks.

[fenhl]

After some more discussion regarding the ToD changes, I think the best course of action would be to make them repeatable, i.e. have blue warps also set ToD on repeated use. It removes the nonrepeatable access, it doesn't affect anything in most situations since you normally don't take a blue warp twice, and it makes a potential future blue warp ER setting a bit more unique rather than just adding 8 additional owls.

[cjohnson57]

These feel like they should all be a single function with a switch statement, but I'm not sure if that's easily doable within the context of the ASM functions that are being overwritten

[fenhl]

Just from looking at the asm, I don't think it's easily doable, since each of these functions are called from different locations. Maybe @engineer124 has an idea for how to do it?