Newbie questions are newbie questions, but I am actually kind of stumped by this.

So there's a locked door in this room, requires a key. Key's hidden, but if the player uses a certain item in their inventory, they can reveal it. In fact, this item is supposed to reveal lots of items like that. The only problem is, I don't want the player to be able to use it all the time, for reasons that make sense within the context of the story. Most specifically, in this opening setting, I want the player to try and use the door so that I can explain exactly why it is they have to use the item (tutorial levels, ftw?).

As it is, the item can be used right off the bat, revealing the keys and skipping large chunks of narration accidentally. So my question here is, is there a way to lock out a certain verb on an object until specific conditions are met, either by making it simply not there, or by causing it to show a prompt instead to the effect of "you cannot use that object just yet?"

to do what you want involves some work (possibly) in the code, and also with lists and~or dictionaries, which, as a new person to quest (and I presume also to coding), will probably be too much for you at this point, but if you're interested:

add the verb, when you want it to be available during game play (and remove it again when you don't want it available):

1. http://quest5.net/wiki/Category:All_Fun ... t_Commands (page 1, range: A-S)
2. http://quest5.net/w/index.php?title=Cat ... t#mw-pages (page 2, range: S-Z)
3. http://quest5.net/wiki/Using_Lists
4. http://quest5.net/wiki/Displayverbs
5. http://quest5.net/wiki/Inventoryverbs

---------

or, an easier method is to use a 'boolean attribute check', in your Verb's scripting:

'key' (Object) -> Attributes (Tab) -> Attributes -> Add ->

Object (Name ~ ID): key
Attribute Name: activated_flag_boolean
Attribute Type: boolean ( or also known as a 'flag' )
Attribute Value: false

Verb: use key

if (key.activated_flag_boolean = false) {
-> msg ("Sorry, you can't use the key yet to unlock things")
} else if (key.activated_flag_boolean = true) {
-> // 'unlock whatever Object' Scripts
}

some other scripting (some other Verb, a Turnscript, or a Timer, a Function, etc) in the game, where~when that will thus activate the key, via changing the Key's boolean attribute ' activated_flag_boolean ', from ' = false ', to ' = true ' :

// (optional) if .... {
-> key.activated_flag_boolean = true
// (optional) }

and to de-activate the key again:

// (optional) if .... {
-> key.activated_flag_boolean = false
// (optional) }

-----------

and, you'll need this stuff below too:

the two most powerful~useful Scripts (you can do like 90% of what you want with these two scripts):

1. run as script -> add a script -> scripts -> if [EXPRESSION] -> (see below)

2. run as script -> add a script -> variables -> set a variable or attribute -> (see below)

Object.Attribute = Value_or_Expression

in code (I'm lazy, so I'm doing it in code as it's quick and easy):

if (Object.Attribute = Value_or_Expression) {
-> // scripts
} else if ... {
-> // scripts
} else {
-> // scripts
}

for examples:

if (orc.dead_boolean = false) {
-> // fight scripts
} else if (orc.dead_boolean = true) {
-> msg ("The orc is already dead, silly.")
}

if (player.age_integer < 0) {
-> player.age_integer = 0
}
if (player.age_integer >= 0 and player.age_integer < 4) {
-> player.age_string = "baby"
} else if (player.age_integer >= 4 and player.age_integer < 13) {
-> player.age_string = "child"
} else if (player.age_integer >= 13 and player.age_integer < 20) {
-> player.age_string = "teen"
} else if (player.age_integer >= 20) {
-> player.age_string = "adult"
}

player.cash = player.cash + 50

player.cash = player.cash - 40

player.cash = player.cash * 3

player.cash = player.cash / 2

player.cash = player.cash + orc.cash

if (player.cash >= wooden_sword.cost) {
-> wooden_sword.parent = player
-> player.cash = player.cash - wooden_sword.cost
-> msg ("You bought (and taken) the wooden sword")
} else if (player.cash < wooden_sword.cost) {
-> msg ("Sorry, you don't have enough cash.")
}

weapon.offense_integer = 50
player.strength_integer = 100
orc.endurance_integer = 25
player.physical_damage_integer = weapon.offense_integer + weapon.offense_integer * (player.strength_integer - orc.endurance_integer) / 100
// player.physical_damage_integer = 50 + 50 * (100 - 25) / 100
// 50 + 50 * (3/4)
// 50 + (25 * 3) / 2
// 50 + (75 / 2)
// player.physical_damage_integer = ~ 90

If you're using "use item" as your command, then HK's response should suffice as a start.

If instead you're using "use item on blah" to specialize it for each object, then you can do something similar (by putting an "active" check in each object handling script) or there are ways to hook into the command earlier to put in a common up-front check, which I won't get into unless you really need it, as it would probably just confuse things.

TheMaestro, I'd like to offer some additional thoughts which take a different tack on your question. You can take these or leave these. I'm just going to throw them out in case you hadn't considered them. Consider this all my opinion - but as I'm outside you head, perhaps it can offer a different perspective.

One of the biggest "immersion losses" I find in IF games is arbitrarily bizarre behavior put in by the game author which doesn't fit the "reality" of the game world but is put there to artificially force the player along certain paths. Looked at from the author's point of view, it makes sense. From the player's point of view, it's just odd.

As an example, let's say I have an apple in my inventory. (I don't know why I always use apples in my examples.) A natural thing would be to eat the apple. Now, if I type, "eat apple" and the game responds, "You can't eat that right now," as the player I'd be mystified. The reality of an apple is that it can be eaten. The choice by the game author to prevent me from eating the apple just then might work for what he/she wants, but it makes no sense to me as the player and only serves to reinforce that I'm not in a different world with logical rules but in a false reality with capricious behaviors. In other words, I can't use logic to work out the game since the responses are based on ulterior motives, not on the reality as I perceive it.

In a game I've been designing (and working on forever and getting nowhere), your character can sense the emotions of others. At some point, you will be made aware of this. It's part of the immersion process for the player, to gradually gain knowledge of the game world. Now let's say someone replays the game. They know about this "sense" ability. Does it make sense to prevent them from using it before they are told about it? Not in a logical world, no. If the ability is meant to exist as a physical reality in this world, then it exists, period. So I decided that I would not prevent a player from using it if they knew about it. In other words, I would chart out my initial path for the player, but if they had prior knowledge, well, I wasn't going to tell them that something they know exists doesn't - yet.

Another example: I have played games where the author wants people to discover items via a specific process of looking at things. There might be a desk, and then when you look at the desk you see a key on the desk. Then you can take the key and exit the room. When I played the game a second time, I right away typed "take key", and it said "You can't see a key." I had to actually look at the desk to enable the option to see and take the key - even though it was there all along! (In a game world reality sense.) That just seemed wrong to me. Perhaps you could not list the key in what's currently seen until someone looks at the desk. But to say it doesn't exist and then suddenly it does... irritating, arbitrary and needlessly constraining.

So what is my point? Let's say you were physically in this game world of yours, and you had this item in your hand. If you tried to use it before reading some text, would the heavens open up and a voice boom down saying, "Thou cannot use that yet!" That would be a very strange and unnatural occurrence. But that's basically what you're setting up in your scenario for your game.

What is the solution? For something like the apple case I mentioned before, you could keep the blocking behavior but have the text be something like, "You're not hungry yet." That at least has some logical reasoning behind it. You don't know when you will be hungry, but you figure you will be at some point, so all is ok.

In your case (and remember that I have no idea what the item is), I would recommend that the player not even be given the object until it makes sense to use it. Why should they have it if they can't use it? Perhaps put the item near where the text is. That would encourage people to read the text either before taking the item or shortly afterwards, as they would have a logical connection. And if they don't read the text? Well, that's their loss.

But (in my opinion!) the item should behave as the item behaves, without arbitrary, capricious, author-imposed sequencing strangeness that makes it inexplicitly not work at times that only make sense to the game author.

As I said up front, just some thoughts...

Actually, I think I get you perfectly. The idea I had was for the player to be able to detect hidden items through the use of his hat (it's that kind of game). Later on, this skill becomes vital to detect things that aren't as permanent as a set of keys on a night-stand, but at this juncture, I felt like it was important for the player to get a practical demonstration of how the item is supposed to be used since, otherwise, nobody would think that touching the brim of one's fashionable fedora could heighten the main character's sense of perception and detective skills. It was just filtered through a rather mundane puzzle, trying to find one's house keys before leaving for work.

I was just sort of worried about people clicking the textbox that says "hat," seeing the command to "touch the brim" and suddenly revealing a set of keys before they've even done any sort of walking around and figuring out that they have to be finding things, let alone that these things require the assistance of a magical old-fashioned hat. Of course, like you say, that does sort of negate the possibility that somebody playing the sequence over again knows all about the hat's powers and probably just wants to move on through the semi-tutorial.

In any case, it'd probably be easiest to just set the hat out of the immediate reach rather than use a web of flags to hide its use from the player. I really appreciate your candidness, Jay. I'll admit that perhaps I was a bit too hasty on the programming lingo. Thanks.

If you'd be satisfied with just hiding the verb from the hat's menu, then there should be some way to do that. For example, if you click on the hat object in the editor and go to the Object tab, there is a checkbox there that lets you disable the automatically generated verb list. That means your "touch brim" verb won't show up in the verb menu. That sets an attribute on the hat object named "usestandardverblist". The later, when they have gone through what you wish them to go through, you can set usestandardverblist = false, and the "touch brim" verb will show up in the menu.

Of course, if you have other custom verbs, they will come and go as well. If that's the case, then you could leave usestandardverblist permanently true and modify the hat's "inventoryverbs" list on the fly to add and remove as desired. (That was the direction HK was pointing you.)

The player would still be able to type the "touch brim" command (however it is set up, if they can) if they know it, but you wouldn't need to come up with code to provide alternate behavior.

That's interesting. I also have an object that you have to discover for it to appear. I didn't think of second play throughs!

(I glean a lot of info by reading old threads whilst bored...)