Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
InspectorCaracal opened this issue Feb 19, 2024 · 3 comments
Open
Labels
bug An actual error or unwanted behavior.

Comments

@InspectorCaracal
Copy link
Contributor

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

@InspectorCaracal InspectorCaracal added bug An actual error or unwanted behavior. needs-triage Yet to be looked at and verified as an a real issue/feature that could be worked on labels Feb 19, 2024
@Griatch
Copy link
Member

Griatch commented Feb 25, 2024

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. 🤔

@Griatch Griatch removed the needs-triage Yet to be looked at and verified as an a real issue/feature that could be worked on label Feb 25, 2024
Griatch added a commit that referenced this issue Feb 25, 2024
@InspectorCaracal
Copy link
Contributor Author

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

@Griatch
Copy link
Member

Griatch commented Feb 25, 2024

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 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An actual error or unwanted behavior.
Projects
None yet
Development

No branches or pull requests

2 participants