evennia / evennia

Python MUD/MUX/MUSH/MU* development system

Home Page:http://www.evennia.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[BUG] Plural aliasing fails to match in stacked/quiet searches

InspectorCaracal opened this issue · comments

Describe the bug

Something in the way Evennia adds plural aliases to objects, or possibly the way it searches for them, is breaking search results and only returning one match, even when stacked or quiet are set.

To Reproduce

Steps to reproduce the behavior:
Create 3 items named "rock" in your location and then enter the following py lines

py self.search('rock', quiet=True)
>>> self.search('rock', quiet=True)
['rock', 'rock', 'rock']
py self.search('rocks', quiet=True)
>>> self.search('rocks', quiet=True)
['rock']

Expected behavior

If the auto-generated alias "rocks" is expected to be usable at all, it should match exactly the same search results as the regular key "rock".

Environment, Evennia version, OS etc

evennia 3.1.1

Looks like the objects .get_numbered_name(num, looker) must have been called for the <N> rocks alias to be created, which is what makes self.search("rocks") work.

I suspect it's only called on the first rock normally (the others are stacked with it so they are not treated as individual objects). That's why there's only one return in the search("rocks") case.

I'm reluctant to always create these aliases for all objects on-creation, but unless we device some other, more programmatic way to query for plural forms, it's probably what needs to happen. 🤔

Yeah, I puzzled over how exactly to write up this issue for a while because of exactly that. But I think at the moment the expectation of how it should work is probably to add the plural aliases to everything, mostly because of the docstring for get_numbered_name:

this will be called on *every* member of a group even though the plural name will be only
shown once. Also the singular display version, such as 'an apple', 'a tree' is determined

An alternative here is to maybe expand the evennia.utils.strip_partial_matching which is what is used to do partial matches (like finding out that sw works as a shortcut for sword as long as it becomes a unique match among the match candidates). Here, rocks doesn't register as a valid partial match for rock since it's longer.

But maybe it could be a special case ... then there would be no need for an explicit alias (at least not for this use case). Then again, english plural forms are not always easy to generalize 😅