* Pokemon Red and Blue PC Item fix
* Respect non_local_items for PC Item
* prefer exclude if also in priority locations
---------
Co-authored-by: alchav <alchav@jalchavware.com>
* Core: Speed up fill_restrictive item_pool pop loop
Items from `reachable_items` are placed in last-in-first-out order, so
items being placed will be towards the end of `item_pool`, but the
iteration to find the item was iterating from the start of `item_pool`.
Now also uses `del` instead of `.pop()` for an additional, tiny,
performance increase.
It is unlikely for there to be a noticeable difference in most cases.
Only generating with many worlds with a high percentage of progression
items and fast access rules is likely to see a difference with this
change.
--skip_output generation of 400 template A Hat in Time yamls with
progression balancing disabled goes from 76s to 43s (43% reduction) for
me with this patch. This placed 43200 progression items out of 89974
items total (48% progression items).
* Fix comment typo
"be" was missing.
---------
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
* create building data object and rename ItemSource to Source to be more generic
# Conflicts:
# worlds/stardew_valley/content/game_content.py
# Conflicts:
# worlds/stardew_valley/data/artisan.py
# worlds/stardew_valley/data/game_item.py
# worlds/stardew_valley/data/harvest.py
# worlds/stardew_valley/data/shop.py
* remove compound sources, replace by other requirements which already handle this usecase
* add coops to content packs
* add building progression in game features
* add shippping bin to starting building; remove has_house
* replace config check with feature
* add other buildings in content packs
* not passing
* tests passes, unbelievable
* use newly create methods more
* use new assets to ease readability
* self review
* fix flake8 maybe
* properly split rule for mapping cave systems
* fix tractor garage name
* self review
* add upgrade_from to farm house buldings
* don't override building name variable in logic
* remove has_group from buildings
* mark some items easy in grinding logic so blueprints buildings can be in more early spheres
* move stuff around to maybe avoid future conflicts cuz I have like 10 PRs opened right now
* remove price_multiplier, turns out it's unused during generation
* disable shop source for mapping cave systems
* bunch of code review changes
* add petbowl and farmhouse to autobuilding
* set min easy items to 300
* fix farm type
* Removed now unused imports from Launcher
* Moved ImageIcon and ImageButton to use ApAsyncImage for compatibility with apworlds
* Adjusted image size in the Launcher from 40x40 to 48x48. This is already larger than the size in previous versions, and a docs update is soon to follow.
* Expose `dynamic_scheme_contrast` to user.kv, allowing users to set high contrast.
* ScrollBox's default scroll_type was set to only content, so the scrollbar in Launcher was nonfunctional.
* Adjusted the spacing of the title of a component when a description is present to be closer to the center.
* Launcher now scrolls to the top automatically when changing between filters
Shifts the contents of `kvui.py`, and thus all CommonClient-based clients as well as Launcher, to using KivyMD. KivyMD is an extension for Kivy that is almost fully compatible with pre-existing Kivy components, while providing Material Design support for theming and overall visual design as well as useful pre-existing built in components such as Snackbars, Tooltips, and a built-in File Manager (not currently being used).
As a part of this shift, the launcher was completely overhauled, adding the ability to filter the list of components down to each type of component, the ability to define favorite components and filter to them, and add shortcuts for launcher components to the desktop. An optional description field was added to Component for display within the new launcher.
The theme (Light/Dark) and primary palette have also been exposed to users via client/user.kv.
* Core: Prevent people from using LogicMixin incorrectly
There's a world that ran into some issues because it defined its custom LogicMixin variables at the class level.
This caused "instance bleed" when new CollectionState objects were created.
I don't think there is ever a reason to have a non-function class variable on LogicMixin without also having `init_mixin`, so this asserts that this is the case.
Tested:
Doesn't fail any current worlds
Correctly fails the world in question
Also, not gonna call out that world because it was literally my fault for explaining it to them wrong :D
* Verbose af
* Update AutoWorld.py
`Location` does not override `__eq__` so should not override `__hash__`.
With this patch, this makes operations on sets of locations slightly
faster because they will use `object.__hash__` rather than
`Location.__hash__`.
`object.__hash__` is about 4 to 5 times faster than `Location.__hash__`
for me. Generation often uses sets of locations, so this slightly speeds
up generation.
The only place I could find that was hashing locations directly was
`WitnessLocationHint.__hash__`, but it has implemented a matching
`__eq__`, so is fine.
For security reasons, Python randomizes its hash seed each time it is
started, so the result of the `hash()` function is nondeterministic and
can't have been used by worlds for anything that needed to be
deterministic and can't have been used to compare information hashed at
generation time to information hashed by a client.
The base state passed to fill_restrictive should be as maximal as
possible otherwise fill_restrictive has to repeatedly re-sweep and
collect from advancement locations that were reachable from before
fill_restrictive has placed a single item.
This is not added within fill_restrictive itself because it is common
for fills to be performed using a partial 'all_state', which is already
a maximum exploration state.
With --skip_output generation of every template yaml, except FF, KH
and Shivers, this prevented repeatedly re-sweeping 576 advancement
locations in every sweep within progression fill, reducing the
generation time from 124s to 113s for me (8.8% reduction, averaged over
5 generations each).
Without implementing __iter__ directly, calling iter() on a
Region.Register on Python 3.12 would return a new generator implemented
as follows:
```py
def __iter__(self) -> int:
i = 0
try:
while True:
v = self[i]
yield v
i += 1
except IndexError:
return None
```
This was determined by disassembling the returned generator with
dis.dis() and then constructing a function that disassembles into the
same bytecode.
The iterator returned by `iter(self._list)` is faster than this
generator, so using it slightly improves generation performance on
average.
Iteration of Region.Register objects is used a lot in
`CollectionState.update_reachable_regions` in both of the private
_update methods that get called. The performance gain here will vary
depending on how many regions a world has and how many exits those
regions have on average.
For a game like Blasphemous, with a lot of regions and exits, generation
of 10 template Blasphemous yamls with `--skip_output --seed 1` and
progression balancing disabled went from 19.0s to 16.4s (14.2% reduction
in generation duration).
* Only consider usable exits when calculating whether or not a region is a dead-end
* Update EntranceLookup unit tests
* Add new dead-end test
* Add additional explanation to the new test
* minor formatting tweak
based on review feedback
---------
Co-authored-by: CodeGorilla <3672561+Ars-Ignis@users.noreply.github.com>
* DLC Quest Bug Fix
Start inventory item that do not exist in the present world do not make more trap item to appear anymore
* Update worlds/dlcquest/Items.py
Co-authored-by: Mysteryem <Mysteryem@users.noreply.github.com>
* DLC Quest Bug Fix
did the recommendation of Mysteryem and made the item not exist in the pool of item created
* DLC Quest Bug Fix
did the recommendation of agilbert1412 and made a check by name instead of item to itemData
* DLC Quest Bug Fix
overcook failed test
* DLC Quest Bug Fix
re-type correctly a type hint
---------
Co-authored-by: Mysteryem <Mysteryem@users.noreply.github.com>
