Proof of Concept: Scope hinting via prefixes

[max-buzzkill]

Currently const_generic_find is used for a number operations, and numeric prefixes allow differentiating items on multiple keyword matches. However, these numeric indices are calculated per-scope via get_number. This leads to issues if someone is for example 2 items that match a keyword (or the same item like a ring) and is trying to refer to another match/copy in their inventory: 1.keyword ends up matching the first instance in their equipment, while 3.keyword fails because there is no 3rd item in equipment, and the inventory scope is indexing that match at 1.keyword. While this is mostly an inconvenience, there are cases, such as sustaining foci supporting a ritual-cast spell where there is an associated cost to removing/swapping items.

Proposing adding scope hinting prefixes: worn., inv., room. which narrow the scope bitmap ans therefore search space to the relevant scope, if it is valid for that command. The above scenario can be resolved by using inv.keyword or inv.1.keyword to match the item in inventory.

Additionally, experimenting with adding a logical scope: exit. to force exist/door interactions in a similar fashion, allowing the use of keywords beyond the cardinal directions. This might need some additional input/be expanded to other commands if it is thought to be useful, hoping for some feedback on this.

[luciensadi]

This is an interesting concept, but it feels like it has the potential to break a lot of commands if they're doing their own special parsing (and I can't guarantee that any commands aren't doing this). Have you had a chance to test it much?

[vitalyo7]

In another mud, it was possible to add custom alias/tag to an item for this purpose.

Tag 2.backpack as loot_storage
Put something into loot_storage.

Can I recommend that we add ability to tag owned gear.

[max-buzzkill]

This is an interesting concept, but it feels like it has the potential to break a lot of commands if they're doing their own special parsing (and I can't guarantee that any commands aren't doing this). Have you had a chance to test it much?

Still working on testing, hence why I put it up as a draft, though have had some success with preliminary testing. Was mostly curious about initial thoughts/interest in the approach.
I have been mostly focused on commands that search over scope boundaries where the numeric prefixes fail, so its an open question how to deal with commands that do custom parsing over a single scope (breakage would mostly be a silent failure/item not found as get_number would just ignore it.. maybe strip/silently discard the prefixes there?). The list of commands that do custom parsing across scopes is notably smaller, would need to update things like (de)activate (which might also need a scope for ware), drink, and such; which I can work on if there if there is interest in this.

[max-buzzkill]

Stripping prefixes in get number would be the quickest/dirtiest approach to single scope commands, but almost I could imagine the confusion when someone is trying to use a scope prefix for an unsupported scope for a command, and it just happily strips the prefix and operates on the scope it always did.

I imagine a more 'correct' approach would be to define all the scopes as constants, add a scope stripping utility function, and start by finding all commands that use get_number and stripping out the correct scope in those instances. Incorrect scopes would still fail in those cases and the user would get an item not found message.

Alternatively, could try to see how much of the custom item scope handling could be brought under the generic_find umbrella, to have a central point for item discovery/prefixing instead of bespoke implementations.

[max-buzzkill]

In another mud, it was possible to add custom alias/tag to an item for this purpose.

Tag 2.backpack as loot_storage Put something into loot_storage.

Can I recommend that we add ability to tag owned gear.

That is an interesting idea, but wouldn't address the core of this issue. Would be more in line with restrings I think.