Archipelago
Archipelago copied to clipboard
ArchipelagoMW
Core: make start_hints a dictionary instead of a set so quantities can be specified by the player
What is this fixing or adding?
Title
How was this tested?
Generated multiple seeds with different quantities of starting hints to verify expected results
Happened to revisit this one. Besides the conflicts, this will also require some docs updates, correct? Also will need WebHost changes to take counts into account now.
docs are updated, and hints are precollected before generate_output, and get added to the multiworld so worlds can check them now. Took a look at the webhost stuff but it's all js which is pretty far out of my wheelhouse.
I believe this breaks using item groups in start_hints. I at least haven't found a way to get it to work
I'm not sure how doable this is, but it would be nice if the old method of start_hints could still be used with something like start_hints: {Progressive Dots: true} which would put all copies of Progressive Dots into start_hints. This would be especially helpful for items whose count varies based on randomness or user options. That said, throwing in an arbitrarily large number does work; for example: start_hints: {Power Seal: 100}
Edit/Update: It actually looks like doing {Power Seal: true} hints one Power Seal, which seems like an unintended behavior
does start inventory support item name groups? it's doable but i'm not sure it'd be very good, since it'd basically have to get the actual items at random
does start inventory support item name groups? it's doable but i'm not sure it'd be very good, since it'd basically have to get the actual items at random
It doesn't right now, presumably at least partially because the item count would be awkward to the point that I doubt anybody would really use it. Randomly selecting items would be weird, especially since it could pick the same one every time. Something like group: true to include all copies of all of them might make sense but I'd more expect that in start_inventory_from_pool, if anywhere.
Nevermind, losing support for item groups on something that currently has it seems pretty bad, only just read that
Nobody has offered a satisfactory solution to this yet.
Nevermind, losing support for item groups on something that currently has it seems pretty bad, only just read that
Nobody has offered a satisfactory solution to this yet.
That's fair, but If your PR loses a feature, and people say that that's a problem, the onus is gonna be on you as the PR holder (at least if your intent is still to get it merged) to either find a way, or argue that the benefits outweight the cost and convince people
But, to offer something constructive: In my opinion, at least for the games I play, hinting random items from the group would be fine (as long as it's deterministic by seed obviously), that is the behavior I'd expect. If I put "Symbols: 4" for my Witness seed, I'd expect that to hint 4 random symbols out of the 14 symbol items in the itempool. Think about it like this: When hinting 1 instance of an item with 3 copies in the pool, it is also random which copy is going to be hinted. A group (as I understand it conceptually) essentially exists to treat a set of items as one item, so "it's random which copy of that item gets hinted" for a single multi-copy item translates to "it's random which item from the group is hinted" for an item group.
Just realized: !hint item_group from the client is random as well. Yeah I really think it should support item groups, and be random
To me "Symbols: 4" runs into some problems. To showcases all of them: Imagine you're playing on Normal and Arrows get hinted four times, or even worse Colored Dots and Invisible Dots. You also have to consider something like start_hints: {Black/White Squares: 1, Symbols: 3}
The current solution already looks at what items actually exist in the multiworld, as far as I can tell, so I'm assuming anything new that is implemented to do with item groups would do so as well. So the "Arrows" case wouldn't happen.
As for the case where a user puts an item group and a single item from that item group in there ({Black/White Squares: 1, Symbols: 3}), that would be more difficult to resolve. I'd expect it to hint 4 Symbols total, with one of them being Black/White Squares, but to get that behavior, this would have to be done in two steps somehow, I suppose.
In general, I'd expect this to behave as if running !hint as many times as specified, but - because it makes most sense for ux, probably - doing all single-item hints first, and all item group hints second
So Arrows is fine, but it could still hint an item like Sound Dots four times, right?
I can't speak to the behavior of something that is not implemented yet, but if it's implemented sensibly, then yeah obviously it wouldn't hint the same item multiple times - It doesn't hint the same copy of multi-copy items either
If you just dropped in item group support directly into treble's current implementation in the simplest way possible, I believe it would behave correctly in terms of this "Sound Dots" case. (But it would not handle the {Black/White Squares: 1, Symbols: 3} correctly)
I believe this also breaks KH2 https://github.com/ArchipelagoMW/Archipelago/blob/b23c1202582cbdf9a8e882d6b65cb580c5c5a382/worlds/kh2/init.py#L494
The current solution already looks at what items actually exist in the multiworld, as far as I can tell, so I'm assuming anything new that is implemented to do with item groups would do so as well. So the "Arrows" case wouldn't happen.
this isn't possible because options (and their text) are all validated long before any worlds get created, so there's no way to know what items "will" exist. i suppose it could have custom validation and keep the group names in until the option actually gets used but that's a massive pain i don't want to do
The current solution already looks at what items actually exist in the multiworld, as far as I can tell, so I'm assuming anything new that is implemented to do with item groups would do so as well. So the "Arrows" case wouldn't happen.
this isn't possible because options (and their text) are all validated long before any worlds get created, so there's no way to know what items "will" exist. i suppose it could have custom validation and keep the group names in until the option actually gets used but that's a massive pain i don't want to do
I feel like the item groups should just resolve to like, Tuple[Iterable[Item], int]. Or starting inventory should be a Dict[Iterable[Item], int] So if you have a "Weapons" item group with "Sword", "Spear", "Boxing Glove" and "Gun", then this in a yaml:
start_inventory: {"Weapons": 2}
would resolve to
world.options.start_inventory = {
("Sword", "Spear", "Boxing Glove", "Gun"): 2,
}
Then, when it comes time to create the starting hints during generate_multidata or whenever, it can check which of those actually exist.
Randomly choosing the target items from the group during options resolution seems bad.
No, the dict would resolve from Dict[str, int] to Dict[Iterable[Item], int] where groups are expanded, and then later, per dict entry, it chooses value random items out of the ones that exist per entry.
Like if you really want to "resolve" groups by the time of option creation, just resolve them into a list of items and keep the numbers around. I don't see why it would need to resolve all the way down actually to choosing the items during option resolution, why can't that wait until the end?