A Guide to Multi-Matching Alternatives #3427
InspectorCaracal
started this conversation in
Community Contribs & Snippets
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A Guide to Multi-Matching Alternatives
Over the past few years of my involvement in the Evennia development-and-support community, I've learned that one of the mechanisms which people have the most particular opinions about is: "what should happen if there are multiple objects with similar names?" Also known as the multimatch. And chances are, the opinion a given person has on what the right way, right syntax, etc. is for a multimatch is not what Evennia comes with.
Well! One of my favorite things about Evennia is how it gives you options to override just about any mechanical feature it has. And one of those is indeed the infamous multimatching. Here's a quick overview and some examples of how to change that.
Changing the Syntax
One of the two most common changes people want to make is to use a different syntax. By default, Evennia is set up for the disambiguation syntax of
name-1
. But it also makes it incredibly easy to change! (Unless you're terrible at regex like myself, in which case... find someone else who's good at regex and then it'll be easy to change!)There are two settings that control Evennia's disambiguation syntax. The first one is the actual regex pattern which Evennia uses to parse the disambiguator out of the argument. The second one is the template which Evennia uses to print out the multimatch feedback.
Here are their default values:
One fairly common syntax I see people looking for is to change that
name-1
into1.name
. For that, all you need to do is change those two settings to the following:(thank you owllex for providing this on discord)
Change those two settings et voila! You have the syntax you want.
No Multimatching At All
The other most common change I've seen people want is to not multimatch at all. Just grab the first item from the list of matches and go.
This one seems more complicated on the surface, because you'd think you need to dig into the commands and such to change their searching and so on and so forth. Nope! Once again, there is a setting to change it!
The entire multimatching/not-found messaging logic is actually handled in a separate function, after the search is executed, which the list of matches is passed into. That function is defined in your settings as a string path:
In order to override that behavior, all you need to do is write your own function, and then change that setting to your function path. So, to avoid multimatching entirely, you can put a function like this one somewhere in your game - let's say
world/utils.py
for the purpose of example.After saving that, you'd then add something like the following to your settings:
And you're done!
Other alternatives
Those are the most common two alternatives I've seen people want. If there's one you particularly want or like, share it below!
Beta Was this translation helpful? Give feedback.
All reactions