I’m looking at Witness. (That’s how far I’ve gotten in Visible Zorking.)
In places.zil, large chunks of the file are wrapped in top-level square brackets. E.g., line 392-439, then 511-621, 621-658, etc.
Anyone know what these mean? A couple of other games have them (Seastalker, Moonmist). I think I can ignore them for Visible Zorker display purposes, but I’d like to know what’s going on. Editor grouping maybe?
While I’m at it, places.zil line 947 has a stray )> which doesn’t seem to match up with any open <(. Did I miss something?
For the first question, I think it’s for commenting out code easily, because putting a ; before the [ will turn all the code into a comment. And the stray )> is literally unmatched, you’re right. Though there’s a weird unknown character on line 945, so maybe that’s related?..
And the stray )> is literally unmatched, you’re right.
I’ll have to edit it out in my syntax-coloring algorithm. (This is more of a headache than it sounds, but it’s my problem.)
Though there’s a weird unknown character on line 945, so maybe that’s related?
That’s an ASCII form-feed (ctrl-L). That’s pretty common in files of that era; it would become a page break if you printed the file on a line printer. For parsing we treat it the same as a line break.
For the square bracket ‘issue’ - I think @SomeOne2 is right, it’s a way to block off whole sections of code. If you place a semi-colon before the first bracket [ zilf will ‘comment out’ all the code until it reaches the next ] closing bracket. As you already stated, the off " char is a form-feed which I probably acted as a ‘page break’ marker. I am not sure that the )> closing marker is an issue (it would never compile with it if that were the case and in zilf it does). In my source that line is commented out anyway (hence why it is ignored and compiles). Probably just ‘source’ manipulation as there are a number of lines/blocks that have been commented out - there is a commented out ;“]” close bracket at 1083 which may have been related.
<ROOM ROCK-GARDEN
(IN ROOMS)
(DESC "rock garden")
;(ADJECTIVE ROCK JAPANESE BACK)
;(SYNONYM GARDEN)
(LDESC
"This is a rock garden in the Japanese style, east of Linder's bedroom.
A few smooth round boulders lie partly buried in a bed of gravel,
which is carefully raked to be reminiscent of flowing water.
A sequence of smaller rocks forms a zig-zag path from the bedroom door to
the south edge of the garden, where the lawn begins.
There's a door into the house, and a couple of windows.")
(FLAGS RLANDBIT ONBIT)
(NORTH "A wooden fence blocks your way.")
(EAST "You would probably get lost in the woods.")
(SOUTH TO BACK-YARD)
(WEST TO LINDER-ROOM IF LINDER-BACK-DOOR IS OPEN)
(GLOBAL HOUSE LINDER-BACK-DOOR LINDER-WINDOW BATH-WINDOW
LAWN WOODS FENCE)
(LINE 4)
(STATION ROCK-GARDEN)
(CORRIDOR 1)>
<OBJECT ROCKS
(IN ROCK-GARDEN ;LOCAL-GLOBALS)
(DESC "rocks")
(ADJECTIVE SMOOTH ROUND)
(SYNONYM ROCKS ROCK BOULDER)
(FLAGS NDESCBIT CONTBIT SURFACEBIT OPENBIT)
(CAPACITY 150)
;(ACTION ROSE-F)>
;"<OBJECT GLOBAL-ROCKS
(IN GLOBAL-OBJECTS)
(DESC 'rocks')
(ADJECTIVE ROCK)
(SYNONYM ROCKS GARDEN ROCK)>"
"? <OBJECT BENCH ...>"
<OBJECT LINDER-BACK-DOOR
(IN LOCAL-GLOBALS)
(SYNONYM DOOR LOCK)
(ADJECTIVE BACK OUTSIDE)
(DESC "back door")
(FLAGS LOCKED DOORBIT)
(GENERIC GENERIC-BACK-DOOR-F ;LOCKED-F)
;(ACTION BACK-DOOR-F)>
"Inside the house"
;")>["
<ROOM MONICA-ROOM
(IN ROOMS)
(DESC "Monica's bedroom")
;(ADJECTIVE MONICA BED HER)
;(SYNONYM BEDROOM ROOM)
(GENERIC GENERIC-BEDROOM-F)
(ACTION MONICA-ROOM-F)
(FLAGS RLANDBIT ONBIT)
(EAST TO BACK-YARD IF MONICA-BACK-DOOR IS OPEN)
(OUT TO BACK-YARD IF MONICA-BACK-DOOR IS OPEN)
(WEST TO HALL-2 IF MONICA-DOOR IS OPEN)
(NORTH TO BATHROOM IF MONICA-BATH-DOOR IS OPEN)
(GLOBAL MONICA-DOOR MONICA-BACK-DOOR MONICA-BATH-DOOR WINDOW
BED MIRROR TELEPHONE CLOSET)
(PSEUDO "CHAIR" RANDOM-PSEUDO)
(LINE 3)
(STATION MONICA-ROOM)>
Another reason for the brackets could be navigation. I don’t know what kind of text editor they used at Infocom, but the editor described in The MDL Programming Environment can move the cursor over entire MDL objects at a time, and print large bracketed structures in a collapsed form. Putting each room and its associated objects inside brackets could’ve made it easier to skip between them in a 3000+ line file.
<ROUTINE ENOUGH-TRADING> has a spurious > at the end. (15 open braces, 16 close braces.) That, plus the Witness example, leads me to think that Infocom’s compiler was able to silently ignore unbalanced delimiters.
In my source that line is commented out anyway (hence why it is ignored and compiles). Probably just ‘source’ manipulation as there are a number of lines/blocks that have been commented out - there is a commented out ;“]” close bracket at 1083 which may have been related.
Yeah, could be right - I was using the zil files I downloaded a while ago. Seems odd that the compiler would ‘skip’ mis-aligned syntax - debug nightmare
I was sure those must have been syntax errors introduced after the games were released, but it looks like MDL actually does ignore unmatched close brackets:
[KANKAN] PUBLIC:<~>@ mdl105
MUDDLE 105 IN OPERATION.
LISTENING-AT-LEVEL 1 PROCESS 1
)>hello$
hello
