I'm writing up a "How To" guide on creating locked exits to be opened with keys, and I want to clarify a couple of things before I go making statements that aren't really true.

I see one of the main confusions with this issue to be that you cannot select an exit under the default "Use this on (other object)" feature. Since it seems like something a new user might try, and be confused by, I plan to mention this in my guide.

I don't see any work item for changing this in the issue tracker, so I'm assuming there are currently no plans to. I am also assuming that the reason exits don't appear in that list is that their "type" attribute is "exit" rather than "object."

I would greatly appreciate if someone could confirm that all of that is accurate. If the PTB would like this added to the issue tracker, I should probably know that, so I can mention that it might be updated. Also, any advice, suggestions, or other comments on the guide are quite welcome.

@Alex/mods: Should I always expect someone like you to add issues to the tracker, or would you prefer that some of us others had codeplex logins so you could just ask us to do it when things come up in the forums here?

Yep, yep, you're correct. Note that exits can be used in expressions, but it has not been tested.

You don't need to login to use the IT. Just a screen name. Althrough a password is recommended.

I don't know if it was added to a tracker or not, but Alex and I were discussing this just a few days ago and I believe he is implementing something where you can specify an associated object on the exit that would act as a "door" so to speak, which you could use items like keys on in order to unlock the exit.

I might have muddled up a couple of the details as it was 3 or 4 days ago when we were talking about it, so if Alex wants to chime in and clear anything up that would be awesome.

It's here in the issue tracker: http://quest.codeplex.com/workitem/1247

I did see that actually, but I guess I'm not clear on what exactly that is intended to do. Right now, all it says is:

If we can choose a linked object for an exit, then the exit can be made available if that object is open.
This would allow easier implementation of a locked door. The door can be a locked container using the current functionality, with a named key object. If the exit is linked to this door, then the exit only becomes available when the door is unlocked and open.

It sounds like one would still need to create a secondary object to affect the exit. As it is now, I can make a lockable container with an open script that makes an exit become visible (or unlocks it, or even creates one from scratch). So, if the purpose of this fix is to "streamline" that work-around and turn it into a standard feature, that sounds fine to me, but people would still need to know that they can't just "use key on EXITNAME" without accessing the exit via another object. To be clear, I'm sort of assuming there's a good reason why it works that way, so I'm not necessarily suggesting that it be made possible to affect exits in that direct of a way. It's just that since that's how most objects work ("use key on chest"), I want to make sure new users coming in know they can't do that with an exit.

Now, if by "linked" it means that the object would fully "represent" the exit, I can see how that would have other useful applications as well. For instance, homeeman was recently asking about the problem with "lookdir" for Alternative Aliases (if you change the exit's alias to anything other than a cardinal direction, neither "look" nor "look at" will work with it). If the linked object could be used to resolve that also, it would be even more useful, since there's not any simple way around that at all at the moment (or so it seems, from reading that topic).

Actually, I would like to see a new Locks tab in the exits, which have the options:

-HAND (Unlock door), requires door object, messages, is it lockable again and afterscripts.
-KEY (Unlock door with key) requires door object, key object, message, lockable again, and afterscripts.
-CODE (Type code) requires code, messages, afterscripts.
-VERB (#special verb# door) requires verb, door obj, msgs and afterscripts.

What would be the advantage of having to create yet another object (door) for each exit?

I dislike the idea of having HAND/KEY/CODE/VERB even more.

What if I want retinal scanner to open door? Or breath analyzer? You can't expect every possible option to be implemented for you -- some things you will have to code yourself, that flexibility is the power of Quest, not having preset choices.

Regarding exit aliases affecting "look" and "look at" it looks like a bug which also affects compass by disabling those exits on it even though they are still marked properly as directional. I reported it to Alex and I hope it will be fixed.

Finally, why not just add verb "unlock" so you can write unlock stone door (where stone door is alias for north) which calls a function that deals with checking if you have a key? What is preventing you to print a message "You open a stone door and head north while they close behind you with a loud noise." when exit is used? It is about making the player believe there are doors, not about actually physically implementing them. Same goes for many other things you might want to do.

I can't seem to make it work your way.

How would I go about doing that? I'm not sure where to add the verb, or how to direct it at the exit.

EDIT:Bad form, I apologise; that was very sarcastic of me.
What I meant was, the main point of this conversation is that you can't do that without changing the fundamentals of exits in Quest, OR if you have found a way to directly address exits with "unlock," I'd genuinely love to know how.

TriangleGames wrote:I can't seem to make it work your way.
Unlock door.png
How would I go about doing that? I'm not sure where to add the verb, or how to direct it at the exit.

EDIT:Bad form, I apologise; that was very sarcastic of me.
What I meant was, the main point of this conversation is that you can't do that without changing the fundamentals of exits in Quest, OR if you have found a way to directly address exits with "unlock," I'd genuinely love to know how.

Just a quick clarification, is "door" an exit alias in the above example? If it is, then you also can't "look" or "look at" it and you don't see it in the compass, right?

What I was saying is that there is a bug with that (at least I consider it an unintended behavior unless Alex can convince us otherwise). If the bug is fixed, then there is no need to add doors. That was my point.

If you can attach a small sample of what you need maybe I could try to figure a way to do that because I am interested in a solution as well.

levicki wrote: ...(A) is "door" an exit alias in the above example? ... (B) What I was saying is that there is a bug with that (at least I consider it an unintended behavior unless Alex can convince us otherwise). If the bug is fixed, then there is no need to add doors. That was my point. (C) If you can attach a small sample of what you need maybe I could try to figure a way to do that because I am interested in a solution as well.

A) yes, in that sample "door" was an exit alias
B) I don't know whether this behavior was "unintended" or not, but I don't think Alex has any current intention/plan to change it. I say this because he is in favor of the idea to create objects that are "linked" to the exit as a work-around. He is in fact the one who added the work item for it in the issue tracker (see quotes).

sgreig wrote:... Alex and I were discussing this ... he is implementing something where you can specify an associated object on the exit that would act as a "door" so to speak, which you could use items like keys on in order to unlock the exit.

Pertex wrote:It's here in the issue tracker: http://quest.codeplex.com/workitem/1247

It seems like it should be obvious that addressing exits directly would be simpler for these purposes, and Alex is usually fairly open to suggestions for changes (as well as constantly inventing his own improvements for Quest), so I assume he has a good reason for not doing it that way.

C)Currently, the easiest way to unlock an exit is to set a key to unlock the exit all by itself where the player types just "use key." I don't like that idea, because I feel it's too easy for players; they should have to say what they are using the key on. I want the player to type in something more like "unlock EXIT-NAME with key" or "use key on EXIT-NAME." Obviously, "unlock east with key" or "use key on east" wouldn't make any sense. So there are two options I have in mind:

1) Give the exit a unique alias, like "door." Make a scenery object (so players won't see it) with the same alias. Have the key set to be used on the scenery object with a script that unlocks the exit. This way, when players type "use key on door" it will look like they unlocked the exit directly. However, since the exit has the alias door, it won't be accessible via the compass.

2)Leave the exit as a direction, like "east." Make a normal object in the room called "door" which is described to players as blocking the east exit. Have the key set to be used on the door with a script that unlocks the exit. This way, when players type "use key on door" it will look like they unlocked the door itself (which they may have depending on how the door was set up, but the point is that it unlocked the exit). Now, since the exit is just "east," players can access it via the compass.

So, the challenge would be to develop ANY method by which players could type either "use key on exit" or "unlock exit with key" that does NOT involve using a tertiary object to "represent" the exit.

Doors would be optional, and if you could ask that question, levicki, I could do the same to Inform and TADS.

The point of Quest is to make coding easier.

To me, problem seems to be that if you type "unlock bathroom" because your exit has an alias "bathroom" the game will incorrectly set objtype to "object" instead of "exit" and pass that into ResolveNextName(). That will in turn call ResolveName() which will call ResolveNameInternal() and even though ResolveNameInternal() has the code for exit handling it won't be executed because it got the wrong objtype as a parameter which means exit won't be visible and you will get the famous "I can't see that. (bathroom)" message.

This is really a parsing bug in my opinion, and I am not sure it can be handled just by changing CoreParser.aslx.

levicki wrote:To me, problem seems to be that if you type "unlock bathroom" because your exit has an alias "bathroom" the game will incorrectly set objtype to "object" instead of "exit" and pass that into ResolveNextName(). That will in turn call ResolveName() which will call ResolveNameInternal() and even though ResolveNameInternal() has the code for exit handling it won't be executed because it got the wrong objtype as a parameter which means exit won't be visible and you will get the famous "I can't see that. (bathroom)" message.

This is really a parsing bug in my opinion, and I am not sure it can be handled just by changing CoreParser.aslx.

Okay... well if you understand how the bug works, then you might add a request to fix it in the issue tracker or the uservoice suggestions. I have no idea how simple-vs-complex fixing that might be, or where it would fall in Alex's priorities right now, but it could certainly be put on a "to-do" list. In the mean time though ... new users need to be told how to make a door unlock, so until it's changed/fixed, I'm gonna tell people to use a tertiary object. I mean, I'm not gonna try to explain all about why they have to in THAT kind of detail, because a new user whose not familiar with programming might not even understand all that. If it's fixed/changed later, the "how to" can always be changed along with it.

TriangleGames wrote:Okay... well if you understand how the bug works, then you might add a request to fix it in the issue tracker or the uservoice suggestions. I have no idea how simple-vs-complex fixing that might be, or where it would fall in Alex's priorities right now, but it could certainly be put on a "to-do" list. In the mean time though ... new users need to be told how to make a door unlock, so until it's changed/fixed, I'm gonna tell people to use a tertiary object. I mean, I'm not gonna try to explain all about why they have to in THAT kind of detail, because a new user whose not familiar with programming might not even understand all that. If it's fixed/changed later, the "how to" can always be changed along with it.

I do understand because I just tried to make that work and ended up adding Log() statements into CoreParser.aslx in order to see where exactly the problem lies. Just to be clear, I do not mind if you keep telling people to use tertiary object in the howto, I just mind if that becomes default way of doing it because it increases object count dramatically, cluttering the object list and slowing down game development.

As for the issue, I registered an account and I will submit it soon.

levicki wrote:I do understand because I just tried to make that work and ended up adding Log() statements into CoreParser.aslx in order to see where exactly the problem lies. Just to be clear, I do not mind if you keep telling people to use tertiary object in the howto, I just mind if that becomes default way of doing it because it increases object count dramatically, cluttering the object list and slowing down game development.

As for the issue, I registered an account and I will submit it soon.

Well, part of the reason I originally asked about why it works this way, is so I could mention it (in simple terms) in the guide. So, if there's ever so much as an official plan to change it, I would add that in. Although, I suppose my mentioning it is no guarantee of if/when it would happen. I'm not sure it would create as much clutter as you're picturing though, as it would only be necessary for locked or hidden exits, not all the exits. So, I guess it would depend on how many locked exits a person was planning to include.

TriangleGames wrote:Well, part of the reason I originally asked about why it works this way, is so I could mention it (in simple terms) in the guide. So, if there's ever so much as an official plan to change it, I would add that in. Although, I suppose my mentioning it is no guarantee of if/when it would happen. I'm not sure it would create as much clutter as you're picturing though, as it would only be necessary for locked or hidden exits, not all the exits. So, I guess it would depend on how many locked exits a person was planning to include.

Well, if in the future there is an option in editor which says [ ] Include door and is disabled by default and the open/close/lock/unlock which is handled automatically if doors are enabled, then I don't mind seeing such functionality. As a matter of fact I think that could probably be hacked in even now just by editing core libraries.

Anyway, I submitted an issue:
http://quest.codeplex.com/workitem/1252

Edit:
I did some further testing by removing all default "unlock" templates from Quest libraries, and this is definitely a problem with how Quest parses user input.

Namely, when I have:

- An object in the inventory called "bathroom_key" with an alias set to "Bathroom Key"
- A room with an alias "bathroom" and name "room2"
- An exit with an alias "bathroom" and name "exit_bathroom"
- A command "unlock" with a pattern "unlock #object#" which calls my function Unlock() with the parsed object as a parameter.

When I type "unlock bathroom" my function Unlock() receives object "bathroom_key" which is a partial match for "bathroom". It is understandable that room with an alias "bathroom" is not visible because it is behind the exit, but the exit itself should be visible, and the exit object should be returned before considering partial matches.

It seems that in order to enable such functionality the CoreParser.aslx and who knows what else would have to be rehauled. One of the options (maybe the simplest one) of the top of my head would be to change the default lock/unlock/open/close to work on exits too instead of only on containers visible to the player.