Printing privately-named things in lists

I suspect this is related to How long can Z-Machine test names be, and how to modify that length? but I’m interested as to what is going on and why.

I have some code to write out what things need to be done and, at the end of the game, what you missed. I define a task as something with a rule, non-spoiler text and spoiler text.

chapter tasksing

tasksing is an action out of world.

understand the command "t" as something new.
understand the command "tasks" as something new.

understand "t" as tasksing.
understand "tasks" as tasksing.

carry out tasksing:
	if number of undone potential-tasks is 0, say "You did everything!" instead;
	say "You could still [list of undone potential-tasks].";
	now spoiler is true;
	say "Here is spoiler detail on your undone tasks: [list of undone potential-tasks].";
	now spoiler is false;
	the rule succeeds;

spoiler is a truth state that varies.

for printing the name of a potential-task (called pt) when spoiler is true:
	if spoiler-text of pt is empty:
		say "[printed name of pt]*";
	else:
		say "[spoiler-text of pt]";

To process (RL - a rule): (- ProcessRulebook({RL}, 0, true); -)

chapter defining tasks

definition: a potential-task (called mt) is undone:
	process the missed-rule of mt;
	if the rule failed, yes;
	no;

a potential-task is a kind of thing. a potential-task has a rule called missed-rule. a potential-task has text called spoiler-text. [a potential-task is usually privately-named.]

visit2 is a potential-task. printed name of visit2 is "find another room". spoiler-text of visit2 is "visit room 2". missed-rule of visit2 is the r2-visited rule.

this is the r2-visited rule: if r2 is unvisited, the rule fails;

visit3 is a potential-task. printed name of visit3 is "visit room 3". missed-rule of visit3 is the r3-visited rule.

this is the r3-visited rule: if r3 is unvisited, the rule fails;

visit4 is a potential-task. printed name of visit4 is "visit room 4". missed-rule of visit4 is the r4-visited rule.

this is the r4-visited rule: if r4 is unvisited, the rule fails;

chapter the "game"

r2 is east of r1. r3 is south of r2. r4 is west of r3. r1 is north of r4.

(Note “process” is not necessary in Inform 6L or later, but it simply avoids line breaks after rule processing in 6G. But I’ve tried this in later compilers and am still getting the behavior.)

Now this works in Glulx and Z-Machine. However, if I replace “visit” with “visitroom” the Z-Machine gives the text below, and “visittheroom” in Glulx gives the text below. I assume that’s due to USE_DICT_SIZE being 9 for Z, 12 for Glulx.

>t
You could still three potential-tasks.
Here is spoiler detail on your undone tasks: three potential-tasks.

The expected output appears with shorter variable names, e.g.:

>t
You could still find another room, visit room 3 and visit room 4.
Here is spoiler detail on your undone tasks: visit room 2, visit room 3* and visit room 4*.

This is expected–I want to make sure spoiler text appears in the second line, and the asterisk warns me as a programmer that I need to add spoiler-text.

I understand that variable name length may cause Inform to say “wait, I can’t do that, so I’ll print a general list.” But I don’t fully understand why, so I’m a bit curious. Still, I have a clear work-around there.

However, what I really want to do is make the variables all privately-named (uncommenting that bit of code,) so if you ask another NPC about things, you won’t stumble on them by accident.

However, even though I’ve defined a printed name for each rank, I still get “You could still three potential-tasks” instead of the details.

Is there any way to be able to print out the task information while using printed names?

I suppose I could use custom code where I print out commas and such manually, but I’d really like to use inform’s “[list of]” syntax if possible.

Thanks!

Your example doesn’t compile in 6M62, and I’m not entirely sure what changes you’re making when you talk about problems. However:

By default, in dict words, nine characters are significant on both platforms. (Punctuation and accented characters affects this, but ignore that for now.)

I think what you’re running into is Inform’s logic for assuming two objects are indistinguishable. If two objects are of the same kind and have no differences in their vocabulary, they are indistinguishable and get grouped in printed lists.

“visitroom3” and “visitroom4” are indistinguishable because their only vocabulary is the dict word 'visitroom'. If you define objects with no synonyms – which is what happens in the usually privately-named case – then they’re always indistinguishable!

You could avoid the whole problem by making sure that potential-tasks can’t be parsed by the ask-NPC-about-stuff actions. This might require adjusting the grammar for those actions.

You could also make potential-tasks a “kind of object” rather than a “kind of thing” – but then the listing mechanism goes south for some reason. The printed lists are always empty. I haven’t dug into why this is.

I suppose I could use custom code where I print out commas and such manually

That would also solve your problem.

1 Like

Thanks, sorry for the 6M-wonky code. But I’m glad it was/seemed to be clear enough, and I appreciate the explanation!

In my actual program, I don’t think I’d be using names like task1, task2 and task3 … I just defaulted to them because I figured cutesy/detailed names might distract from the core problem! So this looks very easily avoidable indeed.

It certainly makes sense that Inform ignores the numbers. I wanted the simplest variables to run a proof-of-concept test, and it was easy just to cut-and-paste and change the numbers. This will be really handy to know for later times when I write code in my sandbox before putting it into a bigger project.

For reference, when I named the tasks visita, visitb and visitc, everything worked smoothly, as you mentioned, in Z-code and Glulx.