Here is the current list of planned features for Quest 4.0 and QDK 4.0:

Quest 4.0

- MP3 support (already implemented)
- Compiled CAS files can include other files required by the game, e.g. pictures and sounds (already implemented)
- XP themes support (already implemented)
- Numeric variables can now take large values and decimals (already implemented)
- Multiple command history (already implemented)
- Support for files up to 2 billion lines (already implemented)
- “Select case” support
- Pictures within the main Quest window
- More built-in verbs
- Undo
- Type commands directly into the main window, rather than in a bar at the bottom of the screen (option can be set by player)

QDK 4.0
- XP themes support (already implemented)
- Rooms, objects commands and game properties all on the main window, displayed in a treeview
- Script Editor and Script Command Editor on the same window
- Fix copy & paste bugs
- ASL viewer
- A tutorial

I'd be grateful for any comments on the above, or if there are additional features you'd like to see.

I don't have any planned release dates for any alpha or beta versions yet, but as soon as I do I will post them here.

I've got a big list of features I want to implement in Quest and QDK at some point - far too many to go into version 4.0, so some will have to wait for 4.1 or 4.5 or 5.0 or whatever. However I'd still be grateful to hear if there's anything important that you think should definitely go into version 4.0.

The only things that occur to me at the moment are:

* Using the up arrow to recall previous commands like all the other IF systems.

* An option for the game writer to permanently turn the panes off.

* A proper transcript command.

Using the up and down errors for previously entered commands is already implemented in v4.

I'll add an option for an author to disable panes.

How would a proper transcript command differ from the existing ability to output the game text to a file?

Just in the sense that most systems use a SCRIPT ON or SCRIPT OFF command, so they'd be expecting that sort of thing when playing a Quest game.

I'd like to see a skinnable interface - or is this what XP Themes implies? Other than that, the features you've mentioned look great. Which built-in verbs are you implementing?

Perhaps to impose a hierarchy on the development list, you could post your full hopes and dreams feature sheet - then we could all voice our particular gimme's. This seems a sure-fire way to create positive priorities, especially if two or more features prove synergistic.

This is kind of exciting. I'm glad you're moving forward with Quest!

XP Themes pretty much just means you get the nicer rounded buttons rather than the Win2000-style square ones. If you use something like WindowBlinds then Quest should fit in with that though.

Okay, here's a few things:

. 2-dimensional arrays
. Option to display all menus (including disambiguation) as text in main window instead of GUI popups
. Error messages that indicate file origin (I have 29 qlb's at the moment, and while I can generally narrow errors down to two or three origins, the process is tedious. Albeit better than clawing through one massive asl file.)

The error messages could contain the line number or, if that's not possible, then a moderate snippet of contiguous code.

Hi Alex

Interesting list of improvements for V4, mostly positive reaction in my book.

'More built in verbs' is the thing I (personally - I appreciate I'm a minority!) am not thrilled about. Do you have a list yet of which verbs are going to be hard coded into Quest?

Call me a pessimist if you will, but I think of every 'built-in' verb as simply another one I'm going to have to override and replace at some point - and because it's hard coded I can't simply leave it out if I don't want it/ like the way it works, I'm going to HAVE to deal with it. Also the more verbs are built in, the more interdependent they are likely to be and the more of a pain in the @$$ they will be to override.

Al

(who feels a

command <#anything#> do <parse_it_all_yourself>

coming on...)

Oooo, and with a select case going in - you'd be able to do;
for #command# in {
open #box#) dfjg
close #box#) sdfh
hit #box#) sdufh
}

(or something similar).

Overcat - what do you mean errors containing the origin?
You mean if you had a typo, and missed out a closing bracket or something?
In all cases, it should be apparrent where the errors come from - either the code you're just editing or the part of the script which is currently being executed.
IMO, if you can't tell where an error is coming from, you're either doing TOO much in one coding session, or not having enough output.

I think more built in verbs is a great idea. Madrbit disagrees because it means it'll be harder to override them, but when was the last time anyone actually played a Quest game that had covered as many verbs as any game written with another system? Every time I type a command like OPEN or TALK or TURN or WATCH and Quest responds that it doesn't understand what I'm talking about, I start wondering why I'm even playing the game.

Overcat - what do you mean errors containing the origin?
You mean if you had a typo, and missed out a closing bracket or something?
In all cases, it should be apparrent where the errors come from - either the code you're just editing or the part of the script which is currently being executed.
IMO, if you can't tell where an error is coming from, you're either doing TOO much in one coding session, or not having enough output.

Heh. Too much coding in one session. I like to program a new subsystem in its entirety. In all honesty, it's not that much code, it's just that I've got it spread out amongst multiple qlb's. For a single subsystem I may have to code commands in the GAME_Commands.qlb, a function in GAME_Functions.qlb, a procedure or two in GAME_Procedures.qlb, and assign various properties and actions to a few object types in GAME_Types.qlb. One missing bracket or variable sign somewhere is tedious to find. (By tedious, I mean 60-90 seconds.) But - compound that by writing several subsystems in one afternoon. The annoyometer rises, and you think, "If I miss one more damn curly brace, I'm going to...insert humorous action here." And it's not just the curly brace. I think I've exhausted Quest's library of error messages several times over. That said, it is possible to achieve the elusive glory: the perfect, error-less half-hour round of code.

Approximation of what I mean by 'errors containing origin':

Error: Missing }
In: GAME_Functions.qlb

That way, I don't have to check every qlb I've worked on.

Now if I'm the only one who works this way, perhaps this is not such a high priority item to be implementing.

I personally use notepad++ in windows (or dev-c++) ... or in linux I use kate, or one of those varients.
All of which add in an ending curly brace for me - which is nice.

I usually tend to - when using vi or notepad or posting code - put and ending brace AS-SOON as I type an opening one - and just hiot a couple of returns so there's space. That way I know when I'm missing stuff or not.

I thought it already came up with errors like that - and I know that when you have the quest debug output sent to a file - it says "loading library ..." and you might be able to spot it that way.

What I'd like is in stead of saving values to a userid in questnet games, you can save it to a name. This'd make my life ALOT easier, as when you log out and some-one logs in they can get your values (by values I mean strings and variables).

I'd have to voice the same concern as Madbrit over the built in commands. This was always something that irritated me due to the inability to override them.

Also for elexxorine, if you have a login system assumably assigning values to player%userid% objects properties, it's fairly simple to just...

disconnect {
      property <player%userid%; active=false>
      property <player%userid%; login=null>
      property <player%userid%; password=null>
      etc, etc.
}

Beyond that, I'd just like to see the few Questnet bugs ironed out like cloning objects/rooms not keeping their values, and it's a dream, but a more streamlined way of running functions and procedures within the context of objects, specifically player objects, as it isn't easy to do.

oh P.S. A better defined way of passing dynamic parameters to functions and recalling them for multiplayer. I think the example in the help file is...

$myparam(potato, 3)$ couting out "potato potato potato" from potato referenced as $parameter(1)$ and 3 as $parameter(2)$ but I've never gotten any iteration of this to work in multiplayer games.

Here's a list of some stuff I'd like to see in future versions of Quest/QDK:

* Some sort of "Container" setting for objects to make it easy to implement a container you can put things in. Further to this, it would be cool to be able to set object's sizes and/or weights to limit what you can carry and put in containers.

* A system where you can run a text entry window. So you could set up a scenario where the player types "Enter password" and it brings up a window where they can type in the password. The entry can check the text for what is entered, and if it matches the password, the door will open (or whatever), otherwise print a failed message. Or even just get the player to enter their name.

* Some sort of turn-based system, whereby each entry typed is a "turn". Then you could set things to happen after a certain number of turns, or Every (x) turns, and last for (x) number of turns. This could facilitate the inclusion of non-player-related world events such as cars driving past every 3 turns or something - would make a world more believable.

* Some sort of Conversation Tree setup so that you could easily make complex script-based conversations when you speak to a character.

* The option, in Quest, to turn on word selecting - whereby clicking any word in the main window will "type" that word in the entry screen. So if the player sees in the window. "There is a cat here. It looks like it wants a stroke.", you can click the word stroke and then the word cat, and hit Enter, and it'll run the command "Stroke Cat".

* Some sort of (optional) automap, whereby rooms and room links are represented on a self-making map of boxes and arrows, with the option to turn off the map, include a custom graphic instead, or remove certain rooms from the map.

* The option to give objects custom movement behaviour, so you can set a character to walk from room to room every (x) turns or every (x) seconds or something

* Random function - so the author can have a different event happen based on a random number.

* The ability to select actions based on the Inventory, such as "Make contents of player inventory accessible/inaccessable"

* The ability to set multiple inventories - this way one could make an adventure with multiple player characters

* A (command) all function, which will affect everything, so the player can say "Drop All" and they will drop everything droppable in their inventory

* A warning in QDK when you give two items the same alias. At the moment, it's a bit of a crappy system, when you say "Look at Key" for example, and it says "Which key did you mean?" If there was a warning in QDK, the author could think "Hmm, maybe I could change the second key to be a keycard or a lockpick instead, to add more variety and avoid ambiguity".

* Add custom commands to the menus in the Panels - so if the author sets up the ability to "Eat" something, you can right click that item and select Eat as an option.

* Set the intro text to only show at the start of the game, and not when restoring a save, by default, although this could be changeable

* Set an option to display one object in more than one room, so you could have a long fence that appears in all three sections of a Road. Or you could make an (invisible but interactive) object in all rooms called "Sky" or similar.

* Inbuilt lock and key functions, so one can set up locked doors and containers just by linking a key object to a locked object.

* A wildcard feature, so the author can set up an alias for example of "* car". Then the player would get the same response if they typed "Look at big car", "Look at big red car", "Look at my car" etc.

* The ability to generate a list of commands required by the game to reach each ending of the game. So it would output:

Player types:
Open Door
North
Take Gun
Shoot Bad Guy
West
South
Press Button
Player Wins.

That way one could scan for "unwinnable" situations more easily.

* An Undo function in Quest, so you can easily go back if you make a mistake.

Nicked;

You can already set up containers using MaDbRiT's library - although I'm not sure how easy it'd be to use... I thought he had some QDK interfaces..

You can already have a "text-entry" window, exactly as you typed out. Asking the user for input and then matching what is entered against another variable. - Or get the player to enter their name.

Some sort of turn based system? That makes no sense.
You can already implement what you drescribed (for instance events happening after you've entered a command/etc).
Turn based would have your player doing one 'turn', and then the game having a turn?
- I don't know if this already exists, but a string variable which contains if the command the user typed was successful or not would be helpful.
So say the user types "klhsdfljasf", an afterturn script wouldn't run - because the success variable/flag is false, while a "look" command would let the afterturn script run... I'm not sure how Quest currently works this out - or if there is such a built-in variable.

A conversation tree might be helpful.. Although I wouldn't have the slightest idea of how it'd be implemented.

I don't like the word-selecting bit... I suppose it'd help out the disabled, but you'd be turning it into a point&click system.

Automap - would be nice, but how can you turn the whole " 1 - 2 - 3 - 1 " loop thing into a map? Say right into 2, right into 3, right into 1, etc.
There might be some simple SQL-type plugin for VB - dunno.
Would be kinda nice. I opt that rooms are set in place the first time you come across them... That does mean 2 people playing the same game can create 2 different maps, but it'll be easier for the player to see the place.

You can already have objects 'move about', although it takes a tiny bit of coding... How do you expect to restrict the objects movement? - You may not want a cat to be able to enter a dog-house, etc.

A random function already exists.

The ability to select actions based on inventory ALSO exists.
- Also the ability to make contents available/unavailable currently exists.

Multiple inventories - you just move them all to specific rooms. This exists.

Drop 'all' etc, would be nice. Not sure if it exists or not.
Should be easy enough to write a little library for.

If you're creating two keys, with no ambiguity, then surely you're creating a game without really caring about descriptions!?

By "into the panels" I guess you mean, into the right click menu, when you select an object.
That'd be nice I guess.

I agree that the startup text should be only at first-game-launch by default, and there should be a loadscript procedure run when games are loaded..
But you can still do this already in Quest.

Having one object through more than one room.. In your example of 'fence', what if you wanted to destroy one part of it?
Why not just clone the object into those three rooms?
And why have a sky 'object' ?

The lock and key functions idea is OK - but I can do that with a library and a QDK extension... Which I might make..

A wildcard feature? That already exists, but you're thinking about it all wrong. if you put as the description as "it's a big red car" and call it "big red car"... then you *should* put in the "alt" bit of the object; "car,big red car, red car, big car" ... my car won't work because you haven't said it's your car..

The ability to generate a list of commands?
Well, wouldn't you - as the game programmer - know that?
How would the game know that you'd have to take the gun and shoot the bad guy? How would it know not to go east instead of opening the door?

I'd like an extra property for rooms:
#room:places#. Which would contain the places available for that room - while exits contains north/east/etc.

I think by "turns", Nicked means in the sense that you can have timed events which occur after a certain amount of turns in the game. Say you want an NPC to suddenly show up and say something when the player has been playing for X amount of time, you'd be able to do this via turns.

8) I am in agreement that having custom settings on the right click button would be most frothy.

Most of your requests/suggestions, nicked, are doable in code. I surmise that you want all of this built into QDK? Well, if this doesn't happen for you:

1) Read the manual, print a copy, keep it by you
2) Start learning to program in a text editor
3) Build a library

This can be a very satisfying endeavour. Alternately...

1) Beg someone to build a customized library for you
2) There is no 2

I think by "turns", Nicked means in the sense that you can have timed events which occur after a certain amount of turns in the game. Say you want an NPC to suddenly show up and say something when the player has been playing for X amount of time, you'd be able to do this via turns.

You may already be aware, and it might not have been your point, but for clarification this is easily accomplished with minimal coding.

So say the user types "klhsdfljasf", an afterturn script wouldn't run - because the success variable/flag is false, while a "look" command would let the afterturn script run...

I like that. I don't think it exists.

More helpful error messages to indicate where problems are: Quest 4.0 checks individual "define" blocks for missing braces separately, and will tell you which block any missing braces are in.

More built in verbs: I guess there has to be a compromise between a system that is easy for most people to use, and a system that is easy for a few people to customise. It makes more sense to cater for the former group. However, overriding these will be just like it is now, so if you want to define your own "eat" command, say, then you can do so. There will be built-in default messages for objects which can't be (e.g.) eaten, which can again be set by the game author in the same way you can currently override the standard player error messages.

Containers: I'm working out the best way for me to implement this. I will post a separate thread shortly.


Tr0n has covered some of the things Nicked raised already. To address the others:

Conversation Tree: one for a future version I think, but I'll add it to the to-do list.

Word selecting: possibly

Automapping: Something I've thought about, but difficult to implement - anybody any ideas how this should work?

Drop all: command <drop all> for each object in inventory move <#quest.thing#; #quest.currentroom#>
should do the trick

Add custom things to menus: On the to-do list for a future version.

No intro text/startscript when loading game from a save file: Yes I agree this could be handled better and will look into it.

Set an option to display one object in more than one room, so you could have a long fence that appears in all three sections of a Road: Interesting idea, I'll have a think about it.

Lock and key: Yes this could be handled more neatly.

The ability to generate a list of commands required by the game to reach each ending of the game: I have a hunch that if I could do this I would deserve a Nobel Prize or something similar!

Undo: already on the list

Automapping: Something I've thought about, but difficult to implement - anybody any ideas how this should work?

Adrift has an automapping feature but I don't know exactly how it works.

The ability to generate a list of commands required by the game to reach each ending of the game: I have a hunch that if I could do this I would deserve a Nobel Prize or something similar!

This is a feature of Inform 7. Damn good feature as well. As Inform 7 is open source, it might be possible to get a look at the source code and see how a similar feature could be included in Quest.

i'm glad for the undo and especially for the tutorial

Inform 7 must use some form of the Chess branching feature... It goes down one path long enough to make a decision about where it is.

Either that or inform can award 'points' to the player, and that would also help a branching system chieve 'maximum points'.
I still think this is really lazy.

I think I commented on auto-mapping briefly;
I think the start-off room should be set in a central location, and much like MS-access (the databasing thing) you link together boxes.
The boxes can have the Room alias in, and have half-filled out exits.
Once you take an exit, the next room pops in there, and is set-in-place.

So:

   |
-[start]-

goes to:

   |
-[start]--[two]
            |

goes to:

   |
-[start]--[two]
            |
        -[start]-

Now I know the room has two locations (start), BUT it saves having to try and code difficult room arrangements.
You could always put in a little algorythm later on to make a nicer line linking back to the start room, maybe getting something like:

     |---|
-[start]-|-[two]
         |---|

All boxes could be evenly spaced - with the lines going inbetween these spaces - meaning lines are seperated from boxes and don't go through each other.

You getting the idea?

Also, a drop all like that would also drop un-droppable items.
Is there a way we can kick off the drop object action?

All the other suggestions you've commented on are super Alex!

More helpful error messages to indicate where problems are: Quest 4.0 checks individual "define" blocks for missing braces separately, and will tell you which block any missing braces are in.

Perfect.

More built in verbs: I guess there has to be a compromise between a system that is easy for most people to use, and a system that is easy for a few people to customise

.

I was thinking about this myself.

Option A: More built-in commands exist
QDK users: Awesome
Coders: "I can code around it."

Option B: No more built-in commands
QDK users: Sh*t out of luck.
Coders: "I can code around it."

The choice is obvious.

Automapping: Something I've thought about, but difficult to implement - anybody any ideas how this should work?

I wonder how the Z-axis is represented? X, Y, done. Z? Layered Maps? Numerical designations for height? Color-coding?

The ability to generate a list of commands required by the game to reach each ending of the game: I have a hunch that if I could do this I would deserve a Nobel Prize or something similar!

Check if the ASL uses any form of randomness, like the random number function. If so, discovering that list of game-winning commands becomes more and more remote each time the random process fires. If NO probability exists in the game, then I surmise the generation of a game-winning commands list is definitely doable. Note that this list would be a set of irreducible, sequential commands required to win the game.

Set an option to display one object in more than one room, so you could have a long fence that appears in all three sections of a Road: Interesting idea, I'll have a think about it.

A fun coding session, but would be handy in QDK, along with all of the other things already code-able.

Oooo, I just thought of something which would be nice, although definately a frill.

The ability to order the list of items in the inventory.
Alphabetical would be a nice choice - but also being able to add an index number in some way, and sorting by that.
... As I said, definately a frill.

Here's something off the top of my head.
Currently, you have a window on the right side that shows all available objects in the current room.
If a game author were to be clever enough to change the type of the object from the word "object" for a couch to, say, "large furniture" for that couch.... the window will not adjust wide enough to display the full custom object type.
Know what I mean?

It's just something I noticed while making a lot of custom adjustments.

Inform doesn't know how to win the games, but it can play the game for you with a pre-set (by you) list of commands, basically an auto-typer to help debugging.

Can we have a feature that will allow us to ride animals and be carried by other characters?

Riding animals would be easy to code for already.

Lucy wrote:Can we have a feature that will allow us to ride animals and be carried by other characters?

...and to be able to carry animals that are carrying people while you're riding an animal.
hee hee

As of this minute, Tr0n, witch wyzwurd and I have made a few suggestions to your question in the other forum if you wanna take a look.

Re auto solving of Quests

It would take a very advanced system to solve problems the following problem (which could easily occure in a quest):-
clue 'press the button that is the colour of yellow and blue mixed'
soln 'press green button'
as the solving system would not know where to find the clue (it does not know that blue & yellow mixed is green, and so can not make the connection bwtn the clue and the soln)
or like
clue 'enter the name of the cat you saw to as the password'
soln 'frizzels' (the name of the cat as given by the owner)
as the solving system would have to understand that people own and name cats

so no auto solving systemc could be provide solns to all quest, but the running of pre-defined cmds throught Quest would be very usefull

Another idea;
Lists of available commands.

I do remember starting off a small project which would list out the available commands which you could execute in each room.

This would take global commands, and room commands, and match them with meanings, displaying them in a list similar to:
Global Commands;
go {n/s/e/w/ne/nw/se/sw/up/down/in/out/place} - go in a specific direction.
examine #object# - examines an object. You may also use; look/l/x/exa/inspect #object# .
inventory - lists objects you are carrying. You may also use; inv/i .
open #object# - open a specific object.
throw #object1# at #object2# - throw an object in your inventory at another object.
throw #object# #direction# - throw an object in your inventory in a direction.
Room Commands;
move #object# - move #object# from it's current location.
hit #object1# with #object2# - hit an object using a second object.

I just think it would be useful to have something similar in Quest 4.

Auto Solving:

I was thinking of it in terms of registering variables and tracking their changes. If we know the 'win' variable will be set to true if 'event' or 'events' occur, let's back track all the way to the beginning to see the shortest route to where the game starts. IE, back to the point where the values of the registered variables are re-initialized. This is why I thought it may be possible to produce irreducible sets of solutions.

Win = true when EventA = 6 and EventB = Susie
EventA = 6 when some action/group of actions is done 56 times
B = Susie when PC goes here

Just a thought. Who knows.

Inform 7 has a feature where it automates checking an existing script, but it can't generate a winning path on its own. (Generating such a script is definitely exponential time, and probably far, far, harder than that.)

Working from the opening move, like in chess, generating a script such as this would be very difficult indeed. In this case I can foresee the exponential increase in possible moves and winning situations. But in chess we do not know the arrangement of the pieces at the end of the match. In a text game, we may already know the arrangement of variables for a win.

Winning State = varA;varB;varC;varD, or
Winning State = NumberOfPeopleLeft; Day; PlayerLocation; NumberOfWidgetsInInventory, or
Winning State = 1;79;Helsinki;4

Then we find out which commands alter these variables. We calculate the orders of input that would result in the variables varA, varB, varC, and varD equalling 1, 79, Helsinki, and 4 respectively. We take the shortest order of input, or command set, and use that as our ideal solution.

I may be barking up the wrong tree. Please let me know. I have a feeling I'm missing something...

Silly example:

1) If the player types "create widget n", where n is an integer, and the player is holding widgets 1, 2, ... (n-1), then the command will succeed, the player will get widget n, and lose widgets 1, 2, ... (n-1).

(So "create widget 1" will work at any time, "create widget 2" will work if the player has widget 1, and so on.)

2) If at any time, the player is holding widget 20, he will win.

Alternately, try working a game with multiple resource conservation puzzles.

1. Similar to ASL Viewer - In the Script Editor, it would be nice to have an ASL button so the relevant section of code could pop up for quick code changes (instead of having to search through code to find the right section). This would really save time on fixing something that's embedded down in a few conditional layers or copying a block of code.

2. OUT throws this nasty error by default:

/--- LDF-ERROR: Unspecified: error:detaultout ---/

3. The previously discussed RETURN bug. http://www.axeuk.com/phpBB2/viewtopic.php?t=376

4. QDK Library bug: Using a type field at the top of a QDK tab autofills blank text fields in library (including other tabs).

Being that no one has been able to solve my problem in the other forum, I'd like to see the ability to change the background color of the Help Menu when the menu is created by the programmer.

Also, my game prints words out letter by letter using the "pause" feature, but the cursor trails the automatic printing of the letters; I'd like to see this feature changed so the cursor is eliminated.

Next, the semicolon must be allowed for proper grammar in the game-window.

-Witch

Lucy wrote:Can we have a feature that will allow us to ride animals and be carried by other characters?

I believe a "follow" script once existed for multiplayer games. This I guess could be used to simulate the "carrying" of other players.

Actually, I would like ";" to be included in the $symbol()$ function.. Maybe "sc"?

I know that the game won't allow you (as a player) to enter that as part of a command, as it screws up.

Eliminate the dependancy of the Help Box background color upon the Window Appearance color. This diminishes the option to use yellow text, since yellow is faint against a white background.


-Witch

Just a question on the Select Case feature. I assume this is going to work the same way it does in Visual Basic?

For those who are unfamiliar with how Select Cases in VB works, here's a short explination.

In the code a simple Select Case section would look like this:

    ' Check rank level
        Select Case GetPlayerRank(index)
            Case 0
                Title = "Newby"
            Case 1
                Title = "Novice"
            Case 2
                Title = "Intermediate"
            Case 3
                Title = "Advanced"
            Case 4
                Title = "Expert"
        End Select

This is obviously not a tested or used Select Case function lol, but I think it's almost right. I think it basically works similar to Conditionals. GetPlayerRank(index) would get the value of the players Rank. (there would be other sub-routines and variables/constants involved in this process). And so the program reads through each Case # line until it finds a match, if it finds a match, it performs the procedure which is written under the Case # (where # is the number). In this case, setting the value of the string variable 'Title'.

There can be more complex Select Case procedures.

However, if this is implemented into ASL, what would be the major benefit of it's purpose? Since you can pretty much perform a similar routine by using the Conditionals in ASL. I guess for one it's a lot less scripting, than using full conditionals.

That should have an "end" or some form of "exit" ('break' in VB IIRC) word to break out the case-list, while not having it should move through the case's.
:

select case str_ONE
    case Default:
        ' execute default stuff
    case ONE:
        ' execute one stuff
        if ( str_ONE = "ONE" ) then break
    case TWO:
        ' exec two stuff
        if ( str_ONE = "TWO" ) then break
end select

This way, it goes through all the possibilities by default - only executing one or two if they are desired...
I hope this sort of "break" feature is used in ASL.

Well, after it finds the match in one of the cases, you can put whatever you like after it.

I assume what you mean here is even if it's found the match, it would still continue to look over the rest of the Select Case procedure for other matches, AFTER it's performed the function of the previously matched case.

That's how select cases work... At least, that's how I remember them working in VB.
I *know* they work this way in C++.. And remember having to put break or something into my VB programs years ago.

I've been thinking... If a player pops up the option box for objects that lists "look" "examine" "take" and "speak" then in a way it forces the game developer to have to satisfy those options. How about instead of the same drop-down menu displaying all options, the only options listed, so the only ones the player can choose from, are the ones the game developer defines. And how about allowing the game developer to add some options to the drop-down menus (such as read...).

-Witch

Hi all

As someone who's been pleading for a "select case" option for ages, I see the advantage as being neater, easier reading code and less of it. Having to write a whole forest of nested if-then-else statements for complex decision making could be tidied up enormously with a judiciously implemented "select-case" construct.

It's not that you can't do the same thing with if-then-else as provided by Quest, more that you could do it more neatly and in a less error prone way. Anyone who's written complicated conditions in Quest knows what a pain it is to keep track of all those infernal if-then-else braces!

Al (MaDbRiT)

What I want is to be able to have '.'s in strings. Also to completely overide built-in stuff, for examble, in my game I have a say command, in the script it says <say #words#; /say #words#>, now theoretically both should work at the moment, but upon tying 'say whatever', it does the built in script, not mine! And it pisses me off!

elexxorine wrote:What I want is to be able to have '.'s in strings. Also to completely overide built-in stuff, for examble, in my game I have a say command, in the script it says <say #words#; /say #words#>, now theoretically both should work at the moment, but upon tying 'say whatever', it does the built in script, not mine! And it pisses me off!

Is there no way to check if the player has typed "say #words#"? is so, do script?

In reply to Al's post, this is what I thought the purpose was, I was just wondering if there was any other reason.

No, I have the command 'say #words#' with the other versions of the command, as the can difine multiple commands that do the same thing in the one set of define brackets. Anyway you saw if you didn't type the '/' it would oct differently... So what am I doing wrong, if anything, which is unlikely, or will this be fixed in the next version?

It has been suggested in the passed, being able to overwrite built-in commands. Hopefully a planned feature for 4.0

A couple more features I'd like to see:

1. Ability to rearrange the order of rooms in QDK's room list.
2. Would like to access object properties with dynamic property names:

if property <#object#;#property#> then msg <OK>
OR
msg <#(object):(property)#>

2. Would like to access object properties with dynamic property names:

You can:
msg <$objectproperty(#object#;#property#)$>

objectproperty is a built-in quest function, which was the first (and arguably is still the best) way to get object properties.

Indeed. I'll have to find the last place I had this problem and see what I used.

Arbutus wrote:A couple more features I'd like to see:
1. Ability to rearrange the order of rooms in QDK's room list.

Aye! Also for objects in a room and the if-commands of conditionals.

-Witch

How about a specification for the language?

What do you mean by specification?

A specification is a description of exactly what is legal Quest, and exactly how that code will be interpreted.

For example, is "A or B and C" evaluated as "(A or B) and C" (bind ors first, or bind left to right), or is it evaluated as "A or (B and C)" (bind ands first, or bind right to left)?

Does it split before or after evaluating variables? (That is, suppose string variable alpha has contents <beta ; gamma>, and the author does "set string <#alpha#>" or "property <wolf; #alpha#>". If it splits first, then the first code will give an error, and the second will give the wolf a property "beta ; gamma". If it evaluates first, then the first will create a string with name "beta" and contents "gamma"; the second will give the wolf two properties, "beta" and "gamma".)

I think the second behaviour will occur.

I don't plan to write a specification as I don't really think it will help that much - the ASL reference should tell you everything you need to know. But please let me know if there's anything else that needs clarification.

I asked two different questions.

Why not try out these things and tell us what happens, that's half the fun of learning, is finding stuff out yourself.

You can't set a string to beta;gamma at run-time (not as far as I'm aware). Since during run-time, the ; is seen and so anything after/before is removed.. I think it's after.

During writing the game, you can assign a string I think.. But still, trying to assign that will get the rest ignored.

If Quest could assign #alpha# to the object - then it would give the object two properties - since ; is taken to split properties up.

Tr0n wrote:You can't set a string to beta;gamma at run-time (not as far as I'm aware). Since during run-time, the ; is seen and so anything after/before is removed.. I think it's after.

Two different ways to do it:

command <set multi> {
	set string <alpha; beta; gamma>
	msg <alpha == '#alpha#'>
	enter <alpha>
	msg <alpha == '#alpha#'>
}

> set multi
alpha == 'beta; gamma'
alpha == 'delta ; echo'

Quite correct..
Another is "command <doo #var#> msg <#var#>".

Erm, Alex..

What about destruction of objects/rooms?

I know cloning, or creating rooms/objects are fine.. But could we have destruction of objects?

What's wrong with hiding them?

Yeah, I suppose we don't need destruction of objects.
Just requires different code if you want to check if the object exists in the game.

but i really want destruction of objects pleeeeease

Put a property on them when they're destroyed then when you try to interact act with them test for that property, hiding is a good example of this, because once hidden the object is destroyed from the point of the player...

once hidden the object is destroyed from the point of the player

Not really any good if you want to quickly clone an object - to say copy properties - and then destroy the object after a little while...

You'd have to either copy each property one by one (which you can only do if you have an array of all the properties), or keep cloning until you end up with a bajillion objects, each named "object[%num%]".

I just think removing the object would be a nice simple command.

me too, and wouldn't hidden objects take up a lot of space on a multiplayer server. I mean, if you can get a large player base, all of which drink the same type of beer at the local tavern, then you would end up with a whole bunch of unuseable objects just takeing up valuable space and slowing down the server.

A way around that is to have a storage room, and when one is needed check for if any are lying in there, if so just move them out, otherwise clone one from the first made...

Again - not really ideal if you want to copy the properties from another object without having to go through them all.

Overall coding - if you clone objects - would be made easier because you could destroy objects.
Even normal coding would be made easier, because you could destroy an object if the player uses it - instead of moving it to a certain place, or hiding it.

To destroy or not to destroy objects. The options are almost even. I use a storage room like Elexxorine mentioned and code to determine re-use or cloning a new object. It works fine and copies all the properties automatically. Destroying objects would be good for keeping the memory usage slim (but most likely by a negligible amount). When you go to clone a new object it would take a different approach to give it a unique name (eg. clone002) since the numbers would be inconsecutive. Overall, for completeness, it would be a neat option.