Can you explain why the:
: match "n _" {
: create "front_gate" target = "room02" ;
}
didn't fall through to the normal direction processing? I've actually got a test after the match statement (not shown here) and if the test fails, it falls through to the normal processing, but when I added the create, it didn't fall through. There is no done or return statement, so it should have continued with the normal processing.
I just to say wrote a section of the document on masking, which is my (just before bedtime) quick demonstration of how overridding works in adventuron:
https://adventuron.io/docs/tut/#MaskingCommands
To be more specific as to your example:
: match "n _" {
: create "front_gate" target = "room02" ;
}
If you perform ANY operation in response to something that might otherwise be handled by the system matching "n _" or "get _" or "drop _" etc, then the system will no longer handle the command. It's treated as if it's an override.
If statements are not statement that do anything themselves, they only decide what commands will be executed, and which will not (same with match, else_if, else).
Only commands that actually do something or affect the game state are treated like overrides.
In your example, create is a command that affects the game state therefore because you put that inside your match, the direction is not handled by the system, it's treated as if you want to do the create INSTEAD of moving in the direction.
To flag that you still want to execute the system handler, you have to mask the commands that you want to execute in addition to the system handler. That's here the : mask {} command comes in. It's been in Adventuron for over a year, but you are the first person to figure out the need for it. You win some documentation. Much joy.
Maybe it's badly designed or counter intuitive, but this design is the design, for better or for worse. I hope you better understand the model now.