You have introduced a couple of new terms here. What is a "system action" and an "unmasked action"? They're not mentioned in the doco. In fact, "action" isn't even defined. The doco uses it in a generic sense and it seems to be the command defined by the pattern in a match statement, but you said a match is not an action. Now I'm confused.
It sounds like a system action is a predefined action like the inbuilt directions, GET and DROP. It would be nice if you could provide a list of these and what they do, otherwise how do we know that they exist or whether we need to override them?
I don't think the directional match statement can go anywhere, as I might have another specific match statement like:
: match "n _" {
: if (is_at "front_porch" && is_door_closed) {
: print "You'll have to open the door first.";
: done;
}
}
In this case, I would want the generic override to be performed first, then the specific override, then the system one.
It would really help if you could explain how commands are processed. This is sorely missing from the doco. I've also noticed that this explanation is missing from barriers. In my last game, I hade two different barriers that applied to the same room. Each had different conditions and I had no idea which one would take priority. Coincidentally, whatever I did seemed to work, but I don't know why, as the conditions were competing with one another.