As suggested, I looked once again at Inform as well as other IF source software. NONE of them have the power and capabilies of TADS. So, I’ve decided to stubbornly stick with it.
You guys are stuck with me. I sincerely hope that I’ll continue to get your help when required. And, I will continue to study all of the TADS manuals for answers to what I need.
RonG
What does TADS do that Quest can’t these days? Just wondering - I’m not looking to start a language war or convince you you’ve made the wrong choice 
I’m not trying to start a war either. I haven’t really looked closely at quest. Thanks for the suggestion.
RonG
BTW: I will give quest a look.
I gave Quest a try but couldn’t get excited about it. One of the biggest drawbacks was having to use online documentation. I am still excited about TADS and I think it’s the best. I now have about 1950 lines of source code in my story and still work on it many hours a day. It looks like you guys are stuck with me for awhile longer. I will continue to learn TADS and to hunt through the TADS manuals; because I’m a headstrong type of person.
Best regards to all of you patient people who have put up with me,
RonG
TADS has the TADS programing language. It also has the adv3 library. Have you looked at them? :mrgreen:
So the shorts answer is: dozens of dozens of stuff.
Quest has the ASLX programming language and the Core library, so that doesn’t really answer the question
I was curious, so I had a quick look. It appears ASLX is a markup language. It’s not really suitable for programming, is it? By which I mean, does it support if/else blocks with boolean tests? Does it support do/while or for loops? Does it support function calls with argument passing? Does it support lists and arrays? Does it support class inheritance?
For starters.
I didn’t see any of that, but maybe I’m missing something on the web page.
A few things TADS is known for below. (Maybe Quest 5 has added them by now, not sure.)
Disambiguation is controllable. For example, when the user tries to OPEN THE BOX and there are multiple boxes, the programmer can specify for which boxes OPEN makes more sense, in which case the parser will not ask “which box do you mean…”
Implied actions are also fully controllable. The code can specify preconditions that must be met for an action to be possible. If a precondition is not met, the parser will try to satisfy that precondition automatically. For example, for DRILL HOLE IN WALL to be possible, you can create a precondition that specifies that the drill must be plugged in. That means that if the player tries to drill a hole with an unplugged drill, the parser will try to automatically plug the drill in a wall socket. The programmer can however limit this, as to not allow the parser to solve puzzles on its own.
Parameterized messages. You can switch between past/present tense, first/second/third person at will without needing multiple versions of your prose. You write: “Opening {the dobj/him} reveal{s|ed} a ham sandwitch” and the system generates the correct message.
Operator overloading. See C++. In short, you can define what operators (=, +, *, etc) do for your objects. Imagine having a shelf of books and you can refer to the 4th book in it with “bookshelf[4]”.
Multi-methods. This allows calling specific implementations of methods based on the types of multiple objects, not just the object the method is called on.
Dynamic object creation. You can create new objects after the game is already running. Imagine a food dispenser that when used creates new food items. (If you know C or C++, that’s the equivalent to C’s “malloc()” and C++'s “new”.) A garbage collector also takes care of cleaning up when you don’t need those objects anymore.
Exception handling. This allows you to separate code that handles errors from the rest of the code.
Anonymous functions and reflection.
I’m getting tired, I’ll stop here 
Edit:
To be fair though, Quest does some things TADS doesn’t. For example video support.
TADS has video support through WebUI, right? I haven’t tried it but I don’t see why it wouldn’t work.
Yes to all of the above. There’s an XML format to define the objects in the game, but within that there’s a scripting language which supports all the usual things you’d expect.
It’s interesting that that wasn’t clear - I wonder what I need to do to make the capabilities more obvious?
There’s a full reference guide to all the functions, script commands etc. on the wiki at quest5.net
You could do this in Quest with a little bit of work - the parser is in CoreParser.aslx which can be modified as required. However, a lot of Quest games are played via object hyperlinks - you can click or tap the required box in the room description, then select “open” from the list that appears. So this kind of functionality is perhaps less necessary in a Quest game than it would be a for a system that is keyboard-only.
Any Quest verb or command triggers a script, so in this case you’d probably set up this up manually with a couple of lines - not sure if/how this would be different in practice to letting the parser handle it earlier.
In what situations would this be used? Not sure I understand why a game would change tense? Also what about non-English games?
Interesting. Quest is unlikely to support this, because it needs to be able to convert games into JavaScript, which doesn’t support operator overloading (which makes me think we can probably get by without it)
Could you give an example?
At last, I can say this is something that Quest already supports 
You can throw exceptions but can’t catch them yet - though thinking about it, that would be quite an easy feature to add.
Quest supports delegates, and you can also set a variable or attribute to a script, so you can pass scripts around. There’s no real reflection yet but I can imagine this would be another feature that wouldn’t be too difficult to add basic support for if there was demand - could easily add a function that returned a list of attributes of an object (you can already get attribute values by string).
Phew, me too
To tell a story in a unique way or to have an interactive flashback scene; I’m sure there are other examples.
My current WIP starts off in past tense, first person and then changes to present tense, possibly second person. Very easy to do in T3.
As for what system is better, that’s like debating what religion is better. It can only end in a stalemate, and quite possibly, with some bloodshed.
– Mike
Okay, I’m happy to stand corrected. It appears Quest is a great deal more powerful than it appears on the surface.
To answer your question, I think writing a manual might be a good step to consider. A hyperlinked wiki is just a horrible learning tool unless one already knows what one wants to look up. Following the trail of breadcrumbs I found the link to Script Commands and clicked through to “if”. This gave me a bare syntax prototype with NO explanation, much less examples. And the prototype contains the symbolic term “script.” So where’s the link explaining what a script is? It’s not on the Script Commands page, and it’s not back on the main page either. I’m not going to hunt through 50 links looking for it … but apparently that’s what your users will need to do.
Sorry to be so blunt, but I’m kind of a hard-ass on the subject of good documentation (as the I7 folks will tell you – I wrote an Inform 7 Handbook because I disliked the built-in Writing With Inform rather intensely, and my suggestions for how to improve it were ignored by the development team).
BTW, I tend to agree with your initial suggestion to Ron, which is where this thread started. I suspect he would be happier with Quest than with T3. On the other hand, T3 does have extensive, searchable documentation…
Definitely! The differences between systems are interesting, but as with web browsers or smartphones it’s often difficult to discuss how they compare without descending into unwinnable arguments, so I’m trying to avoid that here.
Absolutely, I wouldn’t recommend the reference guide to somebody starting out. But on the same wiki is the tutorial - quest5.net/wiki/Tutorial - which takes you through building a Quest game for the first time, using the visual editor. It still needs to be updated for the new web version of Quest but the principles are the same and the editor layout is very similar.
Fair enough. There’s a section on scripts (using the visual editor) there.
I’m not sure Quest would be right for me. For one thing, too much mouse use is bad for my wrists. Typing is better. But now that I know more about it, I won’t be shy about recommending it to newcomers.
You can find info about it here:
en.wikipedia.org/wiki/Multiple_dispatch
tads.org/t3doc/doc/sysman/multmeth.htm
I forgot to mention sense passing (smells, sounds) and materials (transparent, opaque) :mrgreen:
Anyway, this only answers the original question of what TADS does that Quest doesn’t. It doesn’t touch on how important those things are to people and whether they’re worth the complexity they add to the system. The TADS 3 learning curve is quite infamous by now.
I’m certainly sticking with T3, since I’m doing something weird with AgendaItems and the actor data class.
But I’ve noodled around with Quest, and it seems to me a nice engine for a classic PC-only type of text adventure, focused more on puzzle than on narrative. I remember being enthusiastic about SUDS, which however had one killer engine flaw (you couldn’t list props – like the sun – separately from takeable objects). The thinking is also similar to Adrift, which however is either a paid program or (if you use the old one) unstable.
If I had the ear of Quest’s creator, I’d suggest what would be most rewarding at this time would be a scene controller, that would enable you to write something more story-like, and perhaps deeper thinking into the conversation programming and NPC states.
But it’s a nice good little engine, and I’m glad to see the decision to make games playable on the web, and even designable on the web, seems to have been made early in its inception.
So, yes – Quest: well done!
Conrad.
ps - I’m sticking to TADS, but I admit I’m trying to decide whether to make a Quest game!
C.
This is true for the previous version of Adrift (4), but it’s changed with version 5 (currently in beta):
Ah, I see. Yes, that is new since I last checked in.
Conrad.