Archipelago
Archipelago copied to clipboard
ArchipelagoMW
Early Items option
What is this fixing or adding?
Adds an early_items common yaml option. The specified items will be forced into sphere 1.
My motivation to add such a feature: I like the novelty of, for example, randomizing focus and slash directions in HK, but don't want to risk having to do most or all of my game without them. This would allow one to randomize such items but know it shouldn't be too long before they're found.
Furthermore, a number of games have had options implemented to force certain items into sphere 1, and in the future this could be accomplished more simply by just adding the items to this dict (and local_items if desired)
Currently this is accomplished through item rules. This could be changed to a new step in distribute_items_restrictive but we would have to separate out early priority locations and advancement items to deal with those due to, currently, no item rule being placed into priority locations to require they be advancement items.
How was this tested?
Several tests with different games to ensure the specified number of each items are being forced into sphere 1 and no more or less. Confirmed setting Power Bomb: 2 in Super Metoid with morph_placement: early fails to generate due to not enough sphere 1 locations.
If this makes graphical changes, please attach screenshots.
Subnautica is a game that doesn't even make it an option, 2 out of 4+ Seaglide pieces get placed locally in sphere 1, in case that gives you something to improve with.
I think I'm going to rerwite this as a set of extra fill steps, instead of item rules. I'm concerned about an item rule that builds a list of all early locations that have a specific item, for every early item specified, could lead to a performance hit. Plus if you specify too many early items to where it cannot place them all, it would be nice for that to cause an error early on and make it more obvious what the problem was
Will this require that an item be marked progression?
I have an item that is not progression - doesn't open anything logically, but it's kind of annoying if you have to go without it for a long time, so players would like to make sure it's available early.
Will this require that an item be marked progression?
I have an item that is not progression - doesn't open anything logically, but it's kind of annoying if you have to go without it for a long time, so players would like to make sure it's available early.
no
pulling them from the various item pools individually after sorting them into said pools feels pretty inefficient. There's probably an earlier point where these could be intercepted?
pulling them from the various item pools individually after sorting them into said pools feels pretty inefficient. There's probably an earlier point where these could be intercepted?
I didn't really like it, but I did it this way to preserve the pools of items being passed to fill_hook. Not many games use it, and with what they do currently it might not make much of a difference, but I could imagine scenarios where someone could implement something else things not being in progitempool as expected could cause problems
I feel this setting is an easy way to generate generation errors when assining more items in sphere 1 then the game(s) can fit in sphere 1
I feel this setting is an easy way to generate generation errors when assining more items in sphere 1 then the game(s) can fit in sphere 1
Sure, just like how you can cause generation errors by putting more locations than there are junk items into exclude_locations
pulling them from the various item pools individually after sorting them into said pools feels pretty inefficient. There's probably an earlier point where these could be intercepted?
Moved early_items handling to before fill_hook. I suppose if item plando can place items before here, then this should be fine too.
Subnautica is a game that doesn't even make it an option, 2 out of 4+ Seaglide pieces get placed locally in sphere 1, in case that gives you something to improve with.
If we want to keep those 2 items in the local game, then this wouldn't really work because you'd have to put the item into local_items and then all 4 would be forced local. The way I'd like early_items to work not to force them to the local game, just first sphere anywhere, different from how most "early" item settings work
Take a look at Subnautica pre_fill.
It's something I've been wondering if I should make that generic.
As it is, it places 2 items into local sphere 1, but by removing player=self.player it would place them into sphere 1 of the multiworld.
Take a look at Subnautica pre_fill. It's something I've been wondering if I should make that generic. As it is, it places 2 items into local sphere 1, but by removing
player=self.playerit would place them into sphere 1 of the multiworld.
If it's fine to put them in any world then I'll do that
If this https://github.com/ArchipelagoMW/Archipelago/pull/1130 doesn't fix the shared reference problem, then there's somewhere else that is saying value = default, and that should be changed wherever it is.
Is this Viridian Gym stuff a stray commit? It looks like it doesn't belong.
This was supposed to have been committed to my Pokemon fixes pr branch, my bad