Skip to content
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

lufia2ac: prevent double checks #3154

Merged
merged 1 commit into from
Apr 18, 2024
Merged

Conversation

el-u
Copy link
Collaborator

@el-u el-u commented Apr 15, 2024

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

  • Generate a game with shops enabled; play till you reach a shop
  • Highlight any item in the shop, then leave the shop screen
  • Go find a blue chest (in the meantime don't open any red chests and don't receive any multiworld items)
  • Stand next to the blue chest and mash the A button

Scenario 2

  • Completely fill up your inventory
  • Open a red chest that gives you an item you can't carry, then leave the full inventory management screen
  • Go find a blue chest (in the meantime don't open any red chests and don't receive any multiworld items)
  • Stand next to the blue chest and mash the A button

@github-actions github-actions bot added the waiting-on: peer-review Issue/PR has not been reviewed by enough people yet. label Apr 15, 2024
@Berserker66 Berserker66 merged commit 233eba6 into ArchipelagoMW:main Apr 18, 2024
10 checks passed
@el-u el-u deleted the lufia2ac-main branch April 18, 2024 20:59
qwint pushed a commit to qwint/Archipelago that referenced this pull request Jun 24, 2024
AustinSumigray pushed a commit to AustinSumigray/Archipelago that referenced this pull request Jan 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting-on: peer-review Issue/PR has not been reviewed by enough people yet.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants