Hi, I'm new to Quest and its functions, and I like it, however there is one things that's SEVERELY bugging me.
I'm trying to create empty rooms where it just gives you the basics, rules etc. with a single link (I use the exits for that) taking you to the actual beginning of the story/game, but the destination ALWAYS appears in the room description even though I've tried my best to get rid of it, first attempt being removing the prefixes, suffixes and such, but all that does is just get rid of some text, leaving the rooms left there.
This is issue is very annoying and I'd appreciate any help.
Additionally, if you can be so kind, could you please tell me if there's a way to create custom exit names, rather than "North," "South," or "In?" This would be a big bonus in the quality and appearance of my Quest game.
Thanks in advance!

I don't have quest open at the moment, going on memory, so this might be a bit wrong/off....

http://docs.textadventures.co.uk/quest/elements/game.html (here's the code/about the global settings/options/Attributes)

global options/settings control:

'game' Object -> 'Features' Tab -> UN-check the 'automatically generate room descriptions', or whatever other relevant options

or if you want to set an individual Object's options/settings:

'whatever' Object -> 'Room Descriptions' Tab -> see the various options

custom exit names:

http://docs.textadventures.co.uk/quest/tutorial/creating_a_simple_game.html (scroll down to the Exits section)

I haven't worked much with the GUI~Editor, so I'm not sure how you give them your custom names, but I think maybe you can click on the big square exit boxes, to give them your custom names, or maybe you need to 'edit' their script and it lets you name/re-name it.

here's the Exit definition/Attributes in code:

http://docs.textadventures.co.uk/quest/elements/exit.html

it does have an 'alias' Attribute for you to give it your custom name. I'm just not sure how it's done in the GUI~Editor. If you know code, then you can just code it in directly in code.

here's the tutorial, if you don't know about it:

http://docs.textadventures.co.uk/quest/tutorial/

and then check out XanMag's 'tutorials and templates' (tutorial 2) game:

http://textadventures.co.uk/forum/games/topic/5940/quest-tutorials-and-templates-published

here's the docs site for quest:

http://docs.textadventures.co.uk/quest/

here's the guides:

http://docs.textadventures.co.uk/quest/guides/
http://textadventures.co.uk/forum/samples

Go to the "Room Descriptions" tab of the game object. Some way down is "Exits list". Change this to 0 and it will stop Quest displaying the exits as part of the room descriptions. Note that this is a global; it will apply to all rooms.

To change the name of an exit, select it, and then change it to whatever you like... if you are editing off line. This does not seem to work on-line (I can think of a way around that, but it is not simple).

On my part, I wanted "transparent rooms" that would be invisible to the player and would be used to "structure" the game and/or the code.
Here the player is in room1 and must go to room3 via room2 which will be invisible to him and be used only to run a script.

  <object name="room1">
    <inherit name="editor_room" />
    <object name="player">
      <inherit name="editor_object" />
      <inherit name="editor_player" />
    </object>
    <exit alias="south" to="room2">
      <inherit name="southdirection" />
    </exit>
  </object>
  <object name="room2">
    <inherit name="editor_room" />
    <beforeenter type="script">
      game.showdescriptiononenter = false
    </beforeenter>
    <enter type="script">
      msg ("Coucou !")
      wait {
        msg ("Glagla !")
      }
      game.showdescriptiononenter = true
      MoveObject (player, room3)
    </enter>
    <exit alias="north" to="room1">
      <inherit name="northdirection" />
    </exit>
    <exit alias="south" to="room3">
      <inherit name="southdirection" />
    </exit>
  </object>
  <object name="room3">
    <inherit name="editor_room" />
    <exit alias="north" to="room2">
      <inherit name="northdirection" />
    </exit>
  </object>

Simple and easy. In room2, no room description, no exit list, no nothing. You can put, say, a table in room2 : it will be hidden as the rest.

I'm all seriousness, what is the point? I don't understand. Could you give an example what that would look like if I played this game? I'm curious. Thanks.

It isn't a game, it's just a test; and you can copy the code and paste it somewhere :-)

My point is this : as I get acquainted with Quest (which for me is nearly ideal but... I'll get back to this in September) it becomes more and more obvious that the internal language, though simple and powerful, is ill-suited to long and/or complex sequences of code that can be necessary for a difficult negotiation between the player and an NPC, for instance. And I thought that a way (among others) to break such sequences into simpler ones would be to use invisible rooms useful only to store code and variables (attributes). An example of the old "structured programming". I know, I could use a large number of functions, but I thought I'd try that, and it works. No offence meant, but as the game gets larger, as the outliner view at the left of the project window cannot be sorted and as you can't move a node from one place to the other, it tends to get messy. And when a script is stored in a given room then you know where it belongs, in every sense of the word.

After all, the basic natural flow of a game is moving from room to room, no?

At the very worst, you're just in front of an unusual idea :-)

P.S : Do test the code, please; I find it amusing.

Ahhh. Totally misinterpreted your original post here! I'm pretty sure I can figure something out that I think fits your request, but it will not be for a while longer yet. I'll work on it some this evening. Thanks for clarifying!

I am still not clear what the point is. Would it not be easier to just point the player object at the other room via a different attribute? If you want to use rooms to track the player status, say, then set the "status" attribute to point to the room, not the "parent" attribute. The problem with moving the player (which really is just setting the player's "parent" attribute) is that there are things going on in the background when you do that.

Thanks to both of you.
XanMag, I'm looking forward to hear from your solution.
Pixie, three points : First, I don't even know what the player's "status" attribute is or should be. Second, can the "things that are going on in the background" be dangerous for the game's reliability? I'm always willing to learn. Third, if they can be dangerous, I've already thought (two ideas per day, imagine!) that I could use isolated rooms (i.e normal rooms but no exits at all either inside or outside) as so-called "libraries of script attributes - and other attributes, of course". I still want to avoid cluttering the outliner with scores of functions. Your opinion?

I don't think you need to do the special stuff for your Objects/Rooms, as you can have Objects/Rooms be 'storage/data' spots not part of the game play, without doing all that special stuff for your scripting. I think this is also wht Pixie is refering to (though, again my example is not the best), as well.

for example (not the best example - but my brain couldn't think of a better example at the moment of writing this post, lol):

<asl version="550">

  <include ref="English.aslx" />
  <include ref="Core.aslx" />

  <game name="xxx">
  </game>

  <object name="room">
    <object name="player">
      <attr name="current_life" type="int">500</attr>
      <attr name="changedcurrent_life" type="script">
        if (player.current_life > data_object.maximum_life) {
          player.current_life = data_object.maximum_life
        }
      </attr>
      <attr name="statusattributes" type="simplestringdictionary">current_life = Life: !</attr>
    </object>
    <object name="increase_life">
      <attr name="drink" type="script">
        player.current_life = player.current_life + 100
      </attr>
      <attr name="displayverbs" type="simplestringlist">drink</attr>
    </object>
  </object>

  <object name="data_object">
    <attr name="maximum_life" type="int">999</attr>
  </object>
  
  <verb>
    <property>drink</property>
    <pattern>drink</pattern>
    <defaultexpression>You can't drink that!</defaultexpression>
  </verb>

</asl>

I'm still learning this stuff myself. I've learned a lot through experimentation, and I have occasionally made a room for code storage. In fact, I did this to the first "game" I made after I went through the tutorial. But I'm not sure what the particular issue you're having is. To keep a storage room out of view of the player, I'd just make a room without any exits, in or out. Alternatively, I'd click on the exit leading into the room and deselect the "visible" check box.

If you wish to permanently store certain variables, you also have the option of storing an attribute to the game itself. I've done this a few times, especially when I frequently wish to refer to string or object lists. It's extremely handy.

As for storing attributes, you may wish looking into creating object types. You can either create some nonsense object type just used to store all the attributes, or you could come up with a more functional one where you might use several of them together repeatedly (such as NPCs).

For me, I've discovered that as nice as a room to store code was, if it was something I would use repeatedly, it was a lot easier to have it on something like the old Notepad program (or something similar) where I could quickly find, copy, and paste what I wanted. But to each his or her own.

just to add on about, Objects / Room Objects, being used as non-game-playing Objects:

you can use them for grouping-organization, epsecially if you work in the GUI~Editor, the below should explain/show what I mean:

<asl version="550">

  <game name="xxx">
  <game>

  <object name="europe">
    <object name="france">
      // exits to germany, U.K., Spain, etc etc etc
      // exits to the asian countries
    </object>
    <object name="germany">
      // exits to france, U.K., Spain, etc etc etc
      // exits to the asian countries
    </object>
    // etc european countries
  </object> 

  <object name="asia">
    <object name="china">
      // exits to japan, Mongolia, Korea, etc etc etc
      // exits to the european countries
    </object>
    <object name="japan">
      // exits to China, Mongolia, Korea, etc etc etc
      // exits to the european countries
    </object>
    // etc asian countries
  </object>

</asl>

see how we can use Objects as 'group holders', so especially if using the GUI~Editor, you can easily find what you want, as it's similar to a folder system with the 'tree of stuff' when using non-playable Objects to group your play-able Objects.

'europe' and 'asia' Objects are NOT playable Objects (the person playing the game does not interact with them at all), whereas 'china', 'japan', 'france', and 'germany' Objects are playable Objects, they're rooms that the person playing the game traverses and interacts with.

we can expand the grouping/organizing further:

<asl version="550">

  <game name="xxx">
  <game>

  <object name="world">
    <object name="europe">
      <object name="france">
        // exits to germany, U.K., Spain, etc etc etc
        // exits to the asian countries
      </object>
      <object name="germany">
        // exits to france, U.K., Spain, etc etc etc
        // exits to the asian countries
      </object>
      // etc european countries
    </object> 
    <object name="asia">
      <object name="china">
        // exits to japan, Mongolia, Korea, etc etc etc
        // exits to the european countries
      </object>
      <object name="japan">
        // exits to China, Mongolia, Korea, etc etc etc
        // exits to the european countries
      </object>
      // etc asian countries
    </object>
  </object>

  <object name="equipment">
    <object name="weapons">
      <object name="swords">
        <object name="katana">
          <attr name="damage" type="int">50</attr>
        </object>
        <object name="claymore">
          <attr name="damage" type="int">50</attr>
        </object>
      </object>
      <object name="axes">
      </object>
    </object>
    <object name="armors">
    </object>
    <object name="clothing">
    </object>
  </object>

  <object name="magic">
    <object name="fire">
      <object name="fireball_spell">
        <attr name="damage" type="int">100</attr>
      </object>
      <object name="inferno_spell">
        <attr name="damage" type="int">75</attr>
      </object>
    </object>
    </object name="water">
    </object>
  </object>

</asl>

Pixie, three points : First, I don't even know what the player's "status" attribute is or should be. Second, can the "things that are going on in the background" be dangerous for the game's reliability? I'm always willing to learn. Third, if they can be dangerous, I've already thought (two ideas per day, imagine!) that I could use isolated rooms (i.e normal rooms but no exits at all either inside or outside) as so-called "libraries of script attributes - and other attributes, of course". I still want to avoid cluttering the outliner with scores of functions. Your opinion?

By default there is no "status" attribute; it is whatever you want it to be (are you adited on-line; it is less obvious that you can just add any attributes you like in the online version). The stuff going on in the background is when the player's location changes. You can see exactly what it is in the "changedparent" script attribute. If you use "status" attribute to track the status, you know there is no changed script.

Using isolated rooms is fine, and I use them as well, to keep rooms in sections together, to hold objects not yet in the game work and other things.

OK with me, thanks to all :-)