Core: Skip directly collecting placed items in get_all_state() - #6335
Open
Mysteryem wants to merge 1 commit into
Open
Core: Skip directly collecting placed items in get_all_state()#6335Mysteryem wants to merge 1 commit into
Mysteryem wants to merge 1 commit into
Conversation
Depending on when get_all_state() is used, items in `multiworld.itempool`, or from a world's `get_pre_fill_items()` could already have been placed, meaning that `get_all_state()` could collect these item instances twice. This changes `MultiWorld.get_all_state()` to skip directly collecting items that have already been placed. This does not fix all issues with `MultiWorld.get_all_state()` at all generation steps because some worlds create new `Item` instances every time their `get_pre_fill_items()` is called, but collecting a few pre_fill items twice generally doesn't cause problems, otherwise we would see many more generation failures from the vast number of worlds that currently use `get_all_state()` within the `pre_fill` step. This fixes ArchipelagoMW#6333. This fixes ArchipelagoMW#6334.
github-actions
Bot
added
affects: core
Mysteryem
added a commit
to Mysteryem/Archipelago-ahit
that referenced
this pull request
Jul 18, 2026
Similar to using `multiworld.get_all_state()` after core AP's main fill is complete (see ArchipelagoMW#6335), using `multiworld.get_items()` after core AP's main fill is complete is another common 'gotcha' that apworld developers fall for, not realising that it will end up returning a list containing most items twice. This changes `multiworld.get_items()` to only return items from `self.itempool` that are not placed, therefore avoiding the issue of returning an item twice if it is both placed and in `self.itempool`, which often occurs after core AP's main fill is complete. There are still potentially some issues from the fact that not necessarily all items from `self.itempool` will be placed somewhere, e.g. additional items could have been added into the multiworld through item plando. But, I don't know how `get_items()` is actually supposed to work due to it being undocumented. Additionally, changing `get_items()` to be aware of what it should return depending on which generation steps have been run would be a more involved change to parts of core AP.
Collaborator
I believe this actually is more of a "bug" in |
Collaborator
|
I ran a quick 50 gen fuzzer on each of the world using
|
Jouramie
approved these changes
Jul 24, 2026
Jouramie
added
the
is: bug/fix
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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?
Depending on when
get_all_state()is used, items inmultiworld.itempool, or from a world'sget_pre_fill_items()could already have been placed, meaning thatget_all_state()could collect these item instances twice.This changes
MultiWorld.get_all_state()to skip directly collecting items that have already been placed.This does not fix all issues with
MultiWorld.get_all_state()at all generation steps because some worlds create newIteminstances every time theirget_pre_fill_items()is called, but collecting a fewpre_fill-placed items twice generally doesn't cause problems, otherwise we would see many more generation failures from the vast number of worlds that currently useget_all_state()within thepre_fillstep.This fixes #6333.
This fixes #6334.
This fixes hiding some issues in worlds'
pre_fillmethods fromtest_default_all_state_can_reach_everything, that usesget_all_state()and would often collect items fromget_pre_fill_items()twice. This notably reveals a potential bug in SMZ3 which now often failstest_default_all_state_can_reach_everything.How was this tested?
Untested besides running the unit tests.