Problem: Too much text in quotation marks

I’m running into a bit of a problem (message) while writing my first works of IF. I have a few sections of text—right now just say phrases, in one story for the brief ending scene and in the other for some hopefully-newbie-friendly help text—that are a few paragraphs long each. When I try to compile the story files with these texts, I get the following complaint:

I’ve checked both stories’ texts as carefully as I could, and I can’t find any misplaced quotation marks or other similar errors. Furthermore, I can delete arbitrary chunks of text from either say phrase and they will eventually compile; if it were a syntactical problem in a specific part of the text, presumably it would only compile when I removed or fixed that part of the text. Seems like length is the issue, then.

Searching through the manual showed me that the default maximum text length is 1000 characters. I consulted an online character counter, and these texts appear to clock in at somewhere around 3500-4000 characters total (I’m not sure whether it’s including the whitespace statistic within the total character count, so I added it anyway, figuring that overestimating was the safer bet). Okay, that should be an easy fix:

Use maximum text length of at least 6000.

Copied and pasted directly from the manual, even, but unfortunately the stories still won’t compile. I even tried increasing the setting to a ridiculously high limit, like 60000, and had no luck. (The story format is Glulx, by the way, and I’m writing on OS X 10.12.6 using Inform 7 6M62 with the quick fix for the story pane not displaying.) I get that word/character counters are fickle creatures, and I don’t know what Inform is counting specifically, but surely my five-paragraph, 600-or-so-word texts aren’t somehow exceeding sixty thousand characters in length? Meanwhile, when I snip out chunks from the ending text until Inform will accept it, the character counter is still reporting it as about 3351 characters long; that’s well over the default 1000-character limit. What is going on?

There are plenty of workarounds, of course. Cutting the text down so that it fits the apparent limit is always an option. I’ve found that splitting the “long” text into multiple smaller text substitutions works (Report asking for help: say “[help one][line break][help two]”, with [help one] being the first half of the text and [help two] the second). In the case of the help text specifically, I could skip the “help” command and provide the brief instructions in a separate file as part of the release, or not write anything at all and just include the IF postcard. So I’m able to accomplish what I want, in the end, and this error isn’t preventing me from creating or testing or releasing anything… but it still seems like this shouldn’t be happening with the stated defaults/changed settings, or like I’m making some sort of mistake I’m just not catching. If this is in fact a bug, I’d like to be able to report it correctly, and if it is my mistake (not at all unlikely!) then I’d love to understand exactly what I’m doing wrong.

Just in case you’d like to see the “too-long” text for yourself, this is a (slightly modified, silly fantasy nonsense, still extremely rough) version of one story’s ending cutscene. According to the linked character counter, it’s 3293 characters, or maybe 3874 with whitespace. It won’t compile as-is, but if you delete, say, the second-to-last paragraph (“Then he smiles…”), the compile will complete. Cutting out that specific paragraph and the whitespace around it brings it to 2850 characters, maybe 3351 with whitespace.

[spoiler]And that’s it. That’s the last ingredient you need. You wish you could feel pleased with yourself after that ordeal, but there’s not much satisfying about having to overcome that angry brick wall Kil calls a pet. Nothing left to do but get to work, you suppose.

For all the trouble you went to, it’s not that difficult a preparation to put together: mix the ingredients; get mucus all over your fingers (ugh); set the slug fins aside, as the customer will need to rehydrate those on his own when he’s ready to apply the wrap and add the core…

The shop door bell jingles and you look up to see an orc with wildly green hair and with paler skin than most folks around here, dressed in something resembling typical Silverport fashion but greeting you in Trade tinged with a slight accent you can’t place. Beneath the short sleeves you can see bandages, a bit worn and probably ready for replacement, covering most of his right arm. That’d be the customer, then. Hmph. At least Mr. Inconvenience had the courtesy to make his pickup on schedule rather than wasting more of your valuable time.

You explain to the customer how this treatment is meant to work, how to apply it, how long this amount should last him. You attempt to hide your exasperation while you detail the substitution you had to make, and you fail spectacularly. The man smiles politely and apologizes for the confusion. His day has been very hectic–arranging for guides as he heads further upriver and then east, sending a message along to confirm with his contacts in Mésyum, acquiring seasonally appropriate clothing (apparently it’s much cooler in Omaithani this time of year, wherever that is)–but he was remiss not to clarify things further for your mother. All the same, he says, it is a pity that you don’t have nursefish down here. Such useful creatures, and quite the spectacle when leaping from the water at sunset. You decide against telling him about Silverport’s local spectacle, people throwing crispy, half-dried holothures back into the ocean because they’re too bloody stubborn to not die on their own; better that you just move this conversation along so he’ll pay and leave already.

Still, as he reaches across the counter to hand you the money, you can’t keep your eyes from running up and down that bandaged arm, wondering just what sort of burn is under there to require all this fuss. You are also a spectacular failure at pretending not to stare, but rather than take offense the customer simply smiles again. Tending and protecting the Grand Gardens of Omaithani requires dedication, he says. Better that the [italic type]Unashav[roman type] and their hounds scar him than scar the earth and stifle the garden’s gifts forever, yes?

Then he smiles, thanks you again for your assistance, makes a quick gesture that you assume is a farewell, and sweeps back out the door to whatever his next stop is on the way to Mésyum. You sigh and slump dramatically over the counter; Izri lands on your head and nuzzles your hair, making sympathetic chattering noises. Now that the order’s done and dusted, you’re about ready to get out of here yourself. Upstairs, specifically. To bed.

After all, you’ve probably got, what, another thirty minutes before Mother and Kil make it back from the shops?[/spoiler]

Thanks in advance for any help you can provide! Even if it’s just pointing out a very silly mistake somewhere, haha.

1 Like

The easiest solution is just to break the text into multiple strings.

Instead of this:

When the ending scene begins: say "a lot of text...".
Try this:

When the ending scene begins: say "first parargaph[paragraph break]"; say "second paragraph[paragraph break]"; [etc]

Or use substitutions.

After examining the historical froodle:
     say "A bunch of historical text. [froodle2]".

To say froodle2:
     say "Lots of data on the froodle. [froodle3]".

To say froodle3:
     [...]
1 Like

Upon some investigation, I find that the “Use maximum text length…” option has nothing to do with the I7 compiler’s built-in limit. It determines how much space is allocated in the game file for dynamic string manipulations. (For example, a “substituted form of …” has to consume as much game memory as the string originally took up.)

The built-in compilation limit is whatever it is – 3000 characters looks right. As you found, it only applies to single literal strings.

2 Likes

Ah, that makes some sense. The manual’s a bit misleading (or maybe I’m just misreading something), then, but yeah, that’d probably explain it. Thanks for looking into it and clarifying. As I said, I’ve already found some workarounds that get the job done, and the two solutions suggested by Hanon and Draconis should work just as well, so I’ll live. Thanks, all!

The current confusing state of the manual appears to be something of a holdover from earlier versions of Inform, when the source code had to distinguish between dynamically manipulated text (which was called “indexed text”) and constant text strings (which was called just “text”). With text, Inform knew at compile time how much to memory to set aside, but with indexed text that could grow unpredictably, it has to set aside some memory that in theory might or might not be enough.

Back then, that chapter of the documentation was specifically about indexed text, and the setting was “maximum indexed text length,” and the documentation was explicit that this was about memory set aside for dealing with dynamic indexed text. If you put too much stuff in quotation marks, you’d still get that “you forgot a quotation mark” error at compile time, but this didn’t necessarily involve indexed text at all.

Under the hood, I think Inform still treats text strings and dynamic text differently, but they’re both called “text” in the source code and it just automatically converts one to the other as needed. So now the first section of that chapter (§20.1) has a note about how there used to be two different kinds. And now the discussion in §20.2 talks about text and “maximum text length”–but this is still, as zarf said, about dynamic string manipulation, and the compile-time check on length of quoted strings comes from somewhere else. (Note that the manual talks about run-time crashes and weird effects when you exceed the memory limit, but in this case it just refused to compile.) But now it’s more confusing, because both of these things are called just “text.”

Anyway, as you’ve seen, there are workarounds, so it’s no biggie I hope!

Love it when Google throws up the answer to my problem in the very first hit! Great workaround!

4 Likes