a door with 2 keys?!

how can i have a door with tow keys? It seems that when i make two keys for a door it shows an error massage…

Do you mean a door that requires two keys to open it? or a door that only requires one key but there are two keys?

Can’t speak for the OP, but I’m interested in the second question.

A door that only needs one key but has two to open it:

A door has an object called backup key.

The Corridor is a room.
The Private Study is a room.
The red door is east of the Corridor and west of the Private Study. The red door is a door. the red door is lockable and locked. The description of the red door is "Leads from the upstairs corridor into the private study."

The Brass Key unlocks the red door. It is in the corridor.
The backup key of the door is the white key. It is in the corridor.

Instead of unlocking a door with the backup key of the noun:
	Now the noun is unlocked;
	say "You unlock the door using its spare key."

Instead of locking a door with the backup key of the noun:
	Now the noun is locked;
	say "You lock the door using its spare key."

Each door is given a property called backup key. Then when a person trys to unlock/lock the door with that key, it forces the door to do so.
You can even have a skeleton key using this code:

[code]A skeleton key is a kind of thing.
The Skull Key is a skeleton key.
Instead of unlocking a door with a skeleton key:
Now the noun is unlocked;
say “You unlock the door with a skeleton key.”

Instead of locking a door with a skeleton key:
Now the noun is locked;
say “You lock the door with a skeleton key.”[/code]

Thanks!

I’m hoping that the “matching key” business will be deprecated in a future I7 release – I don’t see why “unlocks” can’t relate one door or container to various things.

You could equally have one key related to many doors. To be fully general, it would have to be a many-many relationship.

However, I don’t think the library really needs to strive to be fully general. The solution above is six lines of code, and it works. You could also write an extension that replaces two rules (the “can’t lock/unlock without matching key” rules), using the existing lock-fitting relation, and that would work (in about ten lines of code).

Handling actions and replacing action rules are not supposed to be last-ditch maneuvers.

Im still trying to work out a door that needs two keys, but im sure ill get there ^^

Well, “the matching key” isn’t so bad, since the formulation suggests that there’s only one matching key, but to throw an error for “Alice’s key unlocks the front door. Bob’s key unlocks the front door” is highly unintuitive. Nor is the error all that helpful, since that code doesn’t look like it’s setting the same property twice.

The workaround, as you say, is pretty easy to do once you figure out what’s going on (assuming you don’t have any “after unlocking” rules or such). I think the problem isn’t that the library doesn’t cover the extra case, it’s that the natural readable code doesn’t work. But it’s not such a big deal, particularly if making “unlocks” many-many would add a lot of overhead.

I would also say that replacing action rules is a fairly advanced maneuver, if only because the Standard Rules are not easy to find without a walkthrough. I put in a request for the documentation to include a link to Appendix A, so hopefully that’ll change in the next build.

I figured that a door that needs two keys should have two locks, so I wrote this up. It’s pretty crude and wound up being longer than I expected, so I’ll spoiler it [EDIT: changed the quote tag to a code tag, which is what it was supposed to be]:

[spoiler][code]“two locks” by Matt Weiner

A lock is a kind of thing. A lock is usually scenery. A lock has a thing called the unlocker. A lock can be locked or unlocked. A lock is usually locked.

Instead of locking a lock with something:
If the noun is locked:
say “[The noun] is already locked.”;
otherwise if the second noun is not the unlocker of the noun:
say “[The second noun] doesn’t fit [the noun].”;
otherwise:
say “You lock [the noun].”;
now the noun is locked.

Instead of unlocking a lock with something:
If the noun is unlocked:
say “[The noun] is already unlocked.”;
otherwise if the second noun is not the unlocker of the noun:
say “[The second noun] doesn’t fit [the noun].”;
otherwise:
say “You unlock [the noun].”;
now the noun is unlocked.

Check opening a door:
if a locked lock is part of the door:
let snag be a random locked lock that is part of the door;
say “[The snag] still seems to be locked.”;
stop the action.

Front Hall is a room.
Corridor is a room.
A door called the front door is north of Front Hall and south of Corridor. The top lock is a lock. The top lock is part of the front door. The description of the front door is “It has a top lock and a bottom lock.” The bottom lock is a lock. The bottom lock is part of the front door.
The unlocker of the top lock is the brass key. The unlocker of the bottom lock is the silver key. The player carries the brass key. The player carries the silver key.
Closet is a room. A door called the closet door is north of corridor and south of closet. The closet door is lockable. The closet door is locked. A thing called the closet key is in Corridor. The closet key unlocks the closet door. [/code][/spoiler]

I just threw in the business with the closet so I could test that I hadn’t broken ordinary locking/unlocking behavior. The “check opening” rule is really fugly, since it only tells about one locked – it shouldn’t be too hard to come up with a list of all the locked locks, though making sure it handles is/are properly seemed annoying enough for me not to try. Also, attempts to unlock and lock the front door directly will give unhelpful results; presumably you’d want to catch those and disambiguate which lock you meant.

My tentative conclusion is that double locks are as annoying in IF as in real life. Though, I’m a novice coder, there are probably better ways.

I was working with a simmilar idea to that, so great minds think alike ^^