currently using the ZIL extension in VSCode (on macos) but happens with the vanilla macos text editor as well.
anywhere i have a string (like in an LDESC, FDESC) any carriage return in the code becomes a tab in the final z5 game. and if i try to indent my code so it looks nice, i get a ZSCII warning in the compiler and a garbled character in the final game.
so, the only option seems to be to never hit ‘return’ and simply let my long descriptions run off to the right of my text editor forever; and to never indent within a long string, making the code harder to read?
is there a way to use normal formatting in the text editor that will display properly in the final product?
It was a while ago that I used VSCode (and I’m not on MacOS), but this seems to be an editor problem. You may try to change tabs to spaces for indentation.
You can also try by writing the text as this (from Zork 1)
<ROOM SOUTH-OF-HOUSE
(IN ROOMS)
(LDESC
"You are facing the south side of a white house. There is no door here,
and all the windows are boarded.")
(DESC "South of House")
(WEST TO WEST-OF-HOUSE)
(EAST TO EAST-OF-HOUSE)
(NE TO EAST-OF-HOUSE)
(NW TO WEST-OF-HOUSE)
(SOUTH TO FOREST-3)
(NORTH "The windows are all boarded.")
(FLAGS RLANDBIT ONBIT SACREDBIT)
(GLOBAL BOARDED-WINDOW BOARD WHITE-HOUSE FOREST)>
When you write multiline text, start it in column 1.
yeah, that’s how i’ve been writing multiline text. but that doesn’t fix the problem that i get an unwanted TAB in the game at the carriage return after “There is no door here,”.
so i actually CAN’T use multiline text in the editor since it will insert a tab in the game at every line break.
Maybe check that it’s using appropriate line endings? I wonder if the compiler requires LF instead of CRLF? (Although being on OSX I would expect it to default to LF). There’s a selector in the lower-right corner of the window to switch line ending encodings for the current file.
and this is what the text looks like in VSStudioCode using the ZIL extension:
"Name of Game"
<VERSION XZIP>
<CONSTANT RELEASEID 1>
"Main loop"
<CONSTANT GAME-BANNER
"Name of Game | Description of Game | By Your Name Here |
Year and any other useful info">
<ROUTINE GO ()
<CRLF> <CRLF>
<TELL "Opening text, something that sets the scene." CR>
<INIT-STATUS-LINE>
<V-VERSION> <CRLF>
<SETG HERE ,ROOM-OF-PARTS>
<MOVE ,PLAYER ,HERE>
<V-LOOK>
<MAIN-LOOP>>
<INSERT-FILE "parser">
<ROOM ROOM-OF-PARTS
(DESC "Room of Parts")
(IN ROOMS)
(FLAGS LIGHTBIT ONBIT)
(LDESC "This is a small stone-lined claustrophic room with no apparent door. A tarnished brass sconce is
embedded in the otherwise featureless north wall. A thick wooden table occupies the center of the room;
piled on top of it you see papers and manuscripts as well as a large paperweight.")
>
<OBJECT PAPERWEIGHT
(LOC ROOM-OF-PARTS)
(SYNONYM PAPERWEIGHT WEIGHT)
(DESC "paper weight")
(FLAGS TAKEBIT)
(FDESC "For the first time you notice an an extraordinary paperweight with a needlessly long and
verbose description so as to maximize the ammount of verbiage needed to demonstrate
dumb formatting problems.")
(LDESC "It's a surprisingly complicated extraordinary paperweight with a needlessly long and
verbose description so as to maximize the ammount of verbiage needed to demonstrate
dumb formatting problems.")
(SIZE 7)>
Ok. The indentation that you use inside the "" are not tabs, but spaces. So the string contains bits of 9 spaces between some words. That’s the way Zilf compiles the strings. Then it is up to the interpreter how it handles them, I guess Lectrote eats some of them.
In short, Zilf ignores LF/CRLF/CR but preserve spaces. One solution to this is to multi-line strings in the following manner instead:
"Name of Game"
<VERSION XZIP>
<CONSTANT RELEASEID 1>
"Main loop"
<CONSTANT GAME-BANNER
"Name of Game | Description of Game | By Your Name Here |
Year and any other useful info">
<ROUTINE GO ()
<CRLF> <CRLF>
<TELL "Opening text, something that sets the scene." CR>
<INIT-STATUS-LINE>
<V-VERSION> <CRLF>
<SETG HERE ,ROOM-OF-PARTS>
<MOVE ,PLAYER ,HERE>
<V-LOOK>
<MAIN-LOOP>>
<INSERT-FILE "parser">
<ROOM ROOM-OF-PARTS
(DESC "Room of Parts")
(IN ROOMS)
(FLAGS LIGHTBIT ONBIT)
(LDESC
"This is a small stone-lined claustrophic room with no apparent door. A tarnished brass sconce is
embedded in the otherwise featureless north wall. A thick wooden table occupies the center of the room;
piled on top of it you see papers and manuscripts as well as a large paperweight.")
>
<OBJECT PAPERWEIGHT
(LOC ROOM-OF-PARTS)
(SYNONYM PAPERWEIGHT WEIGHT)
(DESC "paper weight")
(FLAGS TAKEBIT)
(FDESC
"For the first time you notice an an extraordinary paperweight with a needlessly long and
verbose description so as to maximize the ammount of verbiage needed to demonstrate
dumb formatting problems.")
(LDESC
"It's a surprisingly complicated extraordinary paperweight with a needlessly long and
verbose description so as to maximize the ammount of verbiage needed to demonstrate
dumb formatting problems.")
(SIZE 7)>
Ah, yeah, so it takes some getting used to, but the line break is counted as a space in ZIL. Remove the space from the end of the lines and you won’t get that.
Honestly, if it makes it any better, you get used to it after a while!
That’s probably right. You can only print tabs in version 6 of ZIL. I recommend if you haven’t already, turn indentations from tabs to spaces. You may hate it. I prefer it. I format all my code like this:
<ROUTINE EXAMPLE ()
<COND (,REAL?
<TELL "I indentate a lot
further and depending on the line, everything
lines up on mine. But you get used to it.">)
(T
<TELL "Indentation is 5
spaces on the first level of indentation, then
matches whatever it needs to. Not fixed.">)>>
Like many things in ZIL, this is more complex than it seems. As seen in the compiler source and unit tests, the expected behavior is:
Vertical pipe (|) becomes a line break (ZSCII 10).
You can change this to a different character: for example, <SETG CRLF-CHARACTER !\^> to match Inform 6. In that case, | will be preserved as a normal character, and everything below will apply to the new character instead.
Newline (ASCII 10) usually becomes a space (ZSCII 32).
Newline following |, however, is ignored.
Carriage return (ASCII 13) is always ignored.
Tab (ASCII 9) is always preserved, but only a V6 interpreter is likely to print it correctly.
Outside of V6, as you saw, you’ll get warning ZIL0410 (ZSCII 9 (tab) cannot be safely printed in Z-machine version 5), and the interpreter will probably do something disappointing.
Sometimes, two spaces in the source code collapse into one in the compiled string. This is configurable:
By default, two spaces immediately after . or | become one space.
With <FILE-FLAGS SENTENCE-ENDS?>, two spaces immediately after ., !, or ? become a V6 sentence space (ZSCII 11).
With <SETG PRESERVE-SPACES? T>, spaces never collapse.
None of this applies to newlines, even when they become spaces.
The upshot is that it’s easiest to treat line breaks in a string just like you would when writing quoted dialogue in a book:
Only wrap the string between words, or at an explicit line break (|).
Don’t indent the wrapped line(s), even if the first line was indented.
Don’t leave spaces at the end of the line.
But I agree it’s kind of ugly (like everything else designed in the 1970s). If you’d rather indent your source code and control exactly where the spaces go, you can harness the power of macros:
(FDESC %<STRING
"For the first time you notice an an extraordinary paperweight with a needlessly long and "
"verbose description so as to maximize the ammount of verbiage needed to demonstrate "
"dumb formatting problems.">)
I didn’t know about this! This is going to be so helpful in my new project, where full stops collapse double-spaces but not question marks or exclamation marks…
on the lack of tab outside .z6, an interesting alternative is possible:
first, set the editor to converting the tabs into spaces.
then add in your code not only <SETG PRESERVE-SPACES? T> but also " " (eight spaces) as an abbreviation.
I think that this allows tabs in the story text.
