Hi guys,

I am trying to figure out a way to disable a command pattern after one use. I came up with some dirty ways to do it, but they all caused bugs elsewhere in the game that were directly related to what I did trying to disable the commands.

So is there a much easier and cleaner way to disable a command? I want the code for disabling it to be at the end of the script that is activated when the command is first used.

Therefore, the command works the first time, but when the player tries to use the command again, the game does not respond to the command - especially without an error. If a message could be displayed when the player tries to use it more than once, that would be even better than nothing happening at all.

To be more specific, I want to implement a skip command. So that the player can skip large dialogue, scene, or story setups if they choose to. This would move them to a specific room, but I don't want them to be able to use the command again, because it would return them to that room - probably breaking the game in the process.

Look at this script:

Command pattern: xyzzy
Name: xyzzy

First time:
print "xyzzy works!"
Otherwise:
print "xyzzy fails."

Damn, that was so simple. I don't know how I couldn't find that script in the list. Thanks!

If you're doing this for WAKE: EtE, you'll have to note that you can't type while a conversation is going on, so maybe a y/n question that allows skipping.

this wiki page is very useful:

A-S = http://quest5.net/wiki/Category:All_Fun ... t_Commands
S-Z = http://quest5.net/w/index.php?title=Cat ... e#mw-pages

look under the F section, do you see the Firsttime link ???

and here it is:

http://quest5.net/wiki/Firsttime

enjoy

Just to show there are other ways of handling things in Quest, another way of accomplishing this would be using a variable or a flag to keep track of whether the player had already used the skip command or not. You could either set a variable like:

player.hasskipped = 0

Or use a boolean value like:

player.hasskipped = False

In the case of the variable I would have it set to 0 if the player hadn't used it, and to 1 if they had. With the boolean value, well,l I think that probably speaks for itself. As for the script itself, you would implement it thusly (using boolean as an example):

if (player.hasskipped) {
  msg ("That command has already been used.")
}
else {
  // code for skipping
  player.hasskipped = True
}

One thing I want to point out about the above example is the line "if (player.hasskipped) {". That's sort of a short-hand way of saying "if (player.hasskipped = True)." When you're testing for whether a value is true, you can leave the "= True" bit off the end. It saves a bit of typing. There's also a short way for testing whether a value is false, but I can't remember how it's done in Quest off the top of my head so I won't make an attempt in case I make a mistake and embarrass myself.

Technically speaking, I believe this is what the "first time" script does behind the scenes, but I just wanted to bring this up to help give a better understanding of how to wrap your head around problems like these.

cool !!! thank you sgreig! I didn't know that (I was about to ask too, "doesn't it need the, = true, at the end", before I had read further on, lol). So quest knows that (object.boolean)'s default is ( = ) true.

HK loves anything that shortens the time down (though getting~having too many of such short-cut methods can also cause me overwhelmingness and thus difficulty in remembering all of them or confusion too, lol).

---------

I think wouldn't it be:

if (not object.boolean) {

otherwise, you'd need to write it out (as I don't think, as far as I know, there's any other way of saying a negative* with quest):

if (object.boolean = false) {

*you also pointed out that "<>" can be used as not equal, but this type of negative doesn't work~apply for this situation, lol.**

**well... maybe you could do (lol):

if (object.boolean <> true) {

or, if the "not" works (lol):

if (not object.boolean <> false) {

this is very amusing to me, laughs. having fun with all the combinations of positives, negatives, double negatives, and etc.

wait... how smart is quest (so, Alex...), can it handle these? lololol (just joking around).

--------------

also, I never thought of using an int attribute instead, using the computer byte system of ZERO (0) and ONE (1), hehe.

would it be a string attribute or an integer attribute, btw ???

actually... this is could be used as like a switch too:

switch (object.string_attribute) {
  case ("0") {
    xyz
  }
  case ("1") {
    xyz
  }
  case ("2") {
    xyz
  }
}

~or~

switch (object.integer_attribute) {
  case ("0") {
    xyz
  }
  case ("1") {
    xyz
  }
  case ("2") {
    xyz
  }
}

and...

would this be able to work... or would you have to use a string~integer return function to retrieve the object.string~integer_attribute ??? (this seems overcomplicated, so you probably wouldn't need a return function, as I'm likely over thinking again, lol).

As I'm learning more and more of coding... I'm finding myself starting to over think a lot of stuff now... ARGH !!! Doing more complicated coding than is needed...is this normal (but very annoying side effect) when people learn to code more, or is it just me?

Hehe... if you're just using the variable as a flag, then it doesn't really matter if you use an integer or a string. I tend to set it as an integer just out of habit, but it would work either way. You'd just have to remember the quotations marks if you were creating it as a string.

Technically, I would think "if (boolean.value <> True)" would be valid, but I don't know if the expression handler Quest uses would accept that or not. That's really what it would come down to.

Checking if a value is set to false very well could be "if (not boolean.value)" as that seems familiar to me. If that's not the syntax, it's something similar to that.

But yes you'll find little shortcuts like that exist is every programming language. In JavaScript for example, you could use:

if (this.item) {
  // do something
} else {
  // do something else
}

The syntax is even relatively similar. Speaking of which, if you want to get a better handle on programming, I would recommend a website called Codecademy. They have instructional tracks for JS, Python, HTML, CSS, Ruby, etc. You'll find that as you become more familiar with programming in general, the fundamental concepts are all the same, it's just the syntax that differs.

Awesome, thanks for the site, Sgrieg!