What was the line with “or” that wasn’t working? There are a couple of tricky things about “or” in Inform, because you can write something that makes sense in English but that the compiler can’t understand. For instance, you often need to write out complete sentences on either side of the “or”; I think you always have to write “If Jane is visible or Bob is visible” rather than “If Jane or Bob is visible.”
It’s also very easy to write conditions with “or” and negation that don’t do what you want. For instance, if you write:
If Jane is not visible or Jane is not in the location
that’ll be true whenever Jane isn’t both visible and in the location. Sometimes you want
If Jane is not visible and Jane is not in the location
which requires Jane to be both not visible and not in the location. (That may not be the best example; there are some examples around of people getting confused on this, but it’s very hard to find them by searching for “or”!)
Anyway, that could be the problem – if you still have the code that wasn’t working it could help to post it.
Before reading a command when another person (called the audience) is visible: if the addressee is yourself or the adressee is not visible, now the addressee is the audience.
but i think it might have been that Felix misspelled the second addressee (just noticed that). But in the past my attempts at using or have been unsuccessful. I generally avoid using or, unless it’s something like “a thing is either this or that.”
I would love it to work for if conditions:
if player has this or player has that:
do this.
That’s what I was really griping about. But I’m probably giving up too easily and just need to play around with it more. It looks like it works for you.
So if I want to say either “shut up” or “shut the door”, why is this code saying “I only understood you as far as wanting to shut up.”?
Understand the command "shut" as something new.
Understand "shut [something]" as shlutting.
Shlutting is an action applying to an object.
Carry out shlutting:
If the noun is openable:
try closing the noun;
otherwise:
let T be indexed text;
let T be the player's command;
change the text of the player's command to "[addressee], [T]".
I don’t think there’s a handy way to redirect the shlutting action to either my or Matt’s solution to your original problem. (Mine only works at the very last stage in the parsing process (i.e. the games process of trying to understand the player’s command), when the parser has already decided that player’s command didn’t make sense. Matt’s – which may indeed may be the preferable one! – makes the parser understands certain commands (viz. any command that can’t be otherwise understood as a command to talk to the air (and then redirects talking to the air to answering it that). Both fails here, because you have made the parser already understand “shut up”, viz. as an act of shlutting.)
I’d catch the “shut up” thus:
[code]Before closing the up: try answering the addressee that “shut up” instead.
After answering Aburthnot that “shut up”: say “For a fraction of a second, a shade of shock shakes the stiffness of Colonel Aburthnot’s upper lip.”[/code]
(“Shut” standardly triggers the closing action; that’s why we need to write a rule for closing.)
In fact, up is an “object”, specifically a “direction”, not a “thing”. That’s why it doesn’t match [something] - because it’s not a thing at all. Things are only what are manipulable and physically represented in the model world; directions are abstract concepts.
If you look at the Kind index, you’ll see the four kinds of objects are things, rooms, directions, and regions. Each of these kinds is mutually exclusive with the others.