(Desktop TA, v5.8)

In a NEW game, I have a regex command named "kick" and an object named "ball". The regex pattern for kick is ^(kick) (?<object>ball)$. The object capture group will only work if the command is, literally, "kick ball". It will NOT work for "kick bal". If the ball's alias is "football", then "kick football" should work, but it also won't. So (?<object>ball) is basically acting as (?<text>ball) -- the object has to be spelled EXACTLY as in the capture group; abbreviations, aliases, and alt names won't be recognized.

I always take care to mention this issue when I suggest object patterns like that.

I originally suggested the ^kick (?<object>ball)$ pattern in response to someone who had a command kick ball and wanted some code that would let them check if there was a ball in the current room. They were absolutely insistent that they didn't want to use kick #object# and then check if the object was a ball. They wanted the command to only work for that exact string.

I have no idea why a user would want this behaviour, but they were absolutely sure about what they wanted. So I provided the ^kick (?<object>ball)$ pattern as a case of "I still think this is a dumb thing to do, but it's the easiest way to do what you asked for". The OP didn't want the command to accept partial names, because they don't use them.

Actually, there's a legitimate use case in "click only" games - because then the command typed will always include the object's alias exactly, so it might be easy to handle clones like this. But in most cases, I wouldn't recommend using a pattern like this. And even in those cases, I think it would be easier to use a kick #object# pattern and a simple check for the object's type. Or even a verb.

So, this capture group works entirely as intended.

If you want to make a pattern which does accept abbreviated names, you could use ^kick (?<object>b(a(ll?)?)?)$ - and for alternate names, you could use something like ^kick (?<object>f(o(o(t(b(a(ll?)?)?)?)?)?)?|b(a(ll?)?)?)$. However, in these cases you will find that the command will match other objects (for example, "kick bal" could match a balcony - patterns of this form impose constraints on the command the player types, not the object matched.

^kick (?<object>ball)$ is really just ^kick (?<text>ball)$, and then object = GetObject(text), so I don't see how this capture group is particularly useful. It would be much more useful if it would work capturing a specific object from different possible strings, just like ^kick (?<object>.*)$ does.

The flexibility it would add might not seem significant in simple commands, but in complicated commands with a lot of scripting and complex regex patterns, it definitely would be helpful. In my own text game, I have many such complicated commands, and because of this lack of functionality, I've had to make multiple commands for the same command many times over, which really adds to the complexity (and confusion). I would consider this to be a poorly designed feature.

^kick (?<object>ball)$ is really just ^kick (?<text>ball)$, and then object = GetObject(text)

No, it isn't. It matches the text against aliases of objects in scope, just like the regular object matching. So if you want to force the player to type "kick ball" but there's more than one ball in the game (clones, for example, or multiple different balls), it will select the one in the room or present a disambigualtion menu.

I still don't see a point to doing this. There are better ways to do it. But it serves a kind of a purpose; using a regex to achieve something that Quest otherwise can't do.

I would consider this to be a poorly designed feature

It's a feature of the regular expression language, which was specifically designed to match patterns against strings. Regular expressions have no concept of objects.

Using a regex like that is an ugly workaround to fulfil an illogical request; but it gave the original poster exactly what he asked for.

If you want a command to only apply to a specific object, you need to do that in Quest code, not a regex.

It would be much more useful if it would work capturing a specific object from different possible strings

That pattern matches multiple possible objects against a single string, which is exactly what someone requested. I think that it's an illogical thing to ask for, but it's what they wanted.

If you want to match multiple strings against a single object, Quest already has features for that: verbs, changecommandscope, or some combination depending on your exact situation.

You're complaining that a hammer is badly designed because it damages your screws. It's not a bad feature; it just isn't the right tool for the job.

(Sorry that sounds kind of condescending… was writing in a hurry before dinner)

No, it isn't. It matches the text against aliases of objects in scope, just like the regular object matching.

But the regular object matching also matches against abbreviations and alt names, so it does not act the same way.

If you want to match multiple strings against a single object, Quest already has features for that: verbs, changecommandscope, or some combination depending on your exact situation.

I'm only using commands in my game. I'm not familiar with changecommandscope. I see it briefly mentioned under "Advanced Scope For Items" in the documentation, but the explanation is inadequate.

You're complaining that a hammer is badly designed because it damages your screws. It's not a bad feature; it just isn't the right tool for the job.

I disagree. I'm complaining about that feature because it doesn't do much of anything. As for the OP that you mentioned previously, I hear what you are saying, but that isn't the focus of what I'm talking about.

(Sorry that sounds kind of condescending…

You are right -- your tone very much comes across as condescending.