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

Core: Set locality rules after set_rules stage. #2044

Merged
merged 2 commits into from
Jul 29, 2023

Conversation

ThePhar
Copy link
Member

@ThePhar ThePhar commented Jul 27, 2023

What is this fixing or adding?

If games reassign Location.item_rules in set_rules or generate_basic, then local and non_local item rules will be "overwritten".

For example, Clique sets an item_rule in set_rules (made sense to me), but another player set an item as "local_only". In the seed generated, it may still ended up on the Clique location.

Since there's doesn't appear to be consensus that item_rules should not be set after create_items, this should prevent weird behavior if that were to occur up until item plando and fill stages, where I argue this chance should be less likely.

Since

How was this tested?

Ran unit tests and seed with known placement error, and misplacement disappeared.

If this makes graphical changes, please attach screenshots.

Spoiler:
image
image

Before fix w/ same seed:
image

After fix w/ same seed:
image

@ThePhar ThePhar added is: bug/fix Issues that are reporting bugs or pull requests that are fixing bugs. affects: core Issues/PRs that touch core and may need additional validation. labels Jul 27, 2023
@ThePhar ThePhar changed the title Core: Set locality rules to apply after generate_basic stages. Core: Set locality rules after generate_basic stages. Jul 27, 2023
@Berserker66
Copy link
Member

rules, this includes item_rules, should be set by the time set_rules is done.

@black-sliver
Copy link
Member

If I understand berserker correctly, I agree that the block you moved should instead be right after AutoWorld.call_all(world, "set_rules") so that all rules are set before entering the next stage.

Looking at the blame it seems like this was originally specifically added for HK and then simply stayed there with no specific reason, so moving it is probably fine?

@ThePhar
Copy link
Member Author

ThePhar commented Jul 28, 2023

So we're all in agreement basically?

I moved it after generate_basic for those who did everything in generate_basic for whatever reason. That is the absolute latest, I'd expect rules to be updated.

@el-u
Copy link
Collaborator

el-u commented Jul 28, 2023

Basic is specified as being for things that don't affect logic, so I agree with Berserker and black-sliver.
And I guess having the locality rules in the same place as the exclusion rules (i.e. after set_rules but before generate_basic would seem natural.

@ThePhar ThePhar changed the title Core: Set locality rules after generate_basic stages. Core: Set locality rules after set_rules stage. Jul 28, 2023
@ThePhar
Copy link
Member Author

ThePhar commented Jul 28, 2023

Whatever, most important thing is it's after set_rules, so changed PR accordingly.

@ThePhar ThePhar merged commit 672a97c into ArchipelagoMW:main Jul 29, 2023
@ThePhar ThePhar deleted the move_locality branch July 29, 2023 02:06
FlySniper pushed a commit to FlySniper/Archipelago that referenced this pull request Nov 14, 2023
* Core: Set locality rules after `generate_basic`.

* Move locality rules to before `generate_basic`.
kl3cks7r pushed a commit to kl3cks7r/Archipelago that referenced this pull request Dec 15, 2023
* Core: Set locality rules after `generate_basic`.

* Move locality rules to before `generate_basic`.
Jouramie pushed a commit to Jouramie/Archipelago that referenced this pull request Feb 28, 2024
* Core: Set locality rules after `generate_basic`.

* Move locality rules to before `generate_basic`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects: core Issues/PRs that touch core and may need additional validation. is: bug/fix Issues that are reporting bugs or pull requests that are fixing bugs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants