Hello!
I want to know if there is any way to remove the fact that you have to say "go" before a direction. If I write one word, I want to be able to to teleport to that place without saying GO before the word.

it's more work to not use 'go' (or whatever activator word for in your Command's Pattern for your Command), as you'd have to use the individual places~areas~locations (rooms) as your activator word, which means you need to create a Command for each such place~area~location (room) you want to go to...

(Maybe there's a really advanced way to do this, with using only a single Command), but that would be far beyond my knowledge and ability, lol)

well... here's how you'd make your individual Commands (again, I'd recommend just using the 'go' or whatever activator word, so you only need to make~use one single Command, but whatever):

'game' Game Object -> 'Commands' -> Add -> (see below, repeat as needed)

(this is just a basic~simple example, if you want more complex scripting: add new scripts, then let me know)

replace my 'xxx_#' with the names of your place~areas~locations (rooms)

Command Name: town_1_command
Command Pattern: town_1
Command Script: MoveObject (player,town_1)

Command Name: town_2_command
Command Pattern: town_2
Command Script: MoveObject (player,town_2)

Command Name: land_1_command
Command Pattern: land_1
Command Script: MoveObject (player,land_1)

Command Name: land_2_command
Command Pattern: land_2
Command Script: MoveObject (player,land_2)

Command Name: dungeon_1_command
Command Pattern: dungeon_1
Command Script: MoveObject (player,dungeon_1)

Command Name: dungeon_2_command
Command Pattern: dungeon_2
Command Script: MoveObject (player,dungeon_2)

etc etc etc

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

actually... maybe you don't even need the activator word (I haven't worked that fully with testing~studying Commands, lol).... which would then make it really easy to do a single Command:

(this is just a basic~simple example, if you want more complex scripting: add new scripts, then let me know. for example, you probably don't want to teleport inside of a locked chest Object, especially if you don't have a key for it, lol. Or, you don't want to be teleporting inside of a 'wall' Object or into a 'sun' Object ~ the dangers of teleportation~warp travel, lol, or onto the top~'surface' of a 'table' Object, lol)

Command Name: teleport_command
Command Pattern: #object#
Command Script: MoveObject (player, object.name)

I should test this, if it works, lol...

HegemonKhan wrote:...
actually... maybe you don't even need the activator word (I haven't worked that fully with testing~studying Commands, lol).... which would then make it really easy to do a single Command:

Command Name: teleport_command
Command Pattern: #object#
Command Script: MoveObject (player, object.name)

I should test this, if it works, lol...

Quest will only match #object# to objects that are present, so this will not work.

I would do it with a command for each room as you originally said.

Err (I keep forgetting that ~ why I like using #text# always, lol), then I should've said to use the #text# VARIABLE instead, and, thus, you're saying that Commands don't require an 'activator word' at the beginning of its Command Pattern, right? So if we just used the #text# (and adjusted scripting) instead, then the Command would work?

Command Name: teleport_command
Command Pattern: #text#
Command Scripting:

object_variable = ToString (GetObject (text))
MoveObject (player, object_variable.name)

will this work [ I'm not sure if I can do: ToString (GetObject(xxx)) ] ?

I have a bit of trouble using VARIABLE.Attribute_name, in getting it to work... if it can even be done, lol.

-------

or we could probably use #object#, but we'd just need additional scripting:

Command Name: teleport_command
Command Pattern: #object#
Command Scripting: (see below)

if (object = null) {
  foreach (obj, AllObjects ()) {
    if (obj.name = ToString (object)) {
      MoveObject (player, object.name)
    } else {
      if (obj.alias = ToString (object)) {
        MoveObject (player, object.name)
      }
    }
  }
} else {
  MoveObject (player, object.name)
}

right ???

Well it's simple. I want to make my game like a computer. In a room (or page for the computer) I use a command (one word) to do something that only work on that room (page) The more you advance in the game, the more words you can use to advance in the game.

I personally would not use #text# in such an open way (and as The Pixie said, you can't use #object#). All the player has to do is type "player" to move themselves to themselves, and that would make the known universe fold in on itself. Beyond that somewhat tongue-in-cheek thought, you don't want to have a "back door" in your game that allows the player to move to any object. It's just too dangerous.

You *could* use such a technique if you have some sort of validation. And the fact that you want the list of commands to grow over time would fold in nicely with having a string list of valid targets, which you append to as the list needs to grow. Then in the command, you'd see if the text is in the target list. If it is then, you would move. If not, you'd print out some sort of error. You'd have to have an error like "I don't understand that", since #text# will match everything under the sun that doesn't correspond to a valid command (e.g. if you type "n" when there is no exit, if you type "x" with no object, if you type "fizzbinn").

Which gets back to that I probably wouldn't use #text# in general as a command pattern! You're just going to cause yourself all sorts of grief.

Here's another thought about the "ever growing list of commands".

Commands can be global, or commands can be specific to a room. As it turns out (as I just explored), commands can have a parent just like other Quest objects. What that means is that you can keep your collection of commands in a hidden room, and then as each command becomes available, you can set its parent to null. That will move it into the global space, and it will be accessible to the player from then on. This allows the set of commands available to the player to grow over time.

Be aware that if you want to set the parent of a command in script, then you need to give the command a name. Otherwise, Quest will assign one, and you won't know what it is. If you have a sample command with name "samplecommand", then you can move it from a room to the global command space with

samplecommand.parent = null

oh definately... they'd need lots of checks~validations, but I didn't want to confuse them with that stuff.

and, I forgot to touch upon that design issue of game-wise command availability-checking, so thank you Jay for covering that issue.

-------

would any of my code stuff work in my previous posts ???
(as I'm having a bit of trouble with some similiar syntax~format designs, in trying to get them to work)

------

Pixie and Jay wrote:~ "you can use #object#"

couldn't you use the #object#, if you add in the additional scripting that I have (or similiar to if mine isn't quite fully correct) in my previous post?

here's the contents of my previous post:

Command Name: teleport_command
Command Pattern: #object#
Command Scripting: (see below)

if (object = null) {
  foreach (obj, AllObjects ()) {
    if (obj.name = ToString (object)) {
      MoveObject (player, object.name)
    } else {
      if (obj.alias = ToString (object)) {
        MoveObject (player, object.name)
      }
    }
  }
} else {
  MoveObject (player, object.name)
}

I left out the needed checking~validation of (type of) Objects, just to make it a quick posting, but am well-aware it (and any other types of checking~validation) is quite needed.

This sounds dumb probably, but...

You obviously have to have some command before you use the teleporter, yes? So... The player enters the teleporter... The player types 'use teleporter... The player enters a room... Can't you just set the previous command to a switch script?

If you want a totally open environment to jump to room to room... Say you want to jump from home to grocery store by simply typing grocery store, I'd still use a letter, like 'T', to open up a numbered menu with rooms that can be teleported to.

'T', show menu, 1. Home, 2. Grocery, 3. Library, 4. Bar, 5. Etc...

Could you make a universal game command to open a menu like that? Then you could simplify transport to two buttons: 'T', '2'

#object# only matches an object. You will *never* see "object" equalling null in the command, because if there is no object to match, then the command will not fire. It simply will not match. #object# is not a catch-call - it means "there must be an object in view with that name/alias to match".

As far as your code working, the only one I'd go with (and The Pixie has already said this as well) is the multiple commands one. While the #text# command would work to a point, it would be unusable in a game as is due to numerous problems (false matches, etc), and so I don't think I'd say it would "work" as far as being a real solution.

they'd need lots of checks~validations, but I didn't want to confuse them with that stuff.

Then they'll just be confused down the road when all the problems show up. It's an interesting approach, and I have experimented with something similar myself, but it's not workable (in my opinion) even with the validation. It would be easier just to create commands.

ah... laughs... thanks Jay, I get it now:

if you only got:

Command Pattern: #object#

the command will never fire... I wasn't thinking about this... too used to having~using:

Command Pattern: activator_word #text~object#

where then you can have: if (object = null), as the command will still fire due to the rest of the Command Pattern syntax (the 'activator word' as I call it wrongly, lol)

----------

and thanks for all the advice about best practice in code designs~methods, as I'm still a total noob with it.

I like the #text# because I understand how to put all the checks~validations in for it (as I had problems using #object# as I didn't understood how it works until now, thanks to your posts just now hehe... if only I can remember now... actually... I better bookmark~favorite your posts, as I don't trust my memory for good reason, lol), though indeed it is quite cumbersome and confusing~complicated to get it fully working correctly, especially as your game grows and etc.

It will fire - if there is an object that matches what you type. If you have an apple in the room, and you type "apple", then it will fire. But if the apple is in another room or a global object, it won't.

And no, the activator word won't work with #object# either. But it will with #text#.

I'll say again: if you have #object# in your pattern. it will NEVER be null in the script. The command will only ever execute if it has matched an actual present object. Otherwise, Quest will have already said something like "I can't see that" since it couldn't resolve the object. That's true even if you have an "activator" word.

ah okay, so, due to the #object# itself in how it works, it just won't work no matter what, if the person's input isn't an actual Object within the same room~object~parent as the player.

okay, now I understand #object# fully... laughs (I spoke to soon in my previous post, doh!)

--------

anyways... more reason for me to continue to like using #text# despite all of its issues (at least it can~will always work), lol

And again, the problem with #text# isn't the validation. The problem is that it will suck up all invalid input, making some commands return incorrect error messages, unless you re-parse the entire input again to find out what should have happened. For example, if you're in a room without a north exit, and you type 'n', and you have a command that is only #text#, then it will execute your command when you type 'n'. So instead of printing out "You can't go that way", it will print out whatever error you have in your command, which probably won't make as much sense.

I would suggest trying it out - you'll see all sorts of behavior that you'd have to try to compensate for. Definitely not worth the effort for such a small gain!

#text# definitely works better with an activator word, to limit its effect.

err... maybe this stuff is just a bit too advanced for me to understand, as I seem to keep failing to understand what you're trying to explain to me, arg.

My apologizes for having trouble with understanding this stuff that you're trying to explain to me... I think I'm kinda getting it... as I read each of your new posts... sorry for being a bit slow~stupid on this stuff... sighs.

this level of stuff is a bit 'too much into the code weeds' for my basic knowledge of coding at this point, as I'm not aware of all of this stuff you're trying to point out to me. My brain doesn't yet think about this deeper code stuff, that will cause all of these issues.

-------

ya, I definately wouldn't use a Command Pattern of only: #text# (as you point out, it will over-ride all of the built-in quest commands~stuff, so no correct default responses~expressions of those over-ridden built-in quest commands~stuff), as I see~understand (I hope) now at what you're getting at.

basically (if I'm finally getting this stuff you're trying to explain to me):

just do NOT use:

Command Pattern: #text~object#

EVER! lol

I never even thought about not needing what I wrongly called an 'activator' for Command's Patterns (aka using just #object~text# for the Command Pattern), until this poster's thread.

I've always used:

Command Pattern: say #text#
Command Pattern: say #text# to #object#
Command Pattern: say #text1# to #text2#
Command Pattern: equip #text#
Command Pattern: cast #text#
etc etc etc

and using no VARIABLES too (letting the scripting itself handle VARIABLES and~or checking~validation stuff):

Command Pattern: info
Command Pattern: equip
etc etc etc

but never did I even think of using just VARIABLS for the Command Pattern:

Command Pattern: #text#
Command Pattern: #object#

until this poster's thread

which is~was a good thing, due to all the issues of using only a VARIABLE (#text# or #object#) for the Command Pattern.

jaynabonne wrote:And again, the problem with #text# isn't the validation. The problem is that it will suck up all invalid input, making some commands return incorrect error messages, unless you re-parse the entire input again to find out what should have happened. For example, if you're in a room without a north exit, and you type 'n', and you have a command that is only #text#, then it will execute your command when you type 'n'. So instead of printing out "You can't go that way", it will print out whatever error you have in your command, which probably won't make as much sense.

I would suggest trying it out - you'll see all sorts of behavior that you'd have to try to compensate for. Definitely not worth the effort for such a small gain!

#text# definitely works better with an activator word, to limit its effect.

I think it is worse than that (though I have not tested it). I think it will suck up all input. As I understand it, Quest goes through the list of commands until it finds a match, starting with room specific, then your custom commands. #text# is going to match "north", "look", etc. so will override those built in commands even when valid.

In my test, it didn't do that. (I had a similar fear.) I'm not totally sure why, to be honest.

I agree that room-specific commands take precedence, but I'm not sure if Quest can know the difference between the standard commands and the ones you create. I think they all look the same (one just happens to live in the core file). So maybe it just finds the standard one first by chance.

But then, Quest keeps evolving, and I don't always keep up, so I might be wrong about that.

so... the take away is:

always use an 'activator' either by itself or with VARIABLES (#object# or #text#) for your Command Patterns

-----------

I'm sorry for my coming up with using just #object# or #text# from trying to help this thread's poster, I had no idea of the 'can of PARASITIC worms' I was opening up, I had no idea of the catasphrofic issues that creating a Command that would over-ride (possibly even worse) ALL input (as Pixie just posted as a possibly worse isue~outcome than Jay's issues~outcomes), lol.

well... despite my trouble in finally understanding what Pixie and Jay were trying to explain to me, I've now learnt a lot into the deeper working of quest's code, so at least I was able to finally learn from Jay's and Pixie's troubles in trying to explain this stuff to me.

Well, they are reasonable and (actually) creative ideas - they just have ramifications that make them a bit unworkable.

I had a similar idea once in a different situation. I had a pattern like this:

"#text#"

That was meant to be an input method for dialogue. Where you could just type something like

"How are you today?"

to indicate conversation. It worked as far as matching went, but I had no idea what to do with the text once it got to my command. I still like that, conceptually, as a mechnism for inputting conversation, but there's more heavy lifting to parse natural language like that than I feel qualified to attempt. lol

jaynabonne wrote:In my test, it didn't do that. (I had a similar fear.) I'm not totally sure why, to be honest.

I agree that room-specific commands take precedence, but I'm not sure if Quest can know the difference between the standard commands and the ones you create. I think they all look the same (one just happens to live in the core file). So maybe it just finds the standard one first by chance.

But then, Quest keeps evolving, and I don't always keep up, so I might be wrong about that.

Okay, just tested it myself, and as you say, it does not do that. Quest does give precedence to commands that are defined later in the code, which your custom commands will be (if you put custom commands before the library includes, the original commands are used). It looks like it gives lower precedence to commands that do not include #text# (or the RegEx equivalent).