Ok. The whole idea is like this: I want the player character may execute an action, so it would be a verb. However, i don't want he/she/it execute this action everywhere, but only when at some specific rooms, which are a long list for adding ifs to the verb. Is there ant simple way of linking to a room the idea that the verb may be executed there?

Actually, it goes a little further, because i would really appreciate having other verbs valid only at specific rooms.

Verbs and commands can be added to rooms. Then they only apply in those rooms.

Note that there is a difference between verbs and commands. Verbs are special forms of commands that apply to objects. The pattern should include an object reference. Commands can be simple things like "jump", but they can even be things that seem like verbs (e.g. "unlock safe"). If you only need something to apply to one object, it might make sense to make it a command where the object is part of the pattern rather than making it a general purpose verb that could apply to all objects. Without knowing what you're doing, I can't recommend one over the other. But I just wanted to let you know that having the player do something can be accomplished with either verbs or commands, not just verbs, depending on what you're trying to do.

Verbs:

you also can have scripting do the full/entire work for you:

give your desired rooms an indicator/flag Attribute (String Attribute or Stringlist Attribute ... or Boolean Attribute: *but it's better to use a String or Stringlist), which thus can be checked, and thus you can create/add Verbs to those specific rooms, for example:

I like using 'type_of_object' as my (indicator/flag) String (or Stringlist) Attribute's name (and also to include the type of attribute into the name, use underscores, and no uppercase, as well - my personal naming/labeling convention) to separate it from all the other things that use 'type' in their names/whatever)

<object name="room_1">
  <attr name="type_of_object_string_attribute" type="string">dungeon</attr>
</object>

<object name="room_2">
  <attr name="type_of_object_string_attribute" type="string">world</attr>
</object>

<object name="room_3">
  <attr name="type_of_object_string_attribute" type="string">dungeon</attr>
</object>

<object name="room_4">
  <attr name="type_of_object_string_attribute" type="string">world</attr>
</object>

<function name="populate_verbs_function">
  foreach (object_variable, AllObjects()) {
    if (GetString (object_variable, "type_of_object_string_attribute") = "dungeon") {
      // script to create/add your dungeon Verb to it, the 'set' Function/Script, and I assume that you can create/add a Script Attribute (which is what a Verb is) with it...
    }
    // optional extra condition checking for other types of objects:
    else if (GetString (object_variable, "type_object_string_attribute") = "world") {
      // script to create/add your world Verb to it, the 'set' Function/Script, and I assume that you can create/add a Script Attribute (which is what a Verb is) with it...
    }
  }
</function>

<game name="blah">
  <attr name="start" type="script">
    populate_verbs_function
  </attr>
</game>

<verb>
  <property>dungeon_verbs_property</property>
  <pattern>dungeon_verbs_pattern</pattern>
  <defaultexpression>dungeon_verbs_default_expression</defaultexpression>
</verb>

// optional extra Verbs:
<verb>
  <property>world_verbs_property</property>
  <pattern>world_verbs_pattern</pattern>
  <defaultexpression>world_verbs_default_expression</defaultexpression>
</verb>

--------

you can also use Object Types (quest's user level of Groups/Classes) to reduce the workload by yourself (not as much as using scripting, of course):

(Object Types are found under/within the 'Advanced' on the left side's "tree of stuff" or in the 'advenced' under/within the top menu bar's 'add' category)

<object name="room_1">
  <inherit name="dungeon_object_type" />
</object>

<object name="room_2">
  <inherit name="world_object_type" />
</object>

<object name="room_3">
  <inherit name="dungeon_object_type" />
</object>

<object name="room_4">
  <inherit name="world_object_type" />
</object>

<type name="dungeon_object_type">
  <attr name="YOUR_VERBS_NAME" type="script">
    // your dungeon Verb's script(s)
  </attr>
</type>

// optional extra object types:
<type name="world_object_type">
  <attr name="YOUR_VERBS_NAME" type="script">
    // your world Verb's script(s)
  </attr>
</type>

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

Commands:

Commands are different in that they take in typed-in input during game play (so they're universal, not tied to a specific Object like a Verb), examples:

// this Command, upon typing in 'info' during game play, will only display your currently controlled character (Player Object):

<object name="player">
  <attr name="alias" type="string">HK</attr>
  <attr name="age_integer_attribute" type="int">18</attr> // I wish I was still 18, lol
  <attr name="age_string_attribute" type="string">adult</attr>
  <attr name="sex_string_attribute" type="string">male</attr>
  <attr name="race_string_attribute" type="string">human</attr>
  <attr name="class_string_attribute" type="string">warrior</attr>
</object>

<object name="player_2">
  <feature_player /> // this is how you set/tell quest that this Object can be a Player Object (what it does through using the GUI~Editor's option), and I think this ('<feature_player>') is syntax shorthand for: <attr name="feature_player" type="boolean">true</attr>
  <attr name="alias" type="string">Mike</attr>
  <attr name="age_integer_attribute" type="int">25</attr>
  <attr name="age_string_attribute" type="string">adult</attr>
  <attr name="sex_string_attribute" type="string">male</attr>
  <attr name="race_string_attribute" type="string">human</attr>
  <attr name="class_string_attribute" type="string">wizard</attr>
</object>

<object name="monster_1">
  <attr name="alias" type="string">orc</attr>
  <attr name="age_integer_attribute" type="int">30</attr>
  <attr name="age_string_attribute" type="string">adult</attr>
  <attr name="sex_string_attribute" type="string">male</attr>
  <attr name="race_string_attribute" type="string">orc</attr>
  <attr name="class_string_attribute" type="string">berserker</attr>
</object>

<command name="static_character_information_screen_command">
  <pattern>info</pattern>
  <script>
    ClearScreen
    msg ("Name: " + game.pov.alias)
    msg ("Age: " + game.pov.age_integer_attribute + " (" + game.pov.age_string_attribute + ")")
    msg ("Sex: " + game.pov.sex_string_attribute)
    msg ("Race: " + game.pov.race_string_attribute)
    msg ("Class: " + game.pov.class_string_attribute)
    wait {
      ClearScreen
    }
  </script>
</command>

// Input:

info

// Output:

it'll either show the stats for 'player' or 'player_2' (due to using 'game.pov' only --- otherwise, this would be limited to a single specified Object only), depending on which is the game.pov (your currently controlled Player Object), but it will NOT show the stats for the 'monster_1'

VS

// this Command, upon typing in 'info (whatever object)' during game play, will display that inputted Object's information:

<command name="dynamic_character_information_screen_command">
  // you're not limited to a single parameter, and there's two types of parameters: #text# / #textXXX# or #object# / #objectXXX#, as you can see, you parameter must start with '#text' or #object' and end of course with the '#'
  <pattern>info #object_parameter#</pattern>
  <script>
    ClearScreen
    msg ("Name: " + object_parameter.alias)
    msg ("Age: " + object_parameter.age_integer_attribute + " (" + object_parameter.age_string_attribute + ")")
    msg ("Sex: " + object_parameter.sex_string_attribute)
    msg ("Race: " + object_parameter.race_string_attribute)
    msg ("Class: " + object_parameter.class_string_attribute)
    wait {
      ClearScreen
    }
  </script>
</command>

// inputs:

since we're using the '#object#' parameter, it means that quest will look for an Object with the same 'name' ID String Attribute as the inputted name, and if it can't find an Object with that 'name' ID String Attribute, it'll then look for an Object with an 'alias' String Attribute of that inputted name, and if it still fails, then it returns 'null' (so: no error occurs if it can't find an Object, don't need to worry about coding to handle it not finding such an Object with the same 'name' ID String Attribute or 'alias' String Attribute)

info player
info HK
info player_2
info Mike
info monster_1
info orc

outputs:

it'll display (assuming the Object has those Attributes --- we should have coding to check if the Object has these Attributes too, but meh, this is just a quick example for you of using Commands) the stats of the inputted Object, so it can show the stats of any of the 3 Objects: 'player', 'player_2', or 'monster_1'.

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

* why a String (or Stringlist) is better than Booleans, example:

using Boolean Attributes:

// very cumbersome (BAD DESIGN!), but it does allow for easy/simple (coding-wise) use of having multiple (any combination of) effects at the same time:
player.poisoned = false // change to 'true' when poisoned
player.asleep = false // change to 'true' when put asleep
player.stunned = false // etc etc etc
player.paralyzed = false // etc etc etc
player.petrified = false // etc etc etc
player.silenced = false
player.confused = false
player.cursed = false
player.undead = false
player.dead = false
player.unconscious = false
etc etc etc Boolean Attributes (in this example of: conditions/effects/status_effects)

VS

using a String Attribute:

// NO cumbersome-ness (GOOD DESIGN!), but limited to only a single effect at a time:

player.condition = "normal" // change to "whatever effect/condition/status_effect" when it happens to the 'player' Player Object:
// player.condition = "poisoned"
// player.condition = "asleep"

VS

using a Stringlist Attribute:

// some Cumbersome-ness in the extra coding needed but this can't be helped as it's a List (it's still a GOOD DESIGN! it's probably better than using gazillions of Boolean Attributes --- just for your own sanity, the fewer the Attributes you got to create and handle the better for you personally, lol --- , well unless you only have a few effects/condtions/whatever, but for large amounts, Lists are probably better than Booleans - at least if you can easily create the coding needed with using lists and/or for your game design needs, if you want/need to have multiple conditions at the same time):

player.condition_list = split ("normal", ";")

say you (want to) get/be poisoned and petrified:

player.condition_list = split ("poisoned;petrified", ";")
~ OR ~
list remove (player.condition_list, "normal")
list add (player.condition_list, "poisoned")
list add (player.condition_list, "petrified")

If you do want to go the scripting route (e.g. if you need to have the verb or command in multiple rooms - hmm, I've never tried having base types for commands to put the common code in one place), you'd be better off keying the verb activity off of a flag in the desired rooms rather than adding an "if" for the name of each. That way, you can have a single "if" (e.g. if (HasAttribute(player.pov, "doverbhere")) which doesn't need to know about the rooms, and then you can simply mark each room by setting that attribute. It will apply in those rooms, and it won't in the ones without the attribute. You can also use types to mark a room instead ( if (DoesInherit(player.pov, "verbisactivehere") ).

Either way, listing all the room names in "if"s is probably the least desirable way to go, because then one routine is required to have knowledge about all the places it's used (this is known as "tight coupling", which is generally a bad thing to have in programming).

Hahahaha. I confess took some time until I get able to understand the proposals here.

By default, when I see something like command in Quest editor I just skip. It sound too important and too high level for my skills. I suppose would be a nice moment to study commands.

Lets take a look on two actual cases. One is the sing verb. I want a singer character be able to sing a song. However, I don't want it happens during all the game. It may sing when at the stage, during a scene cheering up a girl, during a dinner and other situations /rooms. However, each time it sings, a different massage will be displayed taking in account the place and audience reaction. When singing at other places, different massages will be printed instead of just saying "you can't do that"

Another case is that I plan using a Drama point. It is recurring in my projects, just changing name as desired.

The idea for this specific project is that the player may use the verb / command to Invoke the drama on something. It works as both a hint system or a task resolution, depending on the situation. When used on a talisman, it reveals a secret opening, when used on an enemy, allows winning a fight or when used in a room, hints a secret passage. That is why I am pursuing so much case by case solutions instead of general commands.

For the "sing" case, I think you definitely want a command instead of a verb, as a verb requires a target object, and you wouldn't do something like "sing book" or "sing apple". And even if it's "sing song", there wouldn't be a visible "song" object to physically target.

If you go the "local command to room" approach, then it will work for what you want for "sing", as each instance has a different effect, and there's no need to have a single global command with all the unrelated cases in it. The problem with having the commands in each room is that when you're outside one of those rooms, Quest will respond to "sing" with something like "I don't understand what you mean" instead of "This isn't a good place to sing." You can solve that by actually creating a global sing command that does nothing besides print out your default "No singing here" message. Then override it in the rooms you wish to have it actually do something.

The "Drama" point I'm not sure about, as you didn't give an example of what would be typed. But if you will be using it on an object ("use drama on talisman"), then that would be using the built in "use" system, and if it's more "Drama talisman", then that could be a verb. Or not, depending on what you want to do.

why a String (or Stringlist) is better than Booleans, example:

using Boolean Attributes:

// very cumbersome (BAD DESIGN!), but it does allow for easy/simple (coding-wise) use of having multiple (any combination of) effects at the same time:
player.poisoned = false // change to 'true' when poisoned
player.asleep = false // change to 'true' when put asleep
player.stunned = false // etc etc etc
player.paralyzed = false // etc etc etc
player.petrified = false // etc etc etc
player.silenced = false
player.confused = false
player.cursed = false
player.undead = false
player.dead = false
player.unconscious = false
etc etc etc Boolean Attributes (in this example of: conditions/effects/status_effects)

If there is only a single "condition" state, then using bools *would* be bad, since only one would be active at a time. So, yes, in the case you're describing, what you actually have is an enumerated type, and you should code it that way. That doesn't mean bools are bad in general. In fact, if you needed multiple state flags set at once, it would be a good way. No language feature is good or bad on its own. It comes down to what's needed.

And the code you posted isn't really applicable to what we're talking about here, nor is it what I was referring to (assuming you went back and made all those edits with comments after my response based on what I had said, which I'm not sure but seems likely since you're critiquing the use of flags, which I had suggested, but in a different unrelated context).

The best case (as usual) is to avoid script you don't need and use the built-in facilities in the language (any language) to make life easier when possible. In this case, the "verb/command in a room" ability works as desired, and even going the route of types to identify rooms (which I had suggested) would be overkill, now that the needs are known.

Oh, Jay. I really appreciate the use of flags. I cannot do everything I want with it, but every time I am about using a string attribute, I pause and wonder if I would use a boolean.

Through this thread you two guys gave me a clear insight about what commands and verbs are and how they work as well.

I suppose that many of my problems, including the sing stuff, would be solved by a local command. However I am not yet sure about how implementing this.

Talking about the dramatic drama thing drama, I guess you, Jay, is absolutely right about the verb approach. I guess I was just not thinking clearly. Perhaps I could hide on the relevant objects a verb named drama and the player would type "drama villain " in order to defeat the villain object in a direct and simple way. I can do the same on other objects for different effects. Each time the player "dramas" an Object, it responds with a useful different effect related to the Object itself.

As I said once somewhere in the forum, I really prefer using the GUI and the tools Quest offers than go messing around implementing codes I don't really understand fully as you, experts do. So, anything suggesting using built in resources is my best option.

And talking about built-in, where may I find a list of built-in verbs, it's working and if it's possible editing it. One of the books in my game may be read. However Quest has this verb as default, but I could not figure how adapting the desired effect.

If you click the word Filter at the bottom left (below the object pane), and then select "Show Library Elements", then it will show in all the built-in stuff: verbs, commands, types, etc. You can even pick one of the built-in elements and copy it into your game for editing (the button for that will appear in the top right of the screen when you select one of the built-ins).

Having said that, be aware that verbs are typically bare bones. Something like "read" will have no default behavior besides "you can't read that". It's up to you to define the behavior in your object, and you can do that by selecting the object and then its "Verbs" tab and adding in the verb you want (e.g. read). It's usually better to define the verb before you try to add it to an object, if you want to create a new verb. Quest will auto-define a new verb for you from the object verb tab, but there have been problems with that approach.

That's exactly the point. I tried the "read" verb on an item and the custom verbs tab complained it already existed. So I began to wonder how alter the built-in verbs to my endings.

It is not complaining, it is being helpful. Just select "read" and then put in the custom text or script for that item.

That is what I will try doing next working session. I guess tomorrow we will know if the matter is solved and jump onto the next issue I will struggling with. I need finding a way to learn faster.

There's not too much difference from Commands and Verbs, just different designs are used on their different ways that they can be implemented. So, you can use whichever you're more comfortable with.

from your recent post explaining more about what you want... it seems more like you just need to know about using Functions (if you don't know about them already), as you can put your desired scripting into a Function, and then where-ever/when-ever you want to do that scripting (various Object's Verbs or within a global Command or various local:individual-room-only Commands) you just add in the GUI~Editor's 'call function' Script (using the function's name in its small rectangle text box of its big add box) or in code you literally just write/type in the Function's name. Of course the scripting within your Function will need to address whatever the needs that have already been talked about.

-------

Sorry for my assumptions about code design Jay, I'm still just beginning in understanding code designs/etc, and obviously have got my assumptions wrong on some of this stuff, sighs. I was thinking more about as game maker, having lots of Attributes (especially via using Booleans) as opposed to less Attributes, is a lot more work for you, so when you can, I thought it would be better to use Strings and/or Lists to lessen the amount of Attributes, assumingly that overall even with the extra code scripting for/if using Lists, would be less than all the scripting needed to work with Booleans as well as having all those Boolean Attributes themselves. So, as can be seen, my understanding on design/efficiency/etc is still very limited/noobish/beginner, as I try to think about this stuff, being introduced to it more and more, as I'm learning more programming and especially from the assembly/computer architecture class. I'm in a learning phase trying to learn, and thus am making a lot of mistakes as I try to learn more about designs and/or efficiencies/how code processes work/etc.

HK, as with everything, it depends. And I was mostly mentioning it not as criticism but *because* I know you're learning, and I was hoping it would be helpful.

it is very helpful, I appreciate the corrections/explanations, as it helps me build up a better/more-correct understanding of it! I must apologize, if I came off badly in my post. I didn't mean that at all, sighs. I had only intended to explain that I'm just giving my best understanding of things as I try to help others understand these things, but that understanding of mine is still limited, beginning level, and often incorrect. I learn best by trial and error, I throw out/post my understanding, and it gets corrected/explained by others, hehe:D Is this post correct? no, here's why it is not and here is what is correct. Thank you, now I've learned something from my mistakes and through a trial and error of my use of ideas/presumed-underandings process!

Well, I must say, given the way your posts have been as of late, you have learned quite well. And we all have much to learn. Sheesh, I feel out of date sometimes. lol

well... I'm hitting a bit of a plateau in my progression, sighs. But, I've come a long ways from having started from nothing, thanks to quest, you, pixie, pertex, and all the others here, and also the programming classes I've been taking now, despite me not being that smart and programming (and the math and physics/electronics/logic also involved, argh, lol) being indeed difficult to learn, as it's a major field of study / school-carreer choice/path, that I hope I can make it through to (at least) a bacheler's in CS, lol. I got a long ways to go... the math and physics I got to also learn scares me a bit... sighs. I started to struggle in math upon hitting calculus and I've never really learned/delved into physics at all either (all I had was a basic physics class in high school and never done any robotics/engineering stuff on my own as hobby/whatever).