On the Container tab of an object, it says "Message to print when opening (leave blank for default)".

What if I want it to say nothing? If I leave it blank, it puts in a default message, so how do I leave it actually blank? Even if I put in just a space, it prints a blank line that is ok I guess but rather messy-looking.

The message I want to give will be different depending on other attributes, so I want to put the message in the script part below for the "after opening the object" section. And unless I can blank out the message above, I get two messages :-S

psymann

there might be some code to prevent the default message or to create an actual "no or non" message (without leaving a blank message space), otherwise, you'll just have to change the default templates, if you need help, I think I can point you on how to do so, or if not, you'll have to get help from someone else, who does know how to do it correctly.

When you open a container, it calls this function by default:

  <function name="OpenObject" parameters="object">
    if (HasString(object, "openmsg")) {
      msg (object.openmsg)
    }
    else {
      msg (DynamicTemplate("OpenSuccessful", object))
    }
    object.isopen = true
    ListObjectContents (object)
  </function>

As you can see, it's a simple if/else. You either get "openmsg" ot the standard template. However, if you define a script called "openscript" in your object, then it will *not* call the above. So you can take control and do what you want. Note that it won't even open unless you make it open (e.g. take the relevant part of the above).

A simple one is this:

<openscript type="script">
    this.isopen = true
    ListObjectContents (this)
</openscript>

Note that for this script, the object is passed in as "this". Also, the standard "onopen" script is called as a response to this.isopen being set to true.

Hope this helps!

Hmm, thanks for those ideas. That level of fiddling with default code makes me think that the problem is probably with what I'm trying to do

I think my problem is to do with locking - I have a door that is locked, but it is unlocked with a command string (eg "say open sesame"), not with an object (eg "use brass key on door"). And the "lock" option for a "container" appears to require an object to unlock it.

What I was trying (and failing) to do was have two options for Open, blank out the default message, and use the After Open script to do this:
1) opensesame flag set to true: "You open the door."
2) opensesame flag set to false: "You can't open the door, it's still locked." [and then script it to close the door instantly so from the user's point of view it's never opened]

Now what I'm thinking is a better bodge is this:
1) command "say open sesame" has a script that adds an invisible, un-droppable object called "opensesamekey" to Inventory that the user can't see
2) set the lock "key" to be the "opensesamekey" and set it to "automatically unlock if player has key".

I'll give that a go because, especially while I'm doing my first game, I don't want to put too much complicated code in, lest I muddle myself and get tangled up in it

psymann

Well, you can make it simpler: forget the object/key route and just lock/unlock it yourself. So change it to:

1) command "say open sesame" has a script that sets "locked" to false on the container (e.g. use "Set object flag")

Sorry, I should have said "Unset object flag". (I thought "set object flag" took a parameter.) That's what I get for not using the GUI... lol

Hmm, well, my dodgy dummykey method seems to have worked but now I read your suggestion that sounds better. A flag is different from an attribute? Or the same somehow? I'm still a but confused by those - I sort of expect to see an attribute called "locked" that I can set to true or false, but can't see that. If it's a flag, how do I know what the name of the flag is?

Ie say that the door is called "Door", what's the GUI (or even the code) way to say:
"Set the Door to be unlocked" ?

=====

Though now I've got a new problem because by playing more with these containers, I've just realised that Quest will now allow my user to "put [object] in door" once the door is open. Oh dear! :-/ And I can't see a "can't have things put in it" attribute either.

Should I be using "Openable/Closeable" option instead? If so, what is all the code it produces when I select that option? :-S

Doors are more complicated than I expected!

psy

You can also use the script "Lock exit"

I might have this wrong myself, but my understanding is that:

a "flag" is simply another term used by coders for a boolean (true/false) attribute.

when you "set a flag on" you simply are setting that boolean attribute to true/false, and when you "set a flag off" you simply are setting that boolean attribute to false/true.

I think "flag" is used, is because usually you have other script that activates or deactivates depending on whether the "flag:boolean is on:true or off:false", so when you "set" (change) the "flag" (boolean attribute), now you'll produce different results, due to your "flag" now having a different setting. so, you're "flagging" it, and thus where~how the terminology of "flag" comes from. Or, maybe it goes even further, to flag language, such as used in the navy, different (actual physical), or the number of the, flags mean different things, which can be seen from far away, or the flags are used to make it easier to see a movement which means something specific, think of like baseball signs, but the use of flags instead of the coach's hand, lol. Or, maybe it is like, "you raise a flag", the "flag of walking is now raised and the flag of flying is now lowered" and the reverse of the "flag of flying is now raised and the flag of walking is now lowered".

A "flag" represents the action that booleans attributes of true/false (and their switching~changing between true or false) do or are used to do, and so coders use the term of "flag", and~or a "flag" is recognizable by non-coders, whereas a non-coder is like, "WTF?!, is a boolean?", lol.

that is probably confusing, so let me use an example, lol:

the "player" has a boolean attribute called "flying" and it's value is set initially to false.

there's a key that is far above the "player's" reach that he must get. (the key has it's own script not letting it be taken unless the player's "flying" attribute is "true" = if flying, then take key; if not flying, than msg "What?!, Did you think you could fly?!")

while his "flying" is false, the "player" can't get the needed key.

however, the player has a flying potion in his~her inventory, and upon drinking it, it "Sets the flying flag" to "On" (true) or now has "flagged flying", and now the player can get the needed key.

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

yes, doors and exits are not noobie friendly, lol. there's been some complaints about exits (mainly exits) and thus their often corresponding need of a "door" object, to unlock the exit. people want the exit to act like a "door" itself, instead of having to create an additional object, a "door" object to go along with the exit.

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

in this case, you should ignore the GUI~Editor, and work with the code. As the GUI-Editor limits or confuses you, as it's the code lines that matter, and the GUI-Editor 's choices (container vs openable~closeable) thus limits you in what code lines are available for you to use at the same time.

you can have any code you want, even creating a "chimera" object that can do ALL (or any combination) of these things:

openable~closeable = a "door"
lockable~unlockable = a "door or chest or whatever"
container (open, closed, and~or surface) = a "container or something's top, like a table's top or a counter's top or a desk's top"
switchable (turn on/off) = "electronics or spell or whatever)
etc etc etc (see the different tab's options of~for objects)

if you want to map out what the GUI~Editor's options match to what code lines, please do so for us!, lol

for example:

choose some object to be a SURFACE container, and then check the code, to see what code lines are used (ADDED) for it.
do the same for OPENABLE~CLOSEABLE, SWITCHABLE, and etc etc etc

you can trick the GUI~Editor, choose the object to be a container, so you're given the lockable~unlockable options, select it to be lockable (so that, that option remains there), and then switch the object to be OPENABLE~CLOSEABLE instead of a OPEN~CLOSE container, and you'll retain the LOCKABLE~UNLOCKABLE options, as otherwise, if you just set the object to be OPENABLE~CLOSEABLE, you won't have the options of LOCKABLE~UNLOCKABLE.

so, thus, just work with the code, as the GUI~Editor is messy at best, or limiting at worst, lol.

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

P.S.

you can see Alex' quest engine's core's coding in the GUI~Editor by simply clicking on the filter in the lower left corner, and choosing to show all the stuff (or whatever it is called), it'll be shown as a light grey, in the left pane's "tree of stuff", you can see all the pre-set verbs, and etc, and see how Alex has them set up to work, though for you and me (for noobs or at least me anyways) the coding is a bit too complex for us to try to create on our own, lol. Though, it is very educational to look at, hehe.

This is where~how Jaynebonne has provided the "open" scripts in his~her above post (or he~she just looked at the core code provided online of quest, lol), for instance.

sonic102 wrote:You can also use the script "Lock exit"

And there's the problem, sonic, I can't because it's not the exit I'm locking, it's the Door. And the Exit is only unlocked when the Door is opened.

As HK mentions, having to have a separate Exit and Door is a tad confusing, especially when you've chosen to set your first adventure inside a house with a load of doors I now see why so many games are set in forests!

HK wrote:you should ignore the GUI~Editor, and work with the code

But I like the GUI
It's nice and tidy and stops me from making typos by putting curly brackets in the wrong place and mistyping exittokitchen and exitokitchen and not noticing.

What I kind of want to avoid - for now at least - is burying my head so far in the code that I spend all my time debugging and none writing

I'm guessing I really need "openable/closeable" for the doors, but just need to work out why it splurges a load of code into my game when I do that. As soon as I pick "openable/closeable", while "locked" is already selected, it gives me this:

if (this.locked) {
  if (this.autounlock and ListContains(ScopeInventory(), this.key)) {
    do (this, "unlock")
    if (not this.isopen) {
      OpenObject (this)
    }
  }
  else {
    msg (DynamicTemplate("LockedObject", this))
  }
}
else {
  OpenObject (this)
}

I guess that's what you meant about tricking the GUI into permitting lockability to an open/close object? Just that it confuses me in the process by putting in a load of code I don't understand. And I do dislike having code that I can't explain in my project

Perhaps I just trust it to be doing the right thing, and add my own items underneath that splurge.



Anyway, I'm think I've worked out what I have to do on the GUI now with your help above:

- Choose "Set Variable or Attribute"
- SET VARIABLE [Kitchen Door.lockable] = EXPRESSION [false]
- And then, as long as I've set the door as something with a lock, then lockable will be an attribute it knows and that works

Whoo!

psy

I'm guessing I really need "openable/closeable" for the doors, but just need to work out why it splurges a load of code into my game when I do that. As soon as I pick "openable/closeable", while "locked" is already selected, it gives me this:

Actually, it doesn't (splurge into your game).

Quest has core functions and then functions that are in your game file. You can choose to edit the core functions by copying them up into your game file, and Quest makes that easy for you to do - if you want to.

If you look at the case you describe, you'll see that above the script is a button that says "Make Editable Copy". Until you do actually click that button, the Quest GUI editor is just showing you the current code that is down in the core lib. It's not actually in your game file. You can move a copy up into your game file and make it editable by clicking that button (if you choose). Scripts in your game file override those in the core lib.

Anyway, I'm think I've worked out what I have to do on the GUI now with your help above:

- Choose "Set Variable or Attribute"
- SET VARIABLE [Kitchen Door.lockable] = EXPRESSION [false]
- And then, as long as I've set the door as something with a lock, then lockable will be an attribute it knows and that works 

Actually, there is no "lockable" attribute used by Quest. Perhaps you mean "locked"? (If you'd like to get a hint of the attributes possible, without pawing through the core source, you can see some by going to the "Attributes" tab for the object.)

There is a "container_lockable" type, but you can't change that on that fly. Actually, I don't think you'd want to change "is this door lockable?" on the fly anyway. A door is either able to be locked or not from square one, usually...

Sorry, yes, brain-typo - I did indeed mean "Kitchen Door.locked".


And yes, I see the "Make Editable Copy" now you mention it there. My eyes had just glazed over up till then with an "Oh goodness what the hell is that!?" when all the splurge came up, and I hadn't realised it had not actually splurged into my game file but was just hovering near by.