I am using easydoors extension in my project but having trouble preventing the player to unlock the door without a keycard with this code:
An easydoor called Strategy Meeting Room door is a lockable, locked easydoor in the Meeting Room.
It leads to Strategy Meeting Room.
Green keycard unlocks the Strategy Meeting Room door.
Green keycard is on the Wooden Table.
The keycard is on a table in the Meeting room (player does not carry the green keycard) but when I type unlock strategy door (this easydoor is in the meeting room) with green keycard the green keycard is picked up automatically it seems and the door is unlocked and the player now carries the green keycard without the player ever taking the green card.
This is the outcome after typing open the strategy door with the green keycard:
>unlock strategy room door with green keycard
(first taking Green Keycard)
You unlock Strategy Meeting Room door.
How do i make the player pick up the green keycard first before he is allowed to open the door, thus preventing him from automatically obtaining the green keycard?
I will add, implicit taking is generally considered a good thing nowadays. Needing to REMOVE KEYRING FROM SACK. REMOVE KEY FROM KEYRING. UNLOCK DOOR WITH KEY. OPEN DOOR. instead of simply opening the door was a common source of frustration when games had complex enough world models to require this, but not intelligent enough parsers to do it automatically for you.
Is there a reason you want the player to have to take the key separately?
I guess the issue, then, is that taking the key then opening the door takes enough time for the conversation to conclude, whereas the implicit take allows the player to exit too early since it all happens in one turn?
If that’s the case, rather than mess around making the parser less player-friendly and solving the problem non-diegeticly, maybe you could just make the key inaccessible until the conversation’s concluded? Like one participant in the conversation hands it over once they’re done talking, or you just block attempts to take it saying it’d be impolite to leave the room while people are talking to you?
Thanks, can you maybe give me an idea on how to achieve this?
What I currently have is:
An easydoor called Strategy Meeting Room door is a lockable, locked easydoor in the Meeting Room.
It leads to Strategy Meeting Room.
The matching key of the Strategy Meeting Room door is the green keycard.
The known-key of the Strategy Meeting Room door is the green keycard.
But get the following error with regards the known-key… line
If I take that line out the code compile but in game you get the following error:
>enter the unified command room
(Unified Command Room door)
*** Run-time problem P10: Since Unified Command Room door is not allowed the property "known-key", it is against the rules to try to use it.
It seems to be locked.
A bold headed man enters the meeting room.
>unlock the unified command room
(Unified Command Room door)
*** Run-time problem P10: Since Unified Command Room door is not allowed the property "known-key", it is against the rules to try to use it.
You need a key to unlock Unified Command Room door.
Any idea how I cna resolve this issue?
I am going to share a mind-blowing magic trick I recently learned.
You don’t need inform doors. You don’t need to deal with all the door weirdness. You can make your own doors, which allows you to control their behavior.
Here’s a little mock-up I wrote when I was playing with this:
A frontdoor is a kind of thing. An insidefrontdoor is a kind of frontdoor.
An outsidefrontdoor is a kind of frontdoor.
A frontdoor is always scenery.
Understand the command "knock" as something new. Understand "knock on [something]" as knocking on. Knocking on is an action applying to one thing.
Understand "knock [something]" as knocking on.
The House is a room. It is north of the Yard. "A comfortable house. The front door leads south to the yard."
Tom is a man in the House. The description is "Tom, who lives here.".
The housedoor is here. It is an insidefrontdoor.The description is "The front door leading into the yard.".
The printed name of housedoor is "front door."
Understand "front", "door" as frontdoor.
The Yard is a room. "A grassy yard. The front door leads north into the house.".
The yarddoor is here. It is an outsidefrontdoor. The description is "The front door leading into the house.".
The printed name of yarddoor is "front door.".
Instead of opening a frontdoor:
say "No need to open and close doors in this game. Just go in the direction of the door.".
Instead of closing a frontdoor:
say "No need to open and close doors in this game.".
Instead of entering a frontdoor:
say "Just go in the direction of the door.".
Does the player mean knocking on a frontdoor:
it is very likely.
Carry out knocking on something:
if the noun is an insidefrontdoor:
say "You don't need to knock on a door to leave.";
otherwise if the noun is the yarddoor:
say "You knock and Tom lets you in.";
move the player to the house.
Understand the command "out" as something new. Understand "out" as outing. Outing is an action applying to nothing.
Instead of exiting:
try outing instead.
Carry out outing:
if the location is the House:
try going south;
otherwise if the location is the Yard:
say "You're not inside!".
Something can be lockedup. Something is usually not lockedup.
Check going south from the House:
say "The door slams shut behind you and you remember that it's always locked from the outside. You'll need to knock if you want to go back in.";
now the housedoor is lockedup;
continue the action.
Check going north to the House:
if the housedoor is lockedup:
say "The door is locked.";
stop the action.
Understand the command "unlock" as something new. Understand "unlock [a frontdoor]" as unlocking. Unlocking is an action applying to one visible thing.
Instead of unlocking a frontdoor:
say "You don't have a key to it."
You can then add rules as you need. Hope this helps!
I don’t think there’s a “known-key” property in default Inform - is that part of one of the extensions you’re using? Regardless it seems like there’s an issue with using it to give properties given the run-time errors, but it’s hard to say more without seeing your (or the extension’s) code setting up the property.
(I will say, having a room named Strategy Meeting Room and a door named Strategy Meeting Room door feels like asking for trouble. You know you can just use simpler, distinct names in your code but change how they appear to the player using the printed name property, right?)
As for how I’d manage the stuff I mentioned above, it depends a lot on the specifics of how that conversation is set up. Probably the simplest way is to start the green keycard nowhere, or carried by another character, and then in whatever rule you’re using for the conversation, add a bit of dialogue saying the npc gives you the key, and then put it into the player’s inventory with “now the player carries the green keycard.”
(That’s what the Easydoors extension does, actually!)
What @DeusIrae said is probably your easiest solution. Create the keycard off-stage and then move it after your scene happens through various methods.
Say "The meeting drones on, 'Blah blah blah...and therefore this meeting is concluded! You may acquire your keycard from the table.'";
now the green keycard is on the wooden table.
You likely don’t want to mess too much globally with implicit taking, although you could also do something locally like:
can-take-key is a truth state that varies.
Before taking the green keycard:
if can-take-key is false:
say "Not yet, the meeting is still happening." instead.
[...]
say "The proctor says 'Now the meeting is concluded. You may take the keycard.'";
now can-take-key is true.
