Would I be right to presume that this match statement should appear before any others with direction-specific commands?
I used refresh_header in my previous game (to update the score) and it didn't seem to do anything. I'll try again.
Viewing post in How do you do movable enterable objects?
The match statement could go anywhere really because it's made specific by the inner if.
Refresh header *should* work immediately. If it doesn't then it's a bug.
A system action is overridden if one or more unmasked actions occur. A match itself is not an action, nor is an if statement, because they don't actually do anything, they are only control of flow statements.
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.
I'll see what I can document better but the common sense stuff is mapped by default as system actions (or defaul handlers if you prefer that):
get
drop
wear
remove
Examine
Directions
Put xxxx in yyyy
Take xxx from yyyy
Get all
Drop all
Wear all
Remove all
Load
Save
Inventory
Quit
Ramsave
Ramload
Unknown verb
Unknown noun
Unknown examine target (you see nothing special)
Assume that all these handlers will execute if you don't execute something yourself. Matching is not executing something. It's a statement that is not a match or an if or an else if or an else.
If you execute one line of non control code (match,etc) then the system handler is not skipped.
Of course you can choose to reapply the system handler via :get; :drop; etc commands, but they won't be executed themselves.