This is definitely possible. Section 15.5 of Writing with Inform (in the latest version, 6L02) gives you the syntax, at the very bottom (in the midst of a lot of stuff about real numbers, so it isn’t surprising that you didn’t find it!) You could use either “>=” or “is at least.”
Another thing is that I’m pretty sure Inform won’t understand “the player’s clearance”; it has to be “the clearance of the player.” And when you say “unlock the door,” assuming you mean to just set the door to be unlocked, you say “now the door is unlocked”; see section 8.11 about “now.” (If you want to have the player actually execute the action of unlocking the door with something, that would be “try unlocking the door with [whatever],” but that’s a different thing.)
And it’s only fair to the player to let them know that something interesting has happened, so we should print a message. And we should probably give them a special message over and above “That appears to be locked” when they try to open a door they don’t have enough clearance for. Thus:
[rant=mistaken, see below]Before opening a secure door:
if the clearance of the player is at least the security of the door:
say "Sensing that you are worthy to pass through it, the door unlocks itself for you.";
now the door is unlocked;
otherwise:
say "You don't have a high enough clearance to open this door." instead.[/rant]
The “instead” stops executing the “opening the door” action so the player doesn’t also get the usual “That appears to be locked” message.
That’s because I made a mistake when I should’ve really known better. When you’re acting on a door or something like that, you can’t say “the door”; Inform doesn’t know which door you mean. If the door in question is the thing you’re acting on, you say “the noun” (or “the second noun” if it’s an indirect object as in THROW ROCK AT DOOR). See §7.10. So we should have:
Before opening a secure door:
if the clearance of the player is at least the security of the noun:
say "Sensing that you are worthy to pass through it, the door unlocks itself for you.";
now the noun is unlocked;
otherwise:
say "You don't have a high enough clearance to open this door." instead.
Sorry! See if that works.
I think you could also do this with a temporary variable:
Before opening a secure door (called the portal):
if the clearance of the player is at least the security of the portal:
say "Sensing that you are worthy to pass through it, the door unlocks itself for you.";
now the portal is unlocked;
otherwise:
say "You don't have a high enough clearance to open this door." instead.
Okay, one more question. I’m trying to set each door to close and lock once you pass (they are secure, after all)
Every turn when a secure door was open:
now the noun is closed;
now the noun is locked;
if the player can see the noun:
say "The [noun] closes and locks with a beep."
Does nothing, but if I change the was to an is it get a compiler error because “south” (the direction I’m using for testing) is not allowed to have the open property.
So I’ve figured out that the noun is referencing whatever action I’m currently attempting, waiting applies to nothing so it does nothing, examine myself applies to me (another error since I can’t be open), but “the secure door” still isn’t specific enough to close that door. Unless I’m going to have to write an instance of this rule for every door I make?
Try “repeat with the door in question running through open secure doors…”
One other thing to note is that the possessing action will need rather odd report rules, because when the action gets to the report stage the actor has changed.
You might also want to tweak the behavior of that – as it stands (well, once fixed) I think it’ll close and lock the door the turn that the player types “OPEN DOOR,” which is going to be frustrating. The player actually will be able to get through the doors by typing “south” or whatever, as that opens the door and lets the player move in the same turn, but still, the doors probably shouldn’t be quite so hair-trigger.
Two ways I can think of to take care of this. One is to give every secure door a counter that gets set when they open, counts down every turn they’re open, and closes the door when the counter reaches zero. This would require a few different rules – one every turn one to decrease the counters and close the doors, one carry out opening rule to start the counter when a secure door gets opened, probably one carry out closing rule to make sure that the counter gets reset (and the door gets locked) when the door is closed.
Another way would be just to use a Carry out going rule to close and lock every open secure door. That would mean that the doors lock behind the player, and if they walk away from an open door, so they couldn’t just have secure doors open everywhere, but it would give them enough time to go through the door they’d opened. It depends on what your goals are and what you need in the game.
(I think you should be OK with the rule you’ve written for possessing, because your Carry Out rule prints the message about possessing before you change the player. Usually it’s taken to be a good idea to leave printing text to the Report or After rules but this seems like a case where it might be easier to print the text in the Carry Out rules. If you want to do it in a more Informish way, sometimes Instead rules are used when you need to tie the action and the text printed together.)
[code]A secure door has a number called the propped count.
Every turn when a secure door is open:
repeat with the seal running through open secure doors:
increment the propped count of the seal;
if the propped count of the seal is 3:
now the seal is closed;
now the seal is locked;
now the propped count of the seal is 0;
if the seal is visible:
say “[The seal] slides shut with a click.”
[/code]
Could you also do it by putting your automatic close logic in a rule with the preamble “After going through a secure door (called the portal):”? I think the door gone through is accessible to After rules in this way. Although this does leave the possibility that the player runs around opening all the secure doors without going through any of them, so you probably also want the timer behavior.
ChrisC: I think, if you open and close a secure door by itself, that won’t reset the propped count. So the next time you open it it’ll slam shut too soon.
You could take care of that by setting the propped count of every closed secure door to 0 in your every turn rule but it seems a little less efficient to me.
After going through a secure door (called the seal):
now the seal is closed;
now the seal is locked;
now the propped count of the seal is 0;
say "[The seal] slides shut with a click.".
So it’ll close and reset after three turns or when they pass through.
Edit:
After taking in Matt’s concern with closing, I’ve created the phrase To seal (portal - secure door), which closes, locks, and resets the propped count of the sealed exit. So now instead of closing the secure doors, it seals them. it also reduces redundant code between waiting for the doors to close and passing through them.
An excellent synthesis of suggestions. Especially, well done abstracting the important logic into a separate phrase, in case you find you want to call it in other situations as well.
Actually, one of the trickier things you can do with the logic abstracted into a stand-alone phrase is to give one particular door different automatic-closing behavior; it could print a different message, or additionally make changes elsewhere in the complex.
The trapped door is east of the dungeons and west of the oubliette.
To seal (portal - the trapped door) begin;
now the trapped door is closed;
now the trapped door is locked;
now the security clearance of the trapped door is 9000; [higher than any clearance the player could have, so the door will not open automatically again]
say "The door slams shut and locks firmly with a sinister click. You don't think it will open again so easily.";
end.
And this code will blend right in with whatever “To seal (the portal - a door)” code you already have. It works better if secure doors also have a “willingness to stay open” which affects the delay before they close automatically; the trapped door should have an extremely high willingness to stay open, until some poor sucker steps through it.