This has been causing me no end of grief, but I’ve finally figured out what’s happening to enough of a degree that I can try to describe it here…
I want to test whether a text property on value is set, so I am using a test of the form:
[1]if the text-prop of the item is not "":
[2] say text-prop of the item;
The problem is that, if the text property has certain “to say” substitutions in it, the test itself actually prints the text (and the test comes up false). In other words, line 1 above prints the text, while line 2 never fires. Remove those substitutions, and line 1 performs as expected, with line 2 firing as it should.
What’s more, when the test spuriously prints the text, it does so as if the text were passed by reference rather than by value (I think that’s the right way to put it). Basically–it prints the same thing every time, even if there are random variations.
By way of example, if the following variable is assigned to the property (i.e., “text-prop of X is atmospherics”), then everything works as it ought to:
Atmospherics is initially "[if a random chance of 1 in 5 succeeds][one of]Atmospheric text 1[or]Atmospheric text 2[or]Atmospheric text 3[at random].[else][run paragraph on][end if]"
But add the following, and the issues described above are triggered:
Atmospherics is initially "[if a random chance of 1 in 5 succeeds][interrupt][one of]Atmospheric text 1[or]Atmospheric text 2[or]Atmospheric text 3[at random].[resume][else][run paragraph on][end if]"
The test itself prints the text, the “say” phrase itself never fires, and the first random option chosen is chosen every subsequent time that the phrase prints text (4 out of 5 times it prints nothing, of course).
It shouldn’t really matter what the contents of the substitutions are, but I include them under spoiler:
[spoiler][code]To say interrupt:
suspend standard line input;
say run paragraph on.
To say resume:
resume standard line input;
say run paragraph on.
To suspend standard line input (this is the cancel standard line input rule):
cancel line input in the main window, preserving keystrokes.
To resume standard line input (this is the resume standard line input rule):
say “[paragraph break][command prompt][run paragraph on]”;
re-request line input in main window.
To re-request line input in main window:
(- glk_request_line_event(gg_mainwin, stored_buffer + WORDSIZE, INPUT_BUFFER_LEN - WORDSIZE, stored_buffer–>0); -)
To cancel line input in the/-- main window, preserving keystrokes:
(- glk_cancel_line_event(gg_mainwin, gg_event); stored_buffer–>0 = gg_event–>2; -)
[/code][/spoiler]
So. In truth, I don’t need to test whether the property is set at all. I just need to print it, since printing an empty string should have no real effect. In other words, I don’t need help working around this. But boy is it weird, and very likely indicates an edge case that needs work in Inform’s new handling of text types. If anyone wants to take a crack at reproducing, that’d be great. I tried to come up with a simpler case myself but failed to reproduce it.