Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is this fixing or adding?
In some specific situations, blue chests could quickly be interacted with multiple times to trigger multiple location checks.
https://clips.twitch.tv/RepleteThoughtfulZucchiniDatBoi-mncfy1Px2GTQiDE5
Technical stuff
The cause:
If 0x09CF is nonzero at the end of a chest interaction, the chest will not be marked as permanently non-interactable, but until now the multiworld chest code did not set this value at all
Why this didn't manifest as a larger scale problem:
- Interacting with a red chest initially stores the item ID at this location, but it is cleared again when the item is received
- The item get that usually happens shortly after interacting with a multiworld chest also clears it (sadly there is a delay because this requires client-server-communication...)
- Interacting with a blue/multiworld chest skips most of the chest code and (before this change) didn't modify that memory location, so if it was zero before (as it usually is due to the first two points), it will still be zero at the end
The situations where this problem became noticeable are those where 0x09CF is left in a non-zero state:
- Shops just always leave the last selected item ID at that position (coincidental unrelated use of the same memory address)
- Interacting with a red chest and NOT getting the item (i.e., when inventory is full) leaves the item ID there to indicate that this particular red chest should be kept interactable
After any of that, since blue/multiworld chests didn't previously overwrite 0x09CF themselves, they would then also be treated as still openable
Therefore, if the player managed to use the chest multiple times in the timespan of the delay between the initial interaction and the response arriving with the item to display, then multiple checks could be triggered
The solution:
Make multiworld chests jump to a different part of the existing code, where 0x09CF is cleared
How was this tested?
In both of the following scenarios, games generated on main could trigger double checks,
while games generated with this change should only ever result in one check per chest:
Scenario 1
Scenario 2