Feature Disambiguate identically named quest items

Theraze

Active member
It would be really great if item_amount($item[Eye of Ed]) would return 1 if you had item 2286 on a non-Ed run. Currently, it appears to only check for item 7962.

Whether item_amount looks for both items or only the quest item which is actually possible based on your path, either way it would be nice for this to work again.
 
I'd have thought that getting scripters to use ids ( item_amount($item[2286]) ) where they're dealing with possibly identical items would result in more predictable behaviour than mafia disambiguating specific items by context.
 

Theraze

Active member
Actually, using $item[2286] will give a warning telling you to use $item[Eye of Ed] instead. To avoid the warning, you need to use to_item("2286").

I've been adding those exceptions to BCA as it aborts telling me that I don't have quest items which I clearly do have. I can understand why it works the way it does and why item_amount($item[Eye of Ed]) return 0 right after I get Eye of Ed from a combat. But it's not something that newbie scripters will logically be able to work through, and with Jick's love of making things weird for mafia, I can see more items/paths happening in a way that is awkward for mafia to handle.

Which is why I marked this as a Feature Request, not a Bug. It's a questionable call, whether returning that the user does not have any of an item which they do have, is a bug, new content (as we didn't have identically named items that weren't disambiguated before this, as far as I'm aware), or simply the feature request for handling this more gracefully. But Feature says that this would be nice, but isn't needed as there's a workaround. If it doesn't happen, I expect there to be future bug reports when scripters can't figure out why their 'valid' call for a specific $item is no longer working reliably.
 

Theraze

Active member
Alternatively, it would be nice to error on duplicate name lookups. If we use $item[Eye of Ed] and it isn't a unique match, that should probably make the script error out, to force script writers to use the number instead. Just like when you use non-specific fuzzy matching... as per this example
Code:
> ash $item[eye]

Bad item value: "eye" ()
Returned: void

> ash $item[eye of]

Bad item value: "eye of" ()
Returned: void

> ash $item[eye of ed]

Returned: Eye of Ed
It would assist in making the item calls more consistent for users.

Thanks for considering this. I'd like to be able to make scripts more future-proof with this, so that if/when Jick makes more identically named items, the scripters at least get notified as mafia updates for the new identical content.
 

Darzil

Developer
Well, it wouldn't make scripts more future proof, but it would flag a need to update them.

I can't see myself looking at this any time soon, as item matching is a rabbit hole, and I don't have time to spend a couple of days on this.
 

Veracity

Developer
Staff member
I intend to look at item matching, by and by. I discussed it, somewhere - being able to filter on type of item and look only in specific locations, and so on. The plan was to make all CLI commands use this so that "eat" or "equip" or whatever would only look at items of the right type - and would fail if the string was ambiguous within that type, rather than using the first one, whatever that is.

Now, the problem with duplicate item names is that we have a single list of item names generated from the "key set" of all items. Sets being what they are, there are no duplicates. Recognizing that the same name (fuzzy or exact) can refer to multiple items is a substantial project - several days, as Darzil said. Having done so, it would not be THAT hard to pick the quest item that corresponds to the path you are on.

Question: at Level 11, Ed's staff is disassembled into "new" components. As he visits the guardians who failed at their One Job and gives them back the components, are they removed from inventory? If not, when you return the Macguffin, are they then removed from inventory, much as other Ed-only quest items? If not, do they continue to be the "new" items, are do they magically change into the non-Ed versions?

I'll look more at this, eventually, but not soon.
 

Veracity

Developer
Staff member
Yeah, looking at where we manipulate Quest.MACGUFFIN, I see that we remove the quest items at the appropriate places and set the quest to finished when they are all gone.
 

heeheehee

Developer
Staff member
Can't drop path on day 1. I haven't checked for the other cases, but I would assume all quest items are removed from inventory.
 
Top