Ergh! This has happened to me in two games. I want to have a locked, closed door, for ambiance, but opening it is not something that will happen. Therefore, this is undesirable:
But none of this works…
Instead of unlocking the door:
say "There's no way to get the key."
Instead of unlocking the door with something: ...
Instead of opening it with the door: ...
Instead of opening the door with: ...
Instead of opening it with when the noun is the door: ...
What the heck is the syntax?
The problem arises due to the fact that the action ‘unlocking it with’ is defined, while the action ‘unlocking’ isn’t. You can solve it this way:
[code]The Living Room is a room. “It’s an ordinary living room. The front door is to the south.”
The front door is a door. It is scenery. The front door is south of the Living Room. The front door is locked.
Check unlocking the front door:
say “You’re not going that way.”;
rule succeeds.
Unlocking is an action applying to one thing and requiring light. Understand “unlock [something]” as unlocking.
Check unlocking:
say “There doesn’t seem to be a keyhole.”[/code]
Note, however, that this will prevent the “What do you want to unlock it with?” parser question from ever arising, even with doors that you do want the player to be able to unlock.
Hope this helps.
–JA
Here’s a slightly more complete example, which handles "unlock " in a more reasonable way:
[code]Check unlocking:
if the noun is locked:
say “You don’t seem to have the key.”;
otherwise:
say “[The noun] doesn’t appear to be locked.”;
rule succeeds.
The Kitchen is a room.
The kitchen door is north of the Living Room and south of the Kitchen. The kitchen door is a scenery door. The kitchen door is locked. The fish unlocks the kitchen door.
The player carries a fish.
Check unlocking the kitchen door:
if the player carries the fish:
try unlocking the kitchen door with the fish instead.[/code]
Thanks Jim! I’m actually not going to have any unlockable doors, but I’ll use the second code for good form. Who knows, I might change my mind later.
Incidentally, I got as far as to realize that “unlocking it with” is the verb. But is there really no way to refer to that verb out of the box? Something like, “Instead of unlocking it with when the first noun is…” I could swear I tried everything though and couldn’t find it.
Also, “scenery door” is recognized? Are there any advantages to “scenery door” over “door”? Does this mean I can also do things like “scenery container”?
Thanks!
On that note, I just noticed that whenever you say “unlock fish” or anything else, the default response is “What do you want to unlock it with?”. It might be nice to change that behavior in general to “That’s not something you can unlock” unless you code otherwise. Why is there even such a quality as “lockable” if it doesn’t provide a negative response to trying to lock/unlock anything that isn’t specified as lockable?
More of an opinion than a question.
“Instead of unlocking the front door with something: …” or the general case, “Instead of unlocking with: …”
“Scenery” is not a kind like “supporter” or “container” but a property like “lockable” or “female”. It does mainly two things: the object is automatically fixed in place, and is not listed in the room description. A door has these properties by default so making it scenery doesn’t actually do anything. If you have a container that shouldn’t be carried and shouldn’t have a paragraph of its own in the room description, it can be made scenery. (see chapter 3.8 in the manual.)
I do agree that the default behavior is kludgy, but the lockable property does provide a proper response:
[code]The wharf is a room. A key is carried by the player. A box is a locked, lockable container in the wharf. A fish is in the wharf.
Test me with “unlock box with key/unlock fish with key”.
[This produces:
unlock box with key
That doesn’t seem to fit the lock.
unlock fish with key
That doesn’t seem to be something you can unlock.][/code]
Fortunately the built-in Locksmith extension makes locking and unlocking things behave much smoother, so you might want to take a look at that.
Hm, the “instead of unlocking with” code doesn’t work for me, nor do my default responses seem to be the same as yours, Nitku.
Entirely clean project, all code:
[code]The onlyroom is a room.
The otherroom is a room.
The front door is a door. The front door is east of the onlyroom and west of the otherroom.
The fish is a thing in the onlyroom.
Instead of unlocking the front door with something:
Say “test”.
Instead of unlocking the front door with:
Say “test 2”.
Instead of unlocking with:
Say “test 3”.
Instead of unlocking:
say “test 4”
[/code]
I can work around my problem, I think, but it’s interesting that we’re getting different default responses.
Edited to say: Actually we’re not getting different responses. It’s the presence of the key that makes you get “That’s not something you can unlock” instead of “What do you want to unlock it with”.
Ditto with
After unlocking:
say "test 4" instead.
And “before”.
This is because you are trying commands in the form of “unlock door”, but the standard library does not have an unlocking action. It only has unlocking WITH action, that applies to two things. You will always have to use two nouns with it and it will always ask for the second noun if it’s missing, no matter what you do. If this bothers you the easy solution is
Include Locksmith by Emily Short.This will add an unlocking action that applies to only one thing and thus does not ask for the second one.
I wonder if there’s some hack with “rule for determining the second noun…” or the like.
Probably not. I will get the extension. Thanks Nitku!