Unlock and 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: 1024
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Unlock and lock restrictions

Post by Denk »

Since the beginning of ADRIFT 5, there have been a sort of bug in the Standard Library which still is present in the Combined Library v.4.1.

The problem is that a command like "unlock door" has different restrictions than "unlock door with key". Currently, if you are "lazy" and just type "unlock door" you must be holding the key. But if you instead type "unlock door with key" it is sufficient that you can see the key.

Apparently, the easiest thing would be to add the restriction "Player must be holding the object(key)" to the "unlock objects with object"-task. Alternatively, we could remove that restriction from all unlock/lock-tasks and simply require that the key is visible.

However, it should be perfectly fine if the author has decided to place the key in e.g. the keyhole. If that is the case, it should be possible to unlock the door without taking the key first. If this is what the author wants, adding the tighter restriction above would mean that the "unlock door with key"-task would only run (or be overridden) if the player is holding the key. So ironically, the player would have to take the key from the keyhole before unlocking the door.

So perhaps it is better to have looser restrictions. Then the author can choose to override the default response with tighter restrictions.

One more detail the authors should be aware of: If the key is inside an object you are holding, ADRIFT regards the key as held, but if you are wearing that object, the key is not regarded as held. Still, what is most important is, that all unlock and lock tasks agree on what is required.

I would like to hear your thoughts about this, before I apply changes to the Combined Library.
:Thanks:
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
User avatar
Lazzah
Moderator
Posts: 2526
Joined: Thu Mar 31, 2011 5:54 am
Points: 100
Location: Clacton-on-Sea, Essex
Contact:

Re: Unlock and lock restrictions

Post by Lazzah »

If the key is inside a container that is worn by the PC, ADRIFT still regards the key as being held. I do not think this is right and it should have been fixed ages ago.
Visit "Larry's ADRIFT Text Adventures" at http://LarrysAdriftTextAdventures.co.uk
User avatar
P/o Prune
Site Admin
Posts: 4978
Joined: Mon Jun 24, 2002 9:18 am
Points: 168
Location: Denmark

Re: Unlock and lock restrictions

Post by P/o Prune »

Go ahead Denk. It's a good idea. Seems crazy to me that the player should take the key from the keyhole only to have to virtually put it back in before being able to lock the door. If the key is inside a pocket of a piece of clothing the player is wearing, it should be considered available to the player for use.
How would you go about if the player is holding the key and unlocks a door? You would assume that there's a keyhole even if it's not mentioned in the description of the door? Would the player still be holding the key after having unlocked the %object% ?
D-Day in progress 86Kb (Slowly drifting)
October 31st: 135Kb (My entry for the parser Comp 2022 :wink: )
User avatar
Denk
Posts: 1024
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock and lock restrictions

Post by Denk »

Lazzah wrote: Sat Oct 02, 2021 2:40 pm If the key is inside a container that is worn by the PC, ADRIFT still regards the key as being held. I do not think this is right and it should have been fixed ages ago.
Just to be sure I understand you corrrectly, here you are referring to the task "unlock objects with key"? Because that task isn't checking if the key is held at all.

The restriction [Referenced Object 2][must][be held by][The Player Character] (which isn't used in the above mentioned task) regards the object as held if it is inside a held container but not if it is inside a worn container. I am not sure if you regard this as a bug? At least it is sometimes inconvenient.

That used to be a problem with the "Take Objects (Parent)"-task so if you wanted to take an object from an object you were carrying, you would have to type e.g. "Get ball from bag" because "Get ball" used to tell the player: "You are already carrying the ball." If you instead were wearing the bag, there wasn't a problem, "Get ball" would be sufficient.

Then in the Combined Library I fixed this by adding a property called TakeFix. So instead of the restriction [Referenced Objects][must not][be held by][The Player Character] I replaced it with the restriction: %objects%.Parent.Takefix.Sum=0 [equal to zero means that it is NOT directly held by the player.]

So now (in the Combined Library) it is sufficient to just type e.g. GET BALL also when you are carrying the container with the ball.

It is possible to apply the restriction %objects%.Parent.Takefix.Sum=1 (or similar) in all restrictions that check if you are holding the object. NB: If it is held DIRECTLY it is equal to 1. It is also equal to 1 if it is worn but you can apply a worn-restriction first if you don't want that.

But first we must ensure that we want this stricter requirement in all tasks? Or perhaps just in some?
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
User avatar
Denk
Posts: 1024
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock and lock restrictions

Post by Denk »

P/o Prune wrote: Sat Oct 02, 2021 3:42 pm Go ahead Denk. It's a good idea. Seems crazy to me that the player should take the key from the keyhole only to have to virtually put it back in before being able to lock the door. If the key is inside a pocket of a piece of clothing the player is wearing, it should be considered available to the player for use.
So if I translate your response to something practical, I guess you only want the restriction that the key must be visible? You can then always override the general tasks when you need stricter restrictions, such as the key must not be held by another character etc. Or could you propose a set of restrictions that should always be fulfilled?
P/o Prune wrote: Sat Oct 02, 2021 3:42 pm How would you go about if the player is holding the key and unlocks a door? You would assume that there's a keyhole even if it's not mentioned in the description of the door? Would the player still be holding the key after having unlocked the %object% ?
Many games do not implement a keyhole and if they do, it is rarely a container. So placing the key somewhere after unlocking a door can easily be done by the author either by overriding the unlock tasks or by using a "run after"-task.
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
User avatar
P/o Prune
Site Admin
Posts: 4978
Joined: Mon Jun 24, 2002 9:18 am
Points: 168
Location: Denmark

Re: Unlock and lock restrictions

Post by P/o Prune »

Denk wrote: Sat Oct 02, 2021 3:52 pm So if I translate your response to something practical, I guess you only want the restriction that the key must be visible? You can then always override the general tasks when you need stricter restrictions, such as the key must not be held by another character etc. Or could you propose a set of restrictions that should always be fulfilled?
But is the key visible if it is inside a pocket? I'll see what I can do about dreaming up a set of restrictions :|
Denk wrote: Sat Oct 02, 2021 3:52 pm Many games do not implement a keyhole and if they do, it is rarely a container. So placing the key somewhere after unlocking a door can easily be done by the author either by overriding the unlock tasks or by using a "run after"-task.
This is, of course up to the author. The thought came to me because the author could use the fact that the player doesn't keep the task, to create a little teaser if there, for instance, is another object that can be unlock with the same key.
In my latest game, the player has to retrieve a key and unlock a door. In this scenario the key will stay in the keyhole after the player has unlocked the door. This is no biggie in this case since the key isn't needed elsewhere, though.
D-Day in progress 86Kb (Slowly drifting)
October 31st: 135Kb (My entry for the parser Comp 2022 :wink: )
User avatar
Denk
Posts: 1024
Joined: Mon Feb 22, 2016 6:21 pm
Points: 346
Location: Hjørring, Denmark

Re: Unlock and lock restrictions

Post by Denk »

P/o Prune wrote: Sat Oct 02, 2021 4:02 pm But is the key visible if it is inside a pocket?
If the pocket is a container-object and it isn't closed, ADRIFT will regard objects in the pocket as visible.

P/o Prune wrote: Sat Oct 02, 2021 4:02 pm I'll see what I can do about dreaming up a set of restrictions :|
It would be great if you and others could propose restrictions so there will be less change-requests after I publish the next version (I will probably upload a beta-version first that everyone can check out).
----------------------------------------------------------------------
The Bash Saga:
1. The Dragon Diamond 2. The Way Home 3. Stone of Wisdom
----------------------------------------------------------------------
Post Reply