* TLOZ: Assorded Logic Fixes
- Add needing arrows for Pols Voice rule. Not super necessary at the moment since wooden arrows are always accessible in one of the opening shops, but future proofing for future plans
- Create Gohma Locations and make sure all Gohma blocked locations have the required rule (was missing at least one location before)
- Remove the rule requiring Bow for all locations of level 8 (not sure why that was there, it's theoretically redundant now that Gohma and Pols Voice are properly marked)
- Make sure Digdogger locations properly require Recorder, and clean up redundant Level 7 rules as level 7 currently requires Recorder to access the entrance
* Update worlds/tloz/Rules.py
forgor that has_any exists
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
* Remove world = multiworld
---------
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
* TLOZ: Fix non-deterministic item pool generation
The way the item pool was constructed involved iterating unions of sets.
Sets are unordered, so the order of iteration of these combined sets
would be non-deterministic, resulting in the items in the item pool
being generated in a different order with the same seed.
Rather than creating unions of sets at all, the original code has been
replaced with using Counter objects. As a dict subclass, Counter
maintains insertion order, and its update() method makes it simple to
combine the separate item dictionaries into a single dictionary with the
total count of each item across each of the separate item dictionaries.
Fixes#3664 - After investigating more deeply, the only differences I
could find between generations of the same seed was the order of items
created by TLOZ, so this patch appears to fix the non-deterministic
generation issue. I did manage to reproduce the non-deterministic
behaviour with just TLOZ in the end, but it was very rare. I'm not
entirely sure why generating with SMZ3 specifically would cause the
non-deterministic behaviour in TLOZ to be frequently present, whereas
generating with other games or multiple TLOZ yamls would not.
* Change import order
---------
Co-authored-by: NewSoupVi <57900059+NewSoupVi@users.noreply.github.com>
* [TLOZ]: Fix determinism / Add Location Name Groups / Remove Level 9 Junk Fill
Axing the final uses of world.multiworld.random that were missed before, hopefully fixing the determinism issue brought up in Issue #3664 (at least on TLOZ's end, leaving SMZ3 alone). Also adding location name groups finally, as well as axing the Level 9 Junk Fill because with the new location name groups players can choose to exclude Level 9 with exclude locations instead.
* location name groups
* add take any item and sword cave location name groups
* use sets like you're supposed to, silly
Properly name the Book to Book of Magic in Rules.py so you can actually possibly be expected to use Magical Rod plus Book of Magic to get through dark rooms. No wonder we tend to see candles so early oops.
Also adding a rule that you need candles for access to Level 8 so you aren't required to time a Rod+Book shot against a moblin to burn the bush. Might make this a logic trick or something later.
* Update contributing.md
* Update contributing.md
* Update contributing.md
* Update contributing.md
* Update contributing.md
* Update contributing.md
Added non-AP World specific information
* Update contributing.md
Fixed broken link
* Some minor touchups
* Update Contributing.md
Draft for version with picture
* Update contributing.md
Small word change
* Minor updates for conciseness, mostly
* Changed all instances of settings to options in info and setup guides
I combed through all world docs and swapped "setting" to "option" when this was refering to yaml options.
I also changed a leftover "setting" in option.py
* Update contributing.md
* Update contributing.md
* Update setup_en.md
Woops I forgot one
* Update Options.py
Reverted changes regarding options.py
* Update worlds/noita/docs/en_Noita.md
Co-authored-by: Scipio Wright <scipiowright@gmail.com>
* Update worlds/sc2wol/docs/en_Starcraft 2 Wings of Liberty.md
revert change waiting for that page to be updated
* Update worlds/witness/docs/setup_en.md
* Update worlds/witness/docs/en_The Witness.md
* Update worlds/soe/docs/multiworld_en.md
Fixed Typo
Co-authored-by: black-sliver <59490463+black-sliver@users.noreply.github.com>
* Update worlds/witness/docs/en_The Witness.md
* Update worlds/adventure/docs/en_Adventure.md
* Update worlds/witness/docs/setup_en.md
* Updated Stardew valley to hopefully get rid of the merge conflicts
* Didn't work :dismay:
* Delete worlds/sc2wol/docs/setup_en.md
I think this will fix the merge issue
* Now it should work
* Woops
---------
Co-authored-by: Scipio Wright <scipiowright@gmail.com>
Co-authored-by: black-sliver <59490463+black-sliver@users.noreply.github.com>
Was pointed out that using `state.locations.checked` is not the best solution, even if it's for a completion condition and the Ganon event location would always have the Triforce of Power event item. So let's just check for the Triforce of Power instead. Thank you Zunawe for pointing it out and Silvris for providing the proper rule to use.
Turns out you can't kill Gleeok with bombs or a candle as I happened to find out in a community async. While I'll be fine, a rare combination of settings could put all 4 possible weapons (the three levels of sword and the Magical Rod) to kill Gleeoks behind killing Gleeoks. This fix should prevent that from happening.
Note: Even though there are technically 5 weapons that can kill Gleeok in the pool because at the moment we have an extra copy of the base Sword, I want to future-proof this incase we make changes to the item pool later.
Co-authored-by: black-sliver <59490463+black-sliver@users.noreply.github.com>
It was brought up that if you attempt to non_local any of the starting weapons, there is still a chance for it to get chosen as your starting weapon if you are on a StartingPosition value lower than very_dangerous. This fix will attempt to build the starting weapons list accounting for non_local items, but if all possible weapons have been set to non_local, force one of them to be your starting weapon anyway since the player is still expecting a starting weapon in their world if they have chosen one of the lower StartingPosition values.
There was a bug in non-expanded item pool where due to the base patch changes to accommodate more items in dungeons, some items were transformed into glitch items that removed bombs (this also happened in expanded item pool, but the item placement would overwrite the results of this bug so it didn't appear as frequently). Being a Zelda game, losing bombs is bad. This PR fixes the base patch process to avoid this bug, by properly carrying the value of a variable through a procedure.
As discovered by this bug report https://discord.com/channels/731205301247803413/1182522267687731220 it's currently possible to accidentally have the starting weapon of a player overwritten by a triforce fragment if TriforceLocations is set to dungeons and StartingPosition is set to dangerous. This fix makes sure to remove the location of a placed starting weapon if said location is in a dungeon from the pool of possible locations that triforce fragments can be placed in this circumstance.
* Add Unique Locals Commands to ChecksFinder
* Add Unique Locals Commands to MMBN3 Game Page
* Add Unique Locals Commands to Ocarina of Time Game Page
* Add Unique Locals Commands to Undertale Game Page
* Add Unique Locals Commands to Wargroove Game Page
* Add Unique Locals Commands to The Legend of Zelda Game Page
* Add Unique Locals Commands to Zillion Game Page
* Amend Unique Locals Commands on Final Fantasy 1 Game Page
* Add Unique Locals Commands to Pokemon R/B Game Page
* Grammar fix for FF1
* Corrected sections names to match
* Added commands to Starcraft 2 Wings of Liberty game page
Co-authored-by: Bicoloursnake <60069210+bicoloursnake@users.noreply.github.com>
---------
Co-authored-by: Bicoloursnake <60069210+bicoloursnake@users.noreply.github.com>
using os.path.join was causing duplicate parts of the filepath in certain environments. turns out it's not needed when loading the basepatch in our current world structure. this should hopefully fix genning issues on the RC beta site (and presumably the main site once the RC turns into the release)
* - Use proper MD5 validation
The method TLoZ was trying to validate it's baserom was different from basically every other ROM game. Almost all the other ROM games use the same method as each other (except for the external patchers like FF1 and SoE, and OoT has its own special handling that's vastly different), so updating TloZ to match.
Also got rid of the checksum attribute for the TLoZDeltaPatch as it didn't seem to be used anywhere, so felt it was unnecessary and partially confusing to have it right next to the hash attribute that is actually used.
* change error message to reference MD5
- add section about configuring lua core (shamelessly taken from the OoT setup guide) on bizhawk version 2.8 and below
- fix wrong reference to the ff1 connector lua to correctly reference the tloz connector lua
- remove reference to recommended bizhawk version. it's unnecessary
* Add settings API ("auto settings") for host.yaml
* settings: no BOM when saving
* settings: fix saving / groups resetting themselves
* settings: fix AutoWorldRegister import
Co-authored-by: el-u <109771707+el-u@users.noreply.github.com>
* Lufia2: settings: clean up imports
* settings: more consistent class naming
* Docs: update world api for settings api refactor
* settings: fix access from World instance
* settings: update migration timeline
* Docs: Apply suggestions from code review
Co-authored-by: Zach Parks <zach@alliware.com>
* Settings: correctly resolve .exe in UserPath and LocalPath
---------
Co-authored-by: el-u <109771707+el-u@users.noreply.github.com>
Co-authored-by: Zach Parks <zach@alliware.com>
* Fix links to TASVideos.org using HTTP
* Revise all docs mentioning Lua in EmuHawk which are in English
resolvesTASEmulators/BizHawk#3650
* Correct capitalisation of "BizHawk"
in strings and camelCase identifiers
* Use the term "EmuHawk" when referring to the app, in English docs
---------
Co-authored-by: black-sliver <59490463+black-sliver@users.noreply.github.com>
- Remove a relative import in Rules.py
- Clean up a few unused imports in __init__.py
- Use pkgutil instead of open when applying base patch
- make sure rom_name is initialized correctly in modify_multidata
* use os.path.join() instead of explicit "/"
* Fix starting weapon locations usage
Makes a fresh copy of starting weapon locations when get_pool_core is ran
Should fix the issue of dangerous_weapon_locations getting appended to the list for other worlds past the first world that has dangerous StartingPosition, as well as running into the error if ExpandedPool was different between players
Credit for fix goes to @Silvris in the AP Discord
* Fixes the socket library for bizhawk 2.9/lua 5.4 by including another one in parallel
* Fixes lua 5.4 support by making socket.lua into a "modern" module (the `module` keyword is gone)
* Adds the linux version and 32 bit windows socket dlls because why not
* Merges common functions into `common.lua` - the only functional change of this should be that:
* Some things that were locals are globals now - this can be changed, I just was lazy and it likely doesn't matter
* `drawText` now uses middle/bottom for all prints - feel free to do what you like with that change
* TLOZ: Pols Voice Logic Fix
Was informed that Pols Voice require certain weapons to kill that might not be guaranteed by the starting weapon. This is the only regular enemy in the game that cannot be killed by either any of the starting weapons or bombs which can be bought, so adding this rule should prevent any issues.
- consolidated declaration and population of level location lists
- moved floor_location_game_ids_late declaration for consistency
- moved generate_itempool to create_items, where it belongs
- mention that expanded pool includes take any caves in the option description again
- removed unnecessary StartingPosition check regarding Take Any Caves (leftover from older StartingPosition behavior I believe)
- use proper comparisons to option keys instead of hardcoded ints
