Conversation
|
this looks really cool, seems like it could probably be utilized to address issues like #2200 too! |
c79de7a to
a50623c
Compare
a50623c to
9bbf158
Compare
|
@briaguya-ai / @leggettc18 want your opinion on something. With these new changes, the reward from the boss is given after the blue warp (this is very much intentional, and I intend to stick with this). I just realized however, a side effect of this is that dungeon items that are on the boss reward are now not handled properly unless dungeon items are set to anywhere, mostly due to how we don’t use the “dungeon specific items” unless they are set to anywhere or outside of dungeons. I know there have been some on and off convo’s about this, but would you be opposed to always using the dungeon specific items? Even if dungeon items can only be in their own dungeon? |
I'm not opposed to using dungeon specific items, I am opposed to things always having dungeon specific text and colors. I think the custom message system is robust enough that we could build out logic to handle conditionally displaying generic messages when items aren't shuffled outside of their own dungeons, i'm not sure what it'd take to handle the key colors though. |
update bluewarp handling for entrance rando
| // Moved to links pocket condition (awards light medallion) | ||
| // Flags_SetEventChkInf(EVENTCHKINF_PULLED_MASTER_SWORD_FROM_PEDESTAL); |
There was a problem hiding this comment.
This doesn't seem right. Links pocket isn't necessarily the "dungeon reward", unless you set rewards at end of dungeon.
If this needs to be limited to that condition, could probably be under a
if (Randomizer_GetSettingValue(RSK_SHUFFLE_DUNGEON_REWARDS) == RO_DUNGEON_REWARDS_END_OF_DUNGEON) { ... }
Ultimately though, it is not clear to me why this flag needs to be conditionally set for light medallion. Can you clarify?
There was a problem hiding this comment.
The “awards light medallion” is really just referring to the vanilla logic item behind this check.
This flag was previously used to skip the cutscene that plays the first time you pull MS (which is where you would get the light medallion in vanilla)
Now that cutscene is skipped in z_demo, and this flag is used in the ItemGiver mod to award the links pocket check.
This will allow us in the near future (after some logic tweaks) to award the links pocket check the first time you travel to adult. This should obviously be optional in the name of parity with OOTR, but IIRC the only reason the concept of “links pocket” exists is because of limitations we don’t have, we just inherited it.
|
Closing, this will be succeeded by an upcoming PR targetting |
This PR aims to clean up some of our randomizer item giving logic, unifying patterns, removing some of our reliance on treasure flags, and moving some of the code closer to it's original source.
Pieces of this have come from #2824, as you will see we are now accounting for !rando in some places, but I think that PR still has some larger UI work that will block it for a while, and I want to get these playtested/merged separately
TODO:
Summary of changes:
z_demoto skip cutscenes and the ItemGiver below for giving the itemsItemGiver
This is a new pattern introduced for ensuring the player receives an item, can be useful for cutscene skips, CC, starting with items, multiplayer, etc.
The gist of it is pretty intuitive, you need two flags to give an item, one to determine if the item should be given to the player, and another to determine if the player has received the item already. If you have some sort of logical or cutscene or scene entrance requirements they don't belong in the ItemGiver, that should be handled elsewhere, and simply set the should flag.
Build Artifacts