Unlock/lock restrictions

This forum is the place to learn about and discuss ADRIFT 5. Feel free to mention any bugs you find here, but please also add these to the Bugs & Enhancements list.

Please also refer to the ADRIFT 5 Wiki for more information.
Post Reply
User avatar
Denk
Posts: 1001
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Unlock/lock restrictions

Post by Denk »

EDIT: Poll removed, not much interest. The discussion below is good though.

Hi, I would very much like to know what each of you think about this before I modify the Combined Library, so I have made this quick poll (3 days). You are very welcome to explain your choice if you have the time, but if you would at least vote, then I have an idea of what to do.

Keep in mind that the game-author always can ADD restrictions in overriding tasks if needed, but if there are too many restrictions, the author must modify the tasks in the library.

:Thanks:
Last edited by Denk on Tue Oct 05, 2021 5:10 pm, edited 1 time in total.
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
User avatar
P/o Prune
Site Admin
Posts: 4959
Joined: Mon Jun 24, 2002 9:18 am
Points: 168
Location: Denmark

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by P/o Prune »

I would like that the object to unlock the passage, whatever it is, should be in players possession. Meaning I don't care where it is as long as the player has free access to it.
If it's in players possession, it would be natural that the player automatically takes it out if s/he wants to unlock %object%
D-Day in progress 86Kb (Slowly drifting)
October 31st: 135Kb (My entry for the parser Comp 2022 :wink: )
User avatar
Denk
Posts: 1001
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by Denk »

P/o Prune wrote: Mon Oct 04, 2021 4:18 pmMeaning I don't care where it is as long as the player has free access to it.
I guess this also means that if the key is on a table or in the lock, that is also fine. I think this corresponds to the restriction "object must be visible". Of course, the author could have placed the key upon a high shelf that the player cannot reach or something. In that case the author would have to add extra restrictions either in the overriding task or in the library task, as the library cannot predict such situations.

We could of course add the restriction that "object must not be held by any character" (unless it is the player character). That is the only restriction I can come up with where the key would otherwise be inaccessible for certain.
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
User avatar
P/o Prune
Site Admin
Posts: 4959
Joined: Mon Jun 24, 2002 9:18 am
Points: 168
Location: Denmark

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by P/o Prune »

Denk wrote: Mon Oct 04, 2021 5:14 pm I guess this also means that if the key is on a table or in the lock, that is also fine. I think this corresponds to the restriction "object must be visible".
Not necessarily. But if I, as a player, is carrying the key to a lock in the inside pocket of my jacket and come across the lock that needs that key. To me >unlock door (or whatever) would be logically. It may be that the player doesn't know that s/he is carrying the key that opens that particular lock, but I would assume that s/he would try unlocking it with the key s/he has.
An example is: You are carrying a sword in a scabbard and meet a troll. The command >kill troll, or >kill troll with sword should be sufficient to get rid of the beast since you are already carrying a weapon, rather than expecting the player to first draw the sword from the scabbard.
Not exactly the unlock command idea, but it makes my point, I think.
D-Day in progress 86Kb (Slowly drifting)
October 31st: 135Kb (My entry for the parser Comp 2022 :wink: )
User avatar
Denk
Posts: 1001
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by Denk »

P/o Prune wrote: Mon Oct 04, 2021 5:41 pm
Denk wrote: Mon Oct 04, 2021 5:14 pm I guess this also means that if the key is on a table or in the lock, that is also fine. I think this corresponds to the restriction "object must be visible".
Not necessarily. But if I, as a player, is carrying the key to a lock in the inside pocket of my jacket and come across the lock that needs that key. To me >unlock door (or whatever) would be logically. It may be that the player doesn't know that s/he is carrying the key that opens that particular lock, but I would assume that s/he would try unlocking it with the key s/he has.
An example is: You are carrying a sword in a scabbard and meet a troll. The command >kill troll, or >kill troll with sword should be sufficient to get rid of the beast since you are already carrying a weapon, rather than expecting the player to first draw the sword from the scabbard.
Not exactly the unlock command idea, but it makes my point, I think.
Thanks for discussing this, as I need more info to understand your needs. It might seem simple to say that the key must be in the players possession but ADRIFT needs everything explained/defined. I get that if the player is carrying the key (either in a held object or worn object) then he could unlock the door. But if I require that the object is either in something held or worn, then you wouldn't be able to unlock a door if the key was in the lock. And you couldn't override the library task because you had that requirement.

So in that case you would have to modify the restrictions in the library task to make it work (or create a general task for a specific situation which should be avoided when possible).

To summarize, if you require that the object is either held or worn (perhaps inside another object) then you wouldn't be able to utilize the library tasks when the key is in the lock. What would you prefer?
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
ralphmerridew
Posts: 2626
Joined: Fri Dec 13, 2002 11:56 pm
Points: 10
Location: Missouri
Contact:

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by ralphmerridew »

I personally expect that unlocking a door requires key directly in hand. (Under Inform, if the key was visible but not in hand, it would try to autotake the key first, but I wouldn't require that.)

As for games that allow putting the key in the lock as a move on its own, ... actually, I'm having trouble remembering many such games. Zork II and Scroll Theif. The convention in IF is that putting the key into the lock before / removing the key after is the sort of incidental action the player and player character already understand, so it gets done implicitly.

For example, if the PC is Captain Cork, I wouldn't expect to POINT QUADCORDER AT ALGOLIAN. PUSH SCAN BUTTON. He knows how his quadcorder works. Just SCAN ALGOLIAN should be enough. (On the other hand, if the PC is a person who has never seen a quadcorder, then requiring separate steps would make sense.)

Make the common behavior the default. If an author has a game that would benefit from allowing / requiring a separate PUT KEY IN LOCK step, that game's LOCK / UNLOCK commands will probably require some extra customization. (For example, locks in doors have two sides. If you put the key in the lock, go though the door, then close the door, you won't be able to lock the door from that side.) So having the library handle such cases by default makes things more complicated for the people who don't need the feature, without helping the people who do need it very much.
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
Lazzah
Moderator
Posts: 2524
Joined: Thu Mar 31, 2011 5:54 am
Points: 100
Location: Clacton-on-Sea, Essex
Contact:

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by Lazzah »

In my view, unlocking a door should require the player to be actually holding the key. I think the completion message for unlocking a door should be: "You insert the key into the keyhole, unlock the door and then take the key out again.", or something along those lines. However, if the key is already in the lock then it should be "You unlock the door, taking the key out of the lock afterwards." and placing the key in the PC's inventory.

When unlocking then door with a key that is held, a check should be made that the key is not in any container, as ADRIFT regards any object that is in a container that is worn as being held as well.
Visit "Larry's ADRIFT Text Adventures" at http://LarrysAdriftTextAdventures.co.uk
User avatar
Denk
Posts: 1001
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by Denk »

ralphmerridew wrote: Tue Oct 05, 2021 1:08 am I personally expect that unlocking a door requires key directly in hand. (Under Inform, if the key was visible but not in hand, it would try to autotake the key first, but I wouldn't require that.)
I am not sure yet, but I think I will do both, actually (unless people object below). So the key must be held directly in hand but if it isn't in hand, the player will pick it up. If the player can't pick up the key, it makes sense that he cannot unlock the door.

Something like:
>unlock door
(First taking the iron key from your pocket)
You unlock the door with the iron key.

ralphmerridew wrote: Tue Oct 05, 2021 1:08 am Make the common behavior the default.
The very special situation with a key in the lock will be less elegant if the task automatically takes the key from the lock before unlocking but in this special case the author can just text-override the message "(First taking the key from the lock)" and also make a specific task if the key should stay in the lock after unlocking.

So this is certainly a likely choice:
Require that the key is directly held but if the key is not directly held, the player will pick up the key first. If it can't be picked up for some reason, then the door cannot be unlocked. But if I bump into some big technical hurdles I might have to rethink this option.
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
User avatar
Denk
Posts: 1001
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by Denk »

Lazzah wrote: Tue Oct 05, 2021 9:11 am In my view, unlocking a door should require the player to be actually holding the key.
Combined with your requirement below that the key should not be in a container, I understand that you require that the key is held in hand, which is the same as ralphmerridew proposed. But if we apply such restrictions, then it won't work if the key is in the lock as you mentioned you would like below.
Lazzah wrote: Tue Oct 05, 2021 9:11 am I think the completion message for unlocking a door should be: "You insert the key into the keyhole, unlock the door and then take the key out again.", or something along those lines. However, if the key is already in the lock then it should be "You unlock the door, taking the key out of the lock afterwards." and placing the key in the PC's inventory.
I agree, but I don't think the library by default should be able to handle keyholes. That must be up to the author to implement. Otherwise we would have to define keyholes in the library which I think would be overkill for something that is rarely used. But if we apply the restriction that the object must be held, it will be harder for the author to implement a keyhole than if we only have the requirement that the object must be seen. In the latter case (but not the former) the general task can be overridden with a specific task when the key is in the lock.

Lazzah wrote: Tue Oct 05, 2021 9:11 am When unlocking then door with a key that is held, a check should be made that the key is not in any container, as ADRIFT regards any object that is in a container that is worn as being held as well.
I think you are mixing something up here:

If an object is inside a held container, ADRIFT regards the object as held
BUT
If an object is inside a worn container, ADRIFT does NOT regard the object as held

I wasn't completely sure I remembered this correctly, so I made a small demo to test it:
HeldRestriction.taf
(43.24 KiB) Downloaded 6 times
TRANSCRIPT:

Code: Select all

> i
You are wearing nothing, and are carrying a bag.  Inside the bag is a ball.

> test ball
Currently, ADRIFT regards the object as HELD.

> wear bag
Ok, you put on the bag.

> test ball
ADRIFT says the object is NOT held.
In any case, your proposed restriction will ensure that the key is directly held and not in a container.
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
User avatar
Denk
Posts: 1001
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by Denk »

Sorry, the post above had several confusing typos - now fixed.
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
User avatar
Lazzah
Moderator
Posts: 2524
Joined: Thu Mar 31, 2011 5:54 am
Points: 100
Location: Clacton-on-Sea, Essex
Contact:

Re: Unlock/lock restrictions - mini-poll [Combined Library]

Post by Lazzah »

Denk wrote: Tue Oct 05, 2021 11:28 am I think you are mixing something up here:

If an object is inside a held container, ADRIFT regards the object as held
BUT
If an object is inside a worn container, ADRIFT does NOT regard the object as held
Sorry, getting confused in my old age! :?
Visit "Larry's ADRIFT Text Adventures" at http://LarrysAdriftTextAdventures.co.uk
User avatar
Denk
Posts: 1001
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock/lock restrictions

Post by Denk »

I have tried to meet everyone's expectation in the attached demo below.
[NB: I have removed the poll as there wasn't much interest]

If you type UNLOCK DOOR WITH KEY then the player character will take the key if possible and then unlock the door.

However, I realised that there is a big difference between UNLOCK DOOR and e.g. UNLOCK DOOR WITH IRON KEY because the latter command shows that the player knows which key fits the door, or at least think they know. If the player only types UNLOCK DOOR then he might not be aware what the key is. Thus, an automatic task taking the right key might reveal the key and therefore it might spoil a puzzle. So UNLOCK DOOR only works if the key is held in hand, whereas e.g. UNLOCK DOOR WITH IRON KEY will pick up the key if possible before unlocking.

The demo is here:
UnlockDemo(4_2_beta2).taf
(44.59 KiB) Downloaded 6 times
Comments are very welcome, so I know if you like this approach or not.
:Thanks:
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
Post Reply