The newspapers_upper_living_room are here. They are undescribed and fixed in place. The printed name is “newspapers”. The description is “Four issues of the local newspaper ‘The Dike Herald’. A brief glimpse at one of the headlines (‘[one of]New pharmacy opened in Aventoft![purely at random]’) ensures you that you don’t want to read any of this boring stuff.[Erwaehnung_Notiz]”. Understand “newspapers” and “newspaper” as the newspapers_upper_living_room.
To say Erwaehnung_Notiz:
If notiz_spieker is unflagged:
Now notiz_spieker is flagged;
Now notiz_spieker is on the glass table;
Say " A small piece of paper peeks out from under one of the newspapers.".
The variable is set, the object is moved, but the Say command is simply ignored. How can that be?!?
I don’t know the exact reason but To say Erwaehnung_Notiz is called twice internally. The second call is used to print the text but the notiz_spieker has already been flagged on the first call.
Yeah, you want to be careful of modifying variables in a “to say” phrase because Inform will sometimes expand it to check if it’s empty or whatever, without actually saying it. So you can’t depend on it being run only once. IIRC you can use “if expanding text for comparison purposes” or something like that? Aha, yeah: Very odd bug -- mine or Inform's? - #4 by zarf or How to be sure of whether an action has taken place, and thus time should tick? - #5 by drpeterbatesuk or probably a bunch of other topics. Unfortunately that’s not in the documentation anywhere, I don’t think: you’d have to actually read the Standard Rules to find it.
Yes, good catch. Only in this case we want “not expanding…”
To say Erwaehnung_Notiz:
if not expanding text for comparison purposes:
If notiz_spieker is unflagged:
Now notiz_spieker is flagged;
Now notiz_spieker is on the glass table;
Say " A small piece of paper peeks out from under one of the newspapers.".
and put in all the code that I want, and in Inform 7 I have to use an… “undocumented feature” (at least for me) to be able to use basic features. But c’est la vie, lesson learned and memorized for the next time. Thanks again!
The trick is that I7 offers a lot more ways to customize the results of an action. Instead of putting side effects in the description text, I7 expects that you’ll put those side effects in a rule about the “examining” action. (Because, as you’ve seen, side effects embedded in text get evaluated when it checks things like “does this object have a description at all”.)
That is exactly the reason why I used English for comments as well as variable names. Also, it feels more natural to me to do everything in the same language. Ever since I first touched a computer (now almost 50 years ago), it seemed more natural to use English for everything. The one exception I can recall was this Dutch effort at a localized programming language called ECOL based on ALGOL, using Dutch keywords for everything (so we had constructs like “ALS … DAN … ANDERS” instead of “IF … THEN … ELSE”.) I even created a small compiler for ECOL … but in the end it was just not really worth the effort, there are not that many keywords to learn in most programming languages anyway. Most of the effort in learning a new language goes into learning its ecosystem.
This is the result of a convenience feature: I7 treats an empty description as nonexistent. That is, if you have an object description which is the empty string, I7 gives the “see nothing special” response instead of printing a blank line. This is more intuitive for authors.
However, to do this, it has to resolve all the bracket-bits without printing anything! (It can’t tell whether "[phrase]" is the empty string without running the phrase.) So then you have to think about side effects when you write the phrase.
There’s no better solution, unfortunately. If it didn’t do this, the rules for when “you see nothing special” appears would be hard to explain.
Well, I suppose it could have a special routine to resolve “[phrase]” to a buffer, then choose to print either the buffer or “you see nothing special…” if the buffer was empty…
Right, but if the resolved text is then printed (if needed) directly from the buffer rather than resolving it a second time, the interpolated code is run only once, not twice, for each print. It’s the difference between
if "[my game-state changing routine]" is "", say "You see nothing special";
else say "[my game-state changing routine]".
[potentially runs my game-state changing routine twice]
and
let temp-text be the substituted form of "[my game-state changing routine]";
if temp-text is "", say "You see nothing special.";
else say temp-text.
[always runs my game-state changing routine once]
Unfortunately that plan still doesn’t match up to what the naive author expects. If the buffer winds up empty, you’ve run the interpolated code once but you print it zero times (because it’s a “see nothing special” response). Bugs still result.
Also, buffer printing doesn’t encode style changes, so you lose italics etc.
Valid points. But what the naive author expects is conditional on context, I feel. If you want to increment a counter every time something is examined, for example, this scheme would work as expected.
It obviously would not work as expected if you were expecting your game-state changing code to run only when the special case didn’t apply. In that case you would I think have no option but to use the undocumented if expanding text for comparison purposes.... approach.
And that’s why I think it’s best to just not put things with side effects in a text, if possible. If you keep track of the number of examinings in a “carry out examining” rule instead, it’ll work as expected.