-
Notifications
You must be signed in to change notification settings - Fork 563
Fix OnItemReceive hook for items in the extendedVanillaGetItem table #3063
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix OnItemReceive hook for items in the extendedVanillaGetItem table #3063
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one minor thing, then I think it's ready.
9f69d0f
to
d5fef77
Compare
d5fef77
to
4f5c9ea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super happy to see things move to enums from ints, left a little comment about the _MAX
usage
if (ItemIDtoRandomizerGetMap.contains(itemID)) { | ||
return ItemIDtoRandomizerGetMap.at(itemID); | ||
} | ||
return RG_MAX; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the reasoning behind using RG_MAX
here? it seems like it's being used to mean "invalid", so maybe it makes sense to add RG_INVALID
to the enum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my limited experience in Cpp land, I've seen ENUM_MAX be used to communicate an invalid value, as well as doing arbitraryValue < ENUM_MAX
to validate it's a valid option before continuing (eg: we're doing this a few times with this enum in z_actor.c)
Would this also depend on whether we wanted to maintain separate tables? Though, if it doesn't change anything else, I wouldn't mind adding it or the other one in the meantime to make maintaining Anchor easier while we work on the refactor. |
If you're meaning whether or not we want to merge the extendedVanillaGetItem into the randomizer table, then yes. But I don't think that will happen before v3 |
5f0082b
to
03d7d15
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
03d7d15
to
e28b382
Compare
Currently both the OnItemReceive and OnSaleEnd hooks are receiving inaccurate information about the item that was received if the item belongs to the extendedVanillaGetItem table.
For example if you receive the kokiri emerald, as far as the hooks are concerned you recieved a bottom of the well small key, because the table lookup is done with the ItemID instead of the GetItemID
Getting the Kokiri Emerald:
Build Artifacts