Fill: allow for single player fill restrictive placement and sweeping #2415
Conversation
This file contains 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
alwaysintreble
changed the title
ThePhar
added
is: enhancement
|
Tested on main's OoT, observed ~20% speedup on 10 worlds default settings and ~35% speedup on 20 worlds, presumably would get even better with more worlds but I don't have infinite processing power to test it. |
Berserker66
reviewed
Nov 2, 2023
# Conflicts: # Fill.py
alwaysintreble
added
the
waiting-on: peer-review
alwaysintreble
changed the title
Zunawe
approved these changes
Mar 10, 2024
There was a problem hiding this comment.
Changes look about like what I did a while ago when the conversation that sparked this PR was had. I don't think my approval can speak for whether these changes forget behaviors that I don't know about, but I can say that it works very well for Emerald's purposes. Emerald is starting to hurt quite badly in pre_fill due to having to collect and sweep from every world in order to place a handful of its own items. Aside from creating a patch file, this is by far the slowest aspect of Emerald right now.
Shuffling both badges and HMs (16 items among 16 locations, split into two groups) on my current dev branch for Emerald takes
Without this PR:
- ~1.1 seconds per
pre_fillin a 10-player game - ~10 minutes per
pre_fillin a 2000-player game
With this PR
- ~0.3 seconds per
pre_fillin a 10-player game - ~2 minutes per
pre_fillin a 2000-player game with this PR merged
It's another good chunk of time knocked off if there's an api to create single-player all_states, though not nearly as much.
i have this #2427 but i'm not happy with it atm so would definitely like some feedback on it on how it can be improved/made more usable. |
ScipioWright
added
the
waiting-on: author
alwaysintreble
removed
the
waiting-on: author
NewSoupVi
added
waiting-on: core-review
|
Tested a bunch of seeds with multiple games between main and this PR branch
Everything was identical. |
jnschurig
pushed a commit
to Tranquilite0/Archipelago-SoulBlazer
that referenced
this pull request
Jun 13, 2024
…ArchipelagoMW#2415) * Core: allow for single player state sweeping * Fill: have distribute items use single_player fill when it can * oop * pass locations to sweep_for_events instead of the player * finally found the diff that was breaking swap * LTTP fills everyone's dungeons at once, not just a single player's --------- Co-authored-by: NewSoupVi <[email protected]>
qwint
pushed a commit
to qwint/Archipelago
that referenced
this pull request
Jun 24, 2024
…ArchipelagoMW#2415) * Core: allow for single player state sweeping * Fill: have distribute items use single_player fill when it can * oop * pass locations to sweep_for_events instead of the player * finally found the diff that was breaking swap * LTTP fills everyone's dungeons at once, not just a single player's --------- Co-authored-by: NewSoupVi <[email protected]>
Mysteryem
added a commit
to Mysteryem/Archipelago-ahit
that referenced
this pull request
Sep 24, 2024
ArchipelagoMW#2415 removed the ability to provide items/locations for multiple players simultaneously with single_player_placement=True. Now that this is removed, the old behaviour should be considered deprecated so that developers using the old behaviour don't run into unexpected problems. With the requirement in place that all items in the provided item pool have to belong to the same player, that singular player can be retrieved once in advance rather than getting the player from the most recent item set into the `item` variable. This reduces the used scope of the `item` variable to just the loops it is part of and removes IDE warnings about the variable possibly not being initialized.
Mysteryem
added a commit
to Mysteryem/Archipelago-ahit
that referenced
this pull request
Sep 28, 2024
…layers ArchipelagoMW#2415 removed the ability to provide items/locations for multiple players simultaneously with single_player_placement=True. Now that this is removed, the old behaviour should be considered deprecated so that developers using the old behaviour don't run into unexpected problems. With the requirement in place that all items in the provided item pool have to belong to the same player, that singular player can be retrieved once in advance rather than getting the player from the most recent item set into the `item` variable. This reduces the used scope of the `item` variable to just the loops it is part of and removes IDE warnings about the variable possibly not being initialized.
Mysteryem
added a commit
to Mysteryem/Archipelago-ahit
that referenced
this pull request
Sep 28, 2024
…layers ArchipelagoMW#2415 removed the ability to provide items/locations for multiple players simultaneously with single_player_placement=True. Now that this is removed, the old behaviour should be considered deprecated so that developers using the old behaviour don't run into unexpected problems. With the requirement in place that all items in the provided item pool have to belong to the same player, that singular player can be retrieved once in advance rather than getting the player from the most recent item set into the `item` variable. This reduces the used scope of the `item` variable to just the loops it is part of and removes IDE warnings about the variable possibly not being initialized.
AustinSumigray
pushed a commit
to AustinSumigray/Archipelago
that referenced
this pull request
Jan 4, 2025
…ArchipelagoMW#2415) * Core: allow for single player state sweeping * Fill: have distribute items use single_player fill when it can * oop * pass locations to sweep_for_events instead of the player * finally found the diff that was breaking swap * LTTP fills everyone's dungeons at once, not just a single player's --------- Co-authored-by: NewSoupVi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
title
How was this tested?
generated the same seed for 300 players under 4 separate conditions. existing emerald code with and without using the all_state cache, and then the same after merging in the single player optimization.
emerald cache single player opt.txt
emerald cache.txt
emerald no cache.txt
emerald no cache single player opt.txt
If this makes graphical changes, please attach screenshots.