Command parsing is partly hardcoded, partly softcoded. The Programmers Manual explains how it works here:
http://files.moo.ca/1/1/7/ProgrammersManual_8.htmlBasically, it goes through #0:do_command(), and if that doesn't exist or it returns 0, then it starts the hardwired parser, then if that can't find a match, it calls player.location:huh() which kicks off a bunch of extra steps to find an appropriate match, basically letting these objects in order try to handle it:
- The player class (which includes Feature Objects)
- The room again (which matches most exits as verbs)
- The player again (which tries to do some extra softcoded matching like on ~playername, and also tries extra hard to make 'give', 'get', and 'drop' work)
One of the interesting side effects of all this is that if you end up with your location set to an invalid object like $nothing, none of your feature objects work. One way you know you're in this kind of command-blackhole is if you get the message "I
couldn't understand that" instead of "I
don't understand that"
JHCore does a little extra matching, adds the 'focus object', and will try to match verbs on indirect objects if they're unambiguous (so "read note" will work if there's only one note on a postboard, and you won't have to type "read note on postboard"). All these steps can be extended by any of the objects involved.
Giving good feedback on ambiguous matches is really tricky the way the parser's currently written. One of the things we did on E_MOO was to create a fancy new entirely softcoded parser that did handle ambiguity better (and it didn't need this Rube Goldberg chain of verbs to match commands), but it was a major project.