Archipelago
Archipelago copied to clipboard
ArchipelagoMW
The Witness: Automatic Postgame & Disabled Panels Calculation
AP The Witness has the concept of "disabled panels" which are panels that you have hard-excluded via your settings. shuffle_postgame: false is the big one, but there are more examples.
But this creates a lot of dependencies. If "Mountaintop Box Long" is disabled, "Mountain Bottom Floor Discard" becomes unsolvable too. And then as a result, Caves Entry becomes unsolvable (depending on doors mode). And then the entirety of Caves becomes unsolvable. So, all of these panels have to be disabled, because all of them lie in the postgame.
Right now, all of this is done by hand. I have a big awkward function that checks for complicated option combinations and disables huge, hand written lists of panels.
No more.
I am now using a sort of "What can the all state reach" algorithm to recursively figure out what other panels have been made unsolvable by making an initial set of them unsolvable.
Tested:
- It seems to be decently performant. This was my biggest worry as obviously, a programmatic, recursive solution will always be slower than just reading in a hand-written list of instructions. But, in this case, there barely seems to have been any performance hit.
- 2000 generations with a fully random yaml have also succeeded and resulted in 0 generation errors.
- It remains to be tested whether it matches current behavior. I checked some basic combinations but there's a lot more to check.
Benefits:
- This PR will be very important for the upcoming "warps" feature, especially the planned
random_warp_locationsoption. - I was able to get rid of a lot of the stupid .txt files, basically a whole folder of them
I was really worried about performance on this, but it seems to be okay: The player_logic.find_unsolvable_entities function, which repeatedly sweeps the game and finds unreachable entities, takes about 0.01s-0.02s for solo generations. I deem that acceptable, it's between 1% and 10% of generation time for solo games, and that's the worst it will ever be (because it's linear, whereas fill is at least polynomial). But will of course still hear ideas on how to improve performance.
This feature will be required to support Entrance Randomizer like features that I'm planning to make very soon, and it is also a much cleaner & less error prone solution than the previous solution (which basically involved doing all of this manually for each settings combination... Like yeah, that's gonna be faster, but it's also horrible to maintain)
