Order of operations in a "To say" phrase

I’m encountering weird behavior in a system I have for examining a tree. When the tree is examined at a certain point in the game, a bird is found in it, and then the bird becomes available in the room. Here is a minimal example:

The garden is a room. The player is in the garden.

bird-landed is a truth state variable. bird-landed is true.
The tall tree is in the garden.
The description is "[tree-description]".
To say tree-description:
	say "The tree is lush and green, and sways in the breeze slightly. Theres a little bird hopping around in there! ";
	if the bird is not in the garden:
		say "The bird looks directly at you. ";
		now the bird is in the garden;
		
The bird is a thing.
The description is "Small, with a red crest."

test me with "x bird / x tree / x bird".

Problem is, the text "The bird looks directly at you." never prints. However, when I remove the line now the bird is in the garden, the texts prints just fine. This leads me to believe that “To say” phases must do something strange, like running all the non-say statements, restarting the phrase, and then running all the say statements. That’s just a guess, though. Does anyone know what causes this behavior? And is there any way to work around it?

1 Like

I don’t know Inform well, but shouldn’t you have a period after now the bird is in the garden instead of a semicolon? The whole phrase block doesn’t end until a period, and IIRC Inform’s error detection and reporting around that kind of error is… not great? So that’s a place I’ll look first when weird things are happening…

1 Like

Yup, Inform has to expand text tokens (the stuff in square brackets, which here you’re using to run to-say phrase) before printing them, which leads to this behavior - when it does its evaluation it triggers the state change, so when it evaluates the token again to output it the bird’s already been moved. So probably better to handle this with an after examining the tree rule or something like that.

4 Likes

I think that’s okay in this instance, but couldn’t hurt to clean that up!

1 Like

Bah. I never use a full stop at the end of phrase blocks. If I do, I end up trying to tack on some more code and forgetting to change the period to a semicolon, which leads to confusing compile errors.

4 Likes

Ah, so I guess I’m misremembering which way around causes confusing compile errors.

The way to check for this is “unless expanding text for comparison purposes”. That determines if it’s getting printed to the screen, or just being checked for some other purpose (in this case, to see if the object has no description so it should say “you see nothing unusual”).

1 Like