I feel like this is probably a pretty simple answer. I want to be able to have two room descriptions, one that runs on the first entry to the room, and the other which runs after that. Thanks in advance!

In the room's description, enter something like this:

{if not room.visited:This is the first description.}{if room.visited:This is the later description.}

The first time you enter the room (when it's not yet visited), the description will print "This is the first description." Every time after that, it will print "This is the later description."

Ah, that's how you access the visited attribute. That's a bit easier than the method I'd previously been using (by creating my own attribute and running script to check it.) Thanks! I used to work with Quest a while back and I'm just getting back into it.

there's also this universal (used anywhere) Script too (put it within the "Room Description" or "On Entering Room" script):

http://quest5.net/wiki/Firsttime
http://quest5.net/wiki/Otherwise

(I'm sure this is within the GUI~Editor mode too, I just don't know where off-hand without checking on it ~ too lazy to do it, lol)

Correct:

firsttime {
-> // whatever script
} otherwise {
-> // whatever script
}

with using the "firsttime~otherwise", you do *NOT* need the "if~else" scripts:

INcorrect:

if (firsttime) {
-> // whatever script
} else (otherwise) {
-> // whatever script

Hi,

I'm still very new to QUEST, so sorry if this is a very basic question.

Firstly, I cannot use the excellent "Firsttime/Otherwise" solution as HegemonKhan has suggested. Whilst it does indeed work fine, I later want to be able to use the "Look" verb to display the initial room description. My testing has shown that once firstime has been triggered, I can't seem to get it to trigger again (using "look"). So instead I'm trying to use the room "visited" attribute (which I hope I can amend even though the WiKi description suggests I should never have to amend it!).

But this does not seem to work on the very first room in the game. It appears the core engine has already set the "visited" attribute to "True" for the room the player is placed in originally before my code gets control, so I cannot get my code to display the longer description for the first room in the game. Ive tried to add a script to "beforefirstenter" for this room:

    <beforefirstenter type="script">
      visited = False
    </beforefirstenter>

but that doesn't work for me either. Maybe I'm not coding this correctly? (It doesn't seem to like "room.visited = False" or "this.visited = False" either.)

Can anyone give any advice on setting the "visited" attribute for the very first room, and how I alter the "look" routine to reset the visited attribute back to false before the room is described again? (i.e. I haven't found where the "look/lookat" routine is coded - I assume it is in the core somewhere, but being a newbie here, I don't know; yet; how to get at and alter such code?)

Many thanks

Here's one way to do it:

<!--Saved by Quest 5.4.4873.16527-->
<asl version="540">
  <include ref="English.aslx" />
  <include ref="Core.aslx" />
  <game name="twodesc">
    <gameid>16234e53-37d9-4133-b229-08933adef2d2</gameid>
    <version>1.0</version>
    <firstpublished>2014</firstpublished>
  </game>
  <command name="look">
    <pattern type="string">^look$|^l$</pattern>
    <script>
      msg (game.pov.parent.longdescription)
    </script>
  </command>
  <object name="room">
    <inherit name="editor_room" />
    <longdescription>This is the long description for the room.</longdescription>
    <shortdescription>This is the short description for the room.</shortdescription>
    <description type="script">
      if (GetBoolean(this, "visited")) {
        msg (this.shortdescription)
      }
      else {
        msg (this.longdescription)
      }
    </description>
    <object name="player">
      <inherit name="editor_object" />
      <inherit name="editor_player" />
    </object>
    <exit alias="north" to="Another room">
      <inherit name="northdirection" />
    </exit>
  </object>
  <object name="Another room">
    <inherit name="editor_room" />
    <exit alias="south" to="room">
      <inherit name="southdirection" />
    </exit>
  </object>
</asl>

You can override the "look" verb to handle the look description. BTW, this is a bit hacky, and I personally wouldn't leave it that way. But it shows you the hook.

(To see the built-in commands, etc. select Filter at the bottom left, and choose Show Library Elements. If you want to modify one, select it and then click "Copy" at the top right to move it into your game file. It also shows you in which file it's located.)

Thanks jaynabonne,

That seems to work, thank you. I'd just found the "default.object" and given it a "shortdescription" field, so I was already starting down this path, as I want to give all rooms the possibility of two descriptions.

I will need to look at this in more detail to understand how you have got it to manipulate the "visited" attribute, as the debugger still shows visited=True immediately the room is described, so not sure how you got in to check its state before the core code set it to True. But not tonight! I've got to get up for work in the morning, so that's enough for today!

Thanks,
Ken

I may not be understanding this or got it right, as I'm not sure if jayna's "hack" (JS code syntax?) is involved in this or not, or if this is not what you're trying to ask about, or if you're saying that it's stil not working for you (maybe you made a simple mistake in adding in jayna's code or jayna' overlooked something in his code), but oh well, lol:

<description type="script">
-> if (GetBoolean(this, "visited")) {
->-> msg (this.shortdescription)
-> }
-> else {
->-> msg (this.longdescription)
-> }
</description>

the 'check' is:

if (GetBoolean(this, "visited")) {

conceptually:

if (this object has the boolean "visited" and it also has the value of "true"), then do "short description"
else, do "long description"

Alex coded the quest engine to understand a shortened syntax of:

Object.Boolean_Attribute

is the same thing as it's long (full) syntax:

Object.Boolean_Attribute = true

aka, if there's no "=false" value given, then the quest engine understands it to be "=true" value

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

errr... in reading your post over again... I think you're asking in how it works, despite the debugger still showing that the "visited=true", correct? (HK crosses his fingers, lol)

this must be because jayna's "hack" is JS (or whatever other programming language), which bypasses and~or ignores quest's setting of "visited=true" (which the debugger shows, but is unable to know about the independant other programming language at work through jayna's "hack").

-----------

P.S.

my bad, I missed that you wanted to keep the options of being able to 'see' (via two different verbs~buttons~hyperlinks) the two different room descriptions. The only other way (as far as I can think of) besides using two Verbs, is to have some script that you can activate at will (or circumstance) during game play, which would change the flags for which description is shown. This could be a neat idea (as you could connect the script, via "conditionally: "if" scripting, to whether you have a "truth revealing item" in your possesion or if equiped...), hehe: if (player.item_of_truth.equiped=true), then show "first time or secret description".

so my apologizes for not addressing this aspect that you needed help with, as I thought you just wanted to have a "first time only" description, and then a more generic "every other time" description. I didn't know you wanted to keep the ability to see the "first time" description beyond it's initial appearance~usage, along with also being able to 'see' the generic "every other time" description too.

HK: I have no idea where you get that the hack is JS - there is no JavaScript code in there at all.

Ken: After I posted that and went to bed, I realized that this code is bypassing the normal "You can see..." and "You can go..." sort of description pieces when you type "l" (or "look"). So I don't think it's really a viable solution unless you're happy with bare bones descriptions.

The default "look" verb just does ShowRoomDescription. What you could probably do (not tested) is what you were initially wanting to do - set visited to false before calling ShowRoomDescription in that command:

  <command name="look">
    <pattern type="string">^look$|^l$</pattern>
    <script>
      game.pov.parent.visited = false
      ShowRoomDescription
      game.pov.parent.visited = true
   </script>
  </command>

Also, instead of changing the default object, you might want to consider adding your own room type (MyBaseRoom or something like that). Then you can add the shortdescription there and then just inherit that type in all your rooms (more work, I know, to do all the inheritance, but it saves your code from potentially breaking in future revs of Quest if the base object type changes. And it makes the changes your own).

err... I'm just refering to the symbol using language that you used here:

<command name="look">
-> <pattern type="string">^look$|^l$</pattern>

I wrongly presumed this is JS, so my apologizes for any confusion, especially to ken, and apologizes to you jayna for presuming that this is JS.

I vaguely know that the "|" is 'piping' (connecting ~ but don't understand it very well yet)... but I don't know what the other symbols are~do without looking them up.

-----

I like quest's language, as it doesn't use all these symbols like so many other languages do.

As it's a pain to remember what all the symbols are or do, though it cuts down on the amount of code typing that is needed, which is good (if you can memorize~know the symbols, lol). So I like quest better, as it doesn't use these symbols that I have to try to memorize, lol. As for typing more... I like to type, and also I found that a little more typing to help me out with the organization and~or a structure~system of things is well worth it, lol.

That is what's called a "regular expression". It's a way of defining pattern matches in a more robust way.

Check it out here: http://en.wikipedia.org/wiki/Regular_ex ... c_concepts

The vertical bar ('|') is used to signify "or", for multiple possibilities. The '^' means beginning of line, and the '$' means end of line. The expression is:

^look$|^l$

which means "match either 'look' or 'l', where they are on a line by themselves (only begin and end of line markers around them). I'm no regex expert (regexpert?) by any means; I'd have to look a lot of stuff up to do more complex expressions. (The one in the code was the one the look command already had.)

ah thank you, so it's not even a language, but merely a basic expression usage. Knowing that Quest can use JS, I had wrongly presumed that these were symbols for JS' format~syntax (having never yet examined what JS is or looks like).

that makes simple sense (though I probably will have a hard time remembering it, lol):

' ^ ' is the same similar'ness ("start alert") as ' <object name="blah"> ' or ' { '
' $ ' is the same similar'ness ("end alert") as ' </object> ' or ' } '

It's not so much that. If you left off the '^' and '$', then it would match not only "look" but also "have a good look", "look around" and "look at me!" (not to mention "lookie here son"). By adding the line markers, it forces the match only in the case where it's on a line by itself, no spaces, no other characters. It really is specifying what to match, not begin/end markers as XML tags are.

ya, I was reading up on it in your wiki link, the metacharacters (?,+,*) used for the string match checking... "0 or 1", "1 or more", and whatever the third check was... meh, lol. (I had to look it up, lol: the third check: "0 or more")

the ' | ' in regular expressions means "or", but I think in some other programming language (or whatever) it is used for and known as "piping" or "pipes" ( http://en.wikipedia.org/wiki/Pipeline_(Unix) and https://www.google.com/#q=programming+piping )

add the ending ')' to the unix link (its url) for it to work, the ending ')' got cut off again by the posting again, not sure why...

this string matching ("patterns") and coding theory stuff is quite fascinating... using it with algebra (or beyond) for matching all specified combinations of strings... though it's way over my head, laughs. Ya, learning to code is gonna take me at least 50 years, lol.

let's see if I remember the algebra (it's been so long ago)...

x^2 - y^2 = (x-y) (x+y)
factoring... argh...

thanks for that wiki link on regular expressions ("regex")... though it scares me... way beyond my intelligence level... laughs.

Regular Expressions are briefly touched upon in the tutorial (or some other source on this site or its wiki site), and I barely understood that uber simple example that they gave for regular expressions, so I stayed away from it, and now I know much more about regex'es, and thus know I made the right choice to stay away from them, YEESH!, lol. I now fully understand why you got to be really good at math for programming... sighs.

If you (or anyone else) would like to see some simple regex examples, here is an interesting page:

http://www.icewarp.com/support/online_h ... 030104.htm