"Lock" can't really be a noise token, since it is the verb of the command (are you trying to lock, fire, enable, disable, etc those tubes?). "On" is definitely noise, and optional. While numbers must be numbers, the names can have numbers mixed in too. At the moment they could be entirely numbers, although I could restrict that. Still, how do you decide whether 'torpedo' is meant to be a ship component, or an object on the sensors? Lock countermeasure (on) torpedo? Or Lock (S.S.)Countermeasure (with) torpedo ?
And then what happens when you come up to a port, and try to "dock lock" instead of "lock dock"? :)
What I have gone with so far is a general layout of {verb} {listenerCategory {all|list of numbers}} {parameters}. Sometimes there are no parameters ("enable all drives"), sometimes there are no listeners ("course 90"), but the order holds.
The parameters are the most flexible part, but often limited to just one or two values anyways. Sometimes the noisewords might be required to disambiguate the command, such as when the parameters start with a number. I don't have any such situations in the current configuration, and I can't think of a good example. Even "load tube 1 2 3 40" would correctly match the 40 as your ordnance type and not torpedo tube #40, thanks to backtracking.
Note: I don't actually check the correctness of the names or categories in the regex; provided that it looks like a specific command from a high level view, I capture the fields and check them in the addCommand() function.
If the parameters are not named, then they have to be in a fixed order. ("helm 180 5" vs "helm course 180 speed 5" or "helm speed 5 course 180)
The listeners are restricted to an exact match from a list of category synonyms. "Disable all R" does not shut down the reactor and the radar and the railgun in one go; you have to do those separately unless the config has defined a common category for them. By default, the config intends such a set of actions to cost multiple turns unless there is such a common category.
Object targets, on the other hand, only select a single object from your sensor database hash, and that allows a fuzzy match, with a clarification response if there is not exactly one result.
As far as layout, I've got a trinary operator chain where I link each regex to a function call (addCommand()) that checks params, munges them into a set of sub refs and then queues the final result up for action when the turn ends. ("Belay that" is available to pop the order queue, just in case) :)
Each command has its own regex or three to provide for alternate syntax without getting too line-noisy, and adding new commands is just a matter of tacking a new $cmd =~ /regex/i ? addCommand('what', $1, $3, $2) : type line onto the end of it.
In reply to Re^2: Regex - Matching prefixes of a word
by SuicideJunkie
in thread Regex - Matching prefixes of a word
by SuicideJunkie
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |