Managing command arguments
-
I'm dealing with newest stable TinyMUX.
A pattern I commonly use is to make multiple versions of a command: one that interacts with an arbitrary player (usually for staff use) and one that interacts only with the player running the command.
+pizzas pepperoni - How many pepperoni pizzas do I have? +pizzas sponge/pepperoni - How many pepperoni pizzas does sponge have?The first command will have a template like:
$+pizzas *:<stuff>Since that template will match all versions of the command that have any arguments at all I end up writing ugly code to do my own argument parsing. Above is a fairly trivial case (I can just
after(%0,/)) but as the command template becomes more complex, the ugliness of the parsing code quickly outweighs the benefit of only having a single command.Is there a softcode-accessible function that will do the same parsing that the command parser does and puts the arguments either in the regular argument registers or in the general-purpose registers?
Since my objective is to keep the code readable I'd prefer to avoid using regexp. Embarrassingly, I wasn't able to get the trivial +setnum example in help regexps2 to work so hideous regexps doesn't seem like an option for me.
Is there a smarter way to handle this using the regular wildcard-based argument parsing?
-
I don't think there's a perfect solution since many people have different command practices when it comes to how to build one. The function you're looking for is still going to be regexp, though, even if you want to avoid it for readability. If you're looking for something fairly generic, my suggestion is the following:
&d.parse-regexp <obj>=^(/(\w+))? ?((\w+)/)?(\w+)?(=([\w\s]+))? &f.parse <obj>=regmatchi(%0, get(%!/d.parse-regexp), -1 -1 0 -1 1 2 -1 3)]I didn't do much testing, but this should parse parameters of the following format:
[/switch] [target/][action][=value]And then place them in the %q0-%q3 registers in the appropriate order.
You can switch things up to suit your own purposes, or someone might have a more thorough/better regexp, but this should get you started on a generic parameter parser.
-
...Goddammit. I've been looking for that regexp for quite some time. I will give it a good thorough testing sometime.
