*Implement a |cw command for white foreground text. All the other colors have their own command, I don't see why white can't have its own, too.

*Use the same terminology for (in)accessible, (un)available, in(visible) throughout QDK. Is inaccessible the same thing as unavailable? I think it is, but it isn't clear.

*Add a new conditional check: "If player is in room" and then be able to select a room. I found myself at times having to add unnecessary objects to rooms to verify that the player was in the room he/she needed to be in to accomplish something.

*New directional commands: UP and DOWN. These would work just like NORTH, EAST, etc. These commands would make for more logical multi-story structures. You can get around this by using "Go to" exits, but I'd rather just type UP to go up a flight of stairs.

*Every time I tried using a looped sound it only played once.

*Quest needs to supply a space between the object and its suffix. Currently the description will read, "There is a |blamp|xbon the table," with no space between "lamp" and "on the table."

*I'd like to see Quest work with synonyms better. Excluding custom-defined commands, most commands are going to take the form of VERB (e.g., EAST), VERB OBJECT (e.g., TAKE COINS), or VERB OBJECT PREPOSITION OBJECT2 (e.g., GIVE COINS TO BOY, USE COINS ON FOUNTAIN). The problem comes when you have an object that consists of 2 or more words. Let's say you have a STIFF DRINK in your game. You'd like to let the player refer to this just as DRINK, so you set up a synonym redirecting all references of DRINK to STIFF DRINK. The problem is that Quest does not recognize STIFF DRINK as one object; it takes each word individually. So if you type in TAKE STIFF DRINK, Quest will encounter the word DRINK and replace it with STIFF DRINK, altering the command to TAKE STIFF STIFF DRINK. But wait! Now there's a new DRINK in the command line! So that too will be replaced with STIFF DRINK, and ultimately you wind up with a command of TAKE STIFF STIFF STIFF STIFF STIFF STIFF etc. until the game errors out on an overflow. Could Quest instead understand that most commands will be in either a two-part (VERB OBJECT) or a four-part (VERB OBJECT PREPOSITION OBJECT2) structure and deal with interpreting the command that way? I imagine this would be a difficult change, but I feel good synonyms are important to a successful game so that the player doesn't have to hunt around for the precise words.

*Some sort of built-in scoring mechanism? It's not hard to do with variables, but it might be easier if it was directly programmed in.

*I had some problems using nested if-then-else statements not working properly, but unfortunately I can not provide you with specifics anymore and the issue may have been on my end. My solution was to make each new condition its own procedure.

A whole lot of stuff actually, all good points too, but there are some "answers" that can come immediately to mind and some further questions. Forgive much snippage in the quotes here...

quote:

---

*Add a new conditional check: "If player is in room" and then be able to select a room. I found myself at times having to add unnecessary objects to rooms to verify that the player was in the room he/she needed to be in to accomplish something.

---

Not quite sure what you mean by this. You can read the player's current location easily enough with #quest.currentroom# and use that in tests - an example of what you were trying to do but found tricky would help understanding the problem.

quote:

---

*New directional commands: UP and DOWN. These would work just like NORTH, EAST, etc. These commands would make for more logical multi-story structures. You can get around this by using "Go to" exits, but I'd rather just type UP to go up a flight of stairs.

---

Implementing UP/DOWN as directions that can be accessed by typing is really easy, however if they are to be standard Quest Directions they really need Alex to tweak the Quest interface and provide up down buttons alongside the compass rose. I think this is a Good Idea!

quote:

---

*Every time I tried using a looped sound it only played once.

*Quest needs to supply a space between the object and its suffix. Currently the description will read, "There is a |blamp|xbon the table," with no space between "lamp" and "on the table."
[/quote

Known bugs in 3.11, I'm pretty sure 3.12 fixes these.

[quote]
*I'd like to see Quest work with synonyms better...
... but I feel good synonyms are important to a successful game so that the player doesn't have to hunt around for the precise words.

---

No argument for the conclusion from me! BUT the use of synonymns for converting two word named objects to one word is fraught with problems and is not the best way to use Quest at all.

MUCH better idea is to use the ALT tag, Your 'stiff drink' could then be named 'whisky', and give it ALT names of 'drink', 'stiff drink', 'glass of whisky' etc. Quest then resolves the typed input to the name of the object and the synonyms aren't required.

I Use synonymns to make alternative verbs, e.g. "swill; slurp; guzzle = drink". When kept for this purpose they work a lot better.

quote:

---

*Some sort of built-in scoring mechanism? It's not hard to do with variables, but it might be easier if it was directly programmed in.

---

It could be built in to advantage, I'd not argue that :-) It could also be written as a mini-library though which might be a more attractive way to go.

quote:

---

*I had some problems using nested if-then-else statements not working properly, but unfortunately I can not provide you with specifics anymore and the issue may have been on my end. My solution was to make each new condition its own procedure.

---

As my typelib uses nested if-then-elses to a level that scares me silly, I don't think there is a problem with the way these are implemented in Quest. They are however nasty things that are hard to follow the logic of by nature (once you are half a dozen levels in - it gets hairy)... I repeat my plea to Alex for a "Select Case" option!

Look forward to seeing your game bjbest!

LOL... And then have a message box popping up saying "WOOHOO... CW!" : )

"I found myself at times having to add unnecessary objects to rooms to verify that the player was in the room he/she needed to be in to accomplish something."

Wouldn't it just be easier to use the "$quest.currentroom$" (or is it "#quest.currentroom#"?) and check that?
FYI quest.currentroom contains the name of the room the player is currently in.

"*New directional commands: UP and DOWN."

This wouldn't be TOO hard to do ourselves - but you might say the same about north south east and west. I would say this would be a good addition - in fact I thought this was a feature already, having a look at the latest QDK I see it isn't.

"*I'd like to see Quest work with synonyms better."

Erm, I remember this from a long time ago... Doesn't Quest have the ability to replace a synonym only once?

"*Some sort of built-in scoring mechanism?"

The problem with this is that different programers would want different scoring systems. If you do it yourself you can get more out of it and have a more versatile scoring system.

I agree that you should use the alternative (other) names.

"Re: Player in current room check"

I think it would be welcome for beginner programmers. They wouldn't have the guts to go through the help file in search of Default-Quest variables/functions.

"Conditional menu items"

I agree whole-heartedly. I tried to do something like this before and since it wouldn't work haven't bothered with updating the game since.
This is needed for wider use of the menu's IMO.

quote:

---

Al recommended using the ALT tag for object synonyms. Is this the same thing as using the "Other names..." button on the Description tab of the Object Properties window in QDK?

---

Yes it is!

Complete agreement on the menu-choices structure here, the lack of ability to make these conditional makes them a pain to work with for 'conditional conversation' - which would be a very useful way to implement it otherwise.

Because white is normally the background colour, so white text would be invisible. To print white text, set the background colour to something other than white, then set the foreground colour to white (using the "foreground" tag or script command, or from the QDK Game Properties window), then use "|cb" (which now always uses the current foreground colour).

*Use the same terminology for (in)accessible, (un)available, in(visible) throughout QDK. Is inaccessible the same thing as unavailable? I think it is, but it isn't clear.

Inaccessible and unavailable are the same thing - I didn't realise I'd used different words to mean the same thing. I'll go through the documentation to make sure I'm being consistent.

*New directional commands: UP and DOWN.

These are already implemented in the

*Every time I tried using a looped sound it only played once.

I'm sure this has been reported for, but I was not able to reproduce the problem. Could you send me the ASL file and the sound file you're using please?

I repeat my plea to Alex for a "Select Case" option!

It's been on the "to do" list for a while...

*Conditional menu items

I like the idea, but what do people here think would be a good way to implement it? Adding an item to menu would be easy enough, but presumably you'd also want to be able to delete or hide menu items? Rename them? These would require identifying menu item elements - if numbers are used, then the numbering goes awry when things get deleted, so different menu id's could be used - but then you'd have to specify some kind of id for each menu item. When you want to add a menu item, would you want to be able to add it to the middle of a menu? How do you want to specify where in a menu it gets placed - you could say after a particular menu id, but what if that id has been deleted, or other menu items have been added after it? I'd really like to add this feature, but I can't think of a sensible design for it - any suggestions would be appreciated!

"Re: Player in current room check"
I think it would be welcome for beginner programmers. They wouldn't have the guts to go through the help file in search of Default-Quest variables/functions.

quote:

---

*New directional commands: UP and DOWN.

These are already implemented in the

---

quote:

---

but I can't think of a sensible design for it - any suggestions would be appreciated!

---

I think that sufficient functionality could be acheived if we could code this and have it work ;-

quote:

---

define selection <selectionname>
info <Information about the menu>
choice <A choice> (script)
if (x=y) then choice <AnotherChoice> (script).
end define

---

That would allow the menu to vary according to testable conditions - I don't personally see the need for anything more complex.

quote:

---

That would allow the menu to vary according to testable conditions - I don't personally see the need for anything more complex.

---

quote:

---

"Re: Player in current room check"
I think it would be welcome for beginner programmers. They wouldn't have the guts to go through the help file in search of Default-Quest variables/functions.

---