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

Chest Appearance Does Not Match Contents #1950

Closed
wants to merge 1 commit into from

Conversation

fenhl
Copy link
Collaborator

@fenhl fenhl commented Apr 1, 2023

This PR adds a “Chest, Pot, Crate, & Beehive Appearance Does Not Match Contents” setting that inverts the effect of the “Chest Appearance Matches Contents” and “Pot, Crate, & Beehive Appearance Matches Contents” settings (the latter only if set to “Texture (Match Content)”) so that the appearance of each container will be randomly chosen from all possible appearances except the correct one for the item it contains.

For example, if “Chest Appearance Matches Contents” is set to “Texture”, a boss key can be in a wooden (junk item), gilded (major item), silver (small key), webbed (token), or pink (heart) chest, but never in a golden (boss key) chest, and if “Pot, Crate, & Beehive Appearance Matches Contents” is set to “Texture (Match Content)”, a beehive will wiggle if it contains a junk item.

I was originally going to seed the randomization using the randomizer seed xor'd with the override key of the container, ensuring that each container's appearance remains consistent across reloads. However, I ran into an issue where numerically adjacent seeds appear to yield identical random values, and containers that are physically close to each other tend to have similar override keys. So now the override keys are byteswapped before being xor'd with the randomizer seed, which seems to result in the randomization working properly.

The chest types that can be selected do not account for whether such a chest could normally be in that location, but do account for the size of webbed and pink chests (which depends on win conditions). This is similar to how ice trap cloaks behave.

Depending on settings, there are up to three chests (Ganons Castle Light Trial Lullaby Chest, Spirit Temple Compass Chest, and Spirit Temple Silver Gauntlets Chest) which are moved depending on their size. These are special-cased so a chest type whose physical size does not match that of the item's normal chest type is always selected. For example, if the non-MQ Spirit temple's compass chest is a small key, it can only appear in a gilded, golden, or (depending on wincons) webbed or pink chest.

Special thanks to @rrealmuto and @mracsys for unwittingly assisting with this PR.

@fenhl
Copy link
Collaborator Author

fenhl commented Apr 2, 2023

April Fools!

While I do think this setting can be interesting to play with for a bit, having the randomizer deliberately mislead players like this is probably not something that should be an option without plando (with the exception of ice traps, which though heavily adapted are based on a vanilla mechanic). This setting continues to be available as a hidden (plando-only) setting on my branch. I make the distinction of allowing it for plando because there's precedent with plando authors being allowed to place arbitrary text on gossip stones, including false information. The dev-fenhl version of the feature is also adapted to be compatible with per-world settings, which also allowed me to make the appearance of webbed chests conditional on token shuffle.

I'm closing this PR since the reaction to #1804 gives me the impression that this is unlikely to be wanted for the main fork. If I'm mistaken about this, just let me know and I'll reopen and make the adjustment to remove it from the GUI. The setting did receive rather extensive testing for a joke PR and I'm confident that it's working as advertised.

@fenhl fenhl closed this Apr 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant