Quest (v5.3) has a nice player-friendly feature where if you examine xyz, all objects begining with those letters are displayed in a menu for the player to select.

But, is there any way of disabling this feature?

It tends to provide players with a kind of cheat for some puzzles which depend upon working out what is there to be examined by using lateral thinking, or finding a clue in the adventure.

I've got around it a couple of ways in the past, but they're not very satisfactory:

E.g. if the secret scenery object is a "mirror"...

1. not making "mirror" a scenery object at all, but making "examine mirror" and "x mirror" commands in themselves [not great because player cannot shorten words...unless a very large number of commands are entered covering every possible combination of shortened forms]

2. making additional scenery objects called "m", "mi", "mir", "mirr", mirro" which provide the description "You can't see that here". [That worked pretty well, but obviously is easier to do for short words!]

Cheers!

I do not understand that. If you have to use an object from which you can not find a hint in the game, then it's bad game design. And when the player takes the trouble to try all combinations of examine, it's admirable that he struggles with such a bad game. I would stop playing such a game immediately.

But if you really want to do something like that you could create an object with lots of aliases like a,b,c,d,e... and move it to the room the player is in.

Pertex wrote:I do not understand that. If you have to use an object from which you can not find a hint in the game, then it's bad game design. And when the player takes the trouble to try all combinations of examine, it's admirable that he struggles with such a bad game. I would stop playing such a game immediately.

But if you really want to do something like that you could create an object with lots of aliases like a,b,c,d,e... and move it to the room the player is in.

Hi pertex,

That's a good idea. Thank you.

But I agree with your first sentence that you might not have understood exactly the situation I was talking about.

I simply want players to avoid accidentally stumbling upon certain objects which they should have to use some wit and imagination (or indeed hints in the game) to think of - in the context of a puzzly type of game.

I don't know what you were alluding to when you talked about "trying all combinations". I was talking about the ability to produce a list of all examinable objects by using a single letter. I don't think that allowing players to find everything in a room by typing:

x a
x b
x c
etc

...is necessarily good game design - though it depends upon the style of game. In my case, it's sometimes good if the player actually knows what he's trying to examine, rather than just saying "Now I shall see what this room contains that begins with B..."

I said myself that option #1 is NOT very satisfactory because it requires players to hit on precise combinations.

Thanks.

EDIT: Option #1 is not satisfactory because it requires players to hit on precise combinations

Pertex wrote:I do not understand that. If you have to use an object from which you can not find a hint in the game...

I think it's more for if you examine one object more closely, it brings to the player's attention a second object etc. The room description mentions a painting, the painting description describes the hook it is hanging on, and the description of the hook contains some indication of what you can/need to do to solve the puzzle.

Having said that, I can't see players just walking into a room and trying to examine random letters on the off chance that they'll come across a "secret" item. You'd be better off making the object invisible to start with, and then triggering it to become visible when the player has done something correctly, e.g. look at a certain object.

There is a built in function within Quest called Compare names which you could also modify if you want to change the way object names are matched. You could do something where if the input is not of a certain length, it won't match it to an object. Something like:

if (StartsWith(name, value)) {
  if (LengthOf(value) / LengthOf(name) >= 0.34) {
    if (not ListContains(partialmatches, obj)) {
      list add (partialmatches, obj)
    }
  }
}

(The second "if" statement is the addition to the default code)

In this case, the length of any input has to be greater than just over a third of the number of characters in the full name. So if the object was "mirror" it would match "mirro", "mirr", and "mir", but not "mi" or "m".

To expound...

You see there's a nice kind of puzzle where an object exists and can be examined, but the player might not think of doing so until he has received some hints or given it a lot of thought. They might miss out on the challenge of the puzzle if they accidentally find the object by simply trying to examine something else and end up with a menu containing that mysterious object

I'll try a final example:

"You're in a room with silk curtains [and more description but a secret object not explicitly mentioned]"

Examine s

Which S do you want to examine:
1) silk curtains
2) secret object [[which you were supposed to only think of examining after you found a hint or solved some kind of clue, etc]]

Hope that explains that a desire to not have ALL objects pop up so easily is not necessarily bad game design.

Liam315 wrote:

"Pertex"

I do not understand that. If you have to use an object from which you can not find a hint in the game...

I think it's more for if you examine one object more closely, it brings to the player's attention a second object etc. The room description mentions a painting, the painting description describes the hook it is hanging on, and the description of the hook contains some indication of what you can/need to do to solve the puzzle.

Having said that, I can't see players just walking into a room and trying to examine random letters on the off chance that they'll come across a "secret" item. You'd be better off making the object invisible to start with, and then triggering it to become visible when the player has done something correctly, e.g. look at a certain object.

There is a built in function within Quest called Compare names which you could also modify if you want to change the way object names are matched. You could do something where if the input is not of a certain length, it won't match it to an object. Something like:

if (StartsWith(name, value)) {
  if (LengthOf(value) / LengthOf(name) >= 0.34) {
    if (not ListContains(partialmatches, obj)) {
      list add (partialmatches, obj)
    }
  }
}

(The second "if" statement is the addition to the default code)

In this case, the length of any input has to be greater than just over a third of the number of characters in the full name. So if the object was "mirror" it would match "mirro", "mirr", and "mir", but not "mi" or "m".

Liam,

Just cross-posted with you. I think my second post explains the issue more clearly. Making the object invisible until a certain point is an option and something I do use, but for some purposes it's not appropriate. I might not want an object to be impossible to find, and then suddenly easy to find. I might want it to be available to find, but not explicitly stated, and have a number of clues guide the player to it.

With regards to your point about players not using the single letter examine as a "cheat", you may be right that most don't do it, but it is done. The main problem I suppose is that it can happen by accident if there is something else in the room beginning with the same letter. The player only intends to examine the 'S'ilk, but suddenly discovers a 'S'ecret object, for example.

Liam315 wrote:

"Pertex"

I do not understand that. If you have to use an object from which you can not find a hint in the game...

I think it's more for if you examine one object more closely, it brings to the player's attention a second object etc. The room description mentions a painting, the painting description describes the hook it is hanging on, and the description of the hook contains some indication of what you can/need to do to solve the puzzle.

Having said that, I can't see players just walking into a room and trying to examine random letters on the off chance that they'll come across a "secret" item. You'd be better off making the object invisible to start with, and then triggering it to become visible when the player has done something correctly, e.g. look at a certain object.

There is a built in function within Quest called Compare names which you could also modify if you want to change the way object names are matched. You could do something where if the input is not of a certain length, it won't match it to an object. Something like:

if (StartsWith(name, value)) {
  if (LengthOf(value) / LengthOf(name) >= 0.34) {
    if (not ListContains(partialmatches, obj)) {
      list add (partialmatches, obj)
    }
  }
}

(The second "if" statement is the addition to the default code)

In this case, the length of any input has to be greater than just over a third of the number of characters in the full name. So if the object was "mirror" it would match "mirro", "mirr", and "mir", but not "mi" or "m".

Your solution using the Compare names function looks interesting. That you very much for that.

privateer wrote:Your solution using the Compare names function looks interesting. That you very much for that.

The code I wrote is just one of many possibilities utilizing that function. Above obviously affects all objects in the game, but you could create conditions for specific objects as well. For instance, putting the relevant "secret" objects into an object list and having two sets of matching criteria - The default settings for most objects, and a more specialized set of criteria for the objects on the list, or if there aren't that many, a set of criteria for each individual "secret" object.

I posted something a while ago in the code samples section of the forum that's a modification of this function, whereby whole word matches are given preference over matches that contain that word as part of a longer word (e.g. if the input is "farm" and there are two objects "farm" and "farmer", it will return the farm object because the whole word is matched). You could modify those criteria for the "secret" object list so that those never accept partial matches but only matches for a whole word within the name/alias or alt names.

I don't know what level your understanding of the finer points of Quest coding is, but if you need a hand I'd be happy to help you out with crafting specifics to achieve what you need.

Liam315 wrote:

"privateer"

Your solution using the Compare names function looks interesting. That you very much for that.

The code I wrote is just one of many possibilities utilizing that function. Above obviously affects all objects in the game, but you could create conditions for specific objects as well. For instance, putting the relevant "secret" objects into an object list and having two sets of matching criteria - The default settings for most objects, and a more specialized set of criteria for the objects on the list, or if there aren't that many, a set of criteria for each individual "secret" object.

I posted something a while ago in the code samples section of the forum that's a modification of this function, whereby whole word matches are given preference over matches that contain that word as part of a longer word (e.g. if the input is "farm" and there are two objects "farm" and "farmer", it will return the farm object because the whole word is matched). You could modify those criteria for the "secret" object list so that those never accept partial matches but only matches for a whole word within the name/alias or alt names.

I don't know what level your understanding of the finer points of Quest coding is, but if you need a hand I'd be happy to help you out with crafting specifics to achieve what you need.

Perfect, thank you very much! I'm a GUI jockey at the moment, so I may well take you up on that offer in the future. For now I've just patched up the game with my imperfect option #2 since at least it prevents one of my most devilish puzzles being instantly exposed. (I was amazed to discover a player had found a certain secret object before accessing the part of the game with the hint. I put it down to exceptional lateral thinking, but now I think it was just a case of examining something else in the room that began with the same letter!)

Your solution is much more elegant. Cheers!

I don't know how you would do it, but I would assume there's a way to edit the core functionality of Quest to just remove the popup list altogether as well. Pertex or Jaynabonne or Alex would know better about that than I would though.

You can completely get rid of the disambiguation menu by editing the function ResolveNameInternal. You'd go to the last top-level if/else block and replace the "else" script (the one that calls all the GenerateMenuChoices functions) with a simple message saying something like "Multiple objects found, please be more specific." I'd probably advise against that though since I can see it being more frustrating for the player in a wider range of cases than it is helpful for the small set of situations you want to patch up.

Hi Liam et al,

RE your idea below:

Liam wrote,
"There is a built in function within Quest called Compare names which you could also modify if you want to change the way object names are matched. You could do something where if the input is not of a certain length, it won't match it to an object. Something like:

Code: Select allif (StartsWith(name, value)) {
if (LengthOf(value) / LengthOf(name) >= 0.34) {
if (not ListContains(partialmatches, obj)) {
list add (partialmatches, obj)
}
}
}"

I think something like that is the way forward for me. I tried Pertex's nice idea, but was surprised to find that it just adds the single-letter object to the list of objects in the disambiguation menu! The idea was good in theory in that Quest ought to recognise the letter as a complete object name and therefore not ask for disambiguation, but it seems Quest makes an exception for objects with single letter names.

So, I think my mission will be to implement your idea of having the game insist on longer input. Perhaps rather than insisting on a certain proportion of the total word, I could insist (as in the old days of Quill, etc) on a minimum of 4 letters for objects whose name is more than 4 letters long. Do you think that might be possible? For someone who rarely delves into the code view?

Many thanks!

Yep, anything you want is possible! You don't even need to use the code view, but using the page http://quest5.net/wiki/Category:All_Fun ... t_Commands in the wiki is extremely useful for finding functions to use in your expressions. The default options in the GUI dropdown menus can be somewhat limiting, but this list contains all the commands you will need to do just about anything using expressions.

To start with, I'll just explain how Quest goes about matching the input to an object:

There are 2 main default functions which I've mentioned already, ResolveNameInternal, and CompareNames. When Quest parses the player's input and decides on which word(s) is the object, it runs that part of the input through ResolveNameInternal. That function creates a list of every object in the current room, gets their aliases and alt names, and checks them one at a time against the input using CompareNames.

Compare Names

if (name = value) {
  if (not ListContains(fullmatches, obj)) {
    list add (fullmatches, obj)
  }
}
else {
  if (StartsWith(name, value)) {
    if (not ListContains(partialmatches, obj)) {
      list add (partialmatches, obj)
    }
  }
  else {
    // check if input matches the start of any word in the name
    if (Instr(name, " " + value) > 0) {
      if (not ListContains(partialmatches, obj)) {
        list add (partialmatches, obj)
      }
    }
  }
}

So if you look at the default code, the first part sees if the player's input (described as the variable "value") is an exact match for the name of the object (the variable described as "name"). Remember this function is run over for each individual name, alias, and alternate name that an object has, so the "name" variable can stand for any one of these. If it finds a match, the object is added to the fullmatches list which takes priority over any partial matches in the ResolveNameInternal function.

If it can't find an exact match, it moves on to the next part where you can see it checks if the object name (name) starts with the player's input (value), or if not, whether there are multiple words in the name that might start with the input. (Check the wiki for info on the StartsWith and Instr functions if you are not familiar with them.) The parts that say if (not ListContains(partialmatches, obj)) are there to make sure if one of the object's names is matched, it isn't added again if a second one of its names is also matched.

This second part is what you'll want to change and play around with to suit your needs if you're going to create a universal set of rules.

if (name = value) {
  if (not ListContains(fullmatches, obj)) {
    list add (fullmatches, obj)
  }
}
else {
  if (StartsWith(name, value)) {
    if (LengthOf(name) >= 4) {
      if ((LengthOf(value) >= 4)  and (not ListContains(partialmatches, obj))) {
        list add (partialmatches, obj)
      }
    }
    else {
      if (not ListContains(partialmatches, obj)) {
        list add (partialmatches, obj)
      }
    }
  }
  else {
    // check if input matches the start of any word in the name
    if (Instr(name, " " + value) > 0) {
      if (LengthOf(name) >= 4) {
        if ((LengthOf(value) >= 4)  and (not ListContains(partialmatches, obj))) {
          list add (partialmatches, obj)
        }
      }
      else {
        if (not ListContains(partialmatches, obj)) {
          list add (partialmatches, obj)
        }
      }
    }
  }
}

This is just an example of one way to do it, there are countless ways you could order the logic (including some that would probably be neater and more concise) but this example requires that all names with 4 letters or more be matched to inputs that are also 4 letters or more. Names with 3 letters or less are still matched to a value of any length, although you could require an exact match by using LengthOf(name) = LengthOf(value) in the statements governing those.

privateer wrote:
I think something like that is the way forward for me. I tried Pertex's nice idea, but was surprised to find that it just adds the single-letter object to the list of objects in the disambiguation menu! The idea was good in theory in that Quest ought to recognise the letter as a complete object name and therefore not ask for disambiguation, but it seems Quest makes an exception for objects with single letter names.

Hmm? Could you post your object which behaves in that way?

Hi Pertex,

Your idea actually works perfectly fine now. I had tested it before getting rid of the location-bound single-letter objects. When confronted by TWO similar single-letter objects, Quest displays ALL objects begining with that letter in the menu. But having deleted those it works as expected.

I think you would not object to the final effect. All that has changed now is that the player gets a prompt when attempting to identify an object with a single letter instead of a (sometimes quite long) list of objects, some of which were not intended to be put on obvious view.

Another example of why this implementation has been useful for me, aside from mysery object puzzles, is those objects which SHOULD be impossible to examine - like noises.

E.g.

The sky is full of stars. You hear someone singing. [singing has to be an object so you can interact with it: "listen to singing"]

Examine S [expecting to examine stars perhaps]

Which S?
1 Stars
2 Singing

So the awkwardness of being given "singing" as an examinable option, and then being told "You can't see that" (or something similarly logical) should you try.

So, all in all, your idea is a satisfactory solution. Thank you.