Sometimes as I'm merrily scripting along, adding capabilities to a specific type of object by tacking on new actions, I think "Gee, I wish I could pass parameters to the action of an object".

At that point I have two choices:

1) Create new properties on the object that serve as placeholders for parameters that an object action needs to be aware of
2) Put the functionality of the action into its own procedure, then pass the object as a parameter (along with the other parameters)

Solution two is obvious. But statements that are supposed to be logically grouped with a specific object type (or specific object) are now hanging out in their own procedure and have no direct association with the original object or object type. (Is this just me being nit-picky? )

Solution one is alright: create a set of properties (parameter1, parameter2..,parameterN) on the object that any action can refer to. Those properties have a default 'empty' setting (such as NO_DATA) which indicates that nothing was passed to them. If they do not equal NO_DATA, the action can choose to use them.

action <SomeAction> {

	set string <this; $thisobject$>
	if (#(this):parameter1# <> NO_DATA) then {
		'do stuff
	}
	else {
		'show error - parameter1 was supposed to be passed
	}

	property <#this#; parameter1 = NO_DATA>
}

The action resets any parameters it uses to NO_DATA when it finishes.

But then when I call the action on an object that requires those parameters, I have to:

property <SomeObject; parameter1 = SOME_DATA>
doaction <SomeObject; SomeAction>

The more parameters I need, the more ASL statements are required to call the action properly.

So my question is: how hard would it be to add parameter passing to object actions? That way, I could simply:

doaction <SomeObject; SomeAction(SOME_DATA)>

And then in the object action:

action <SomeAction> {

	if ($numberparameters$ > 0) then {
		set string <p1; $parameter(1)$>
		'do stuff
	}
	else {
		'show error - parameter1 was supposed to be passed
	}	
}

I simply work with the fact Quest uses global variables.

But that would be a nice addition, and would help with standardizing the action call (ie, calling it from two different places is messy).

Why don't you try a different language that supports that functionality? (Inform 6, TADS 2/3, and I think Hugo)

I've been nibbling at the TADS 3 documentation recently, and I think it fits me better than Inform 6 or 7. I am going to try writing my OneRoom competition entry with TADS 3 after the competition is over.

But I like Quest's ASL because it's a blank slate: I don't have to worry about jacking into a pre-existing model, or overwriting one. I can make it all myself! (And learn things about structure along the way). Although there are times when I override default functionality in Quest, it isn't very hard to do so.

That said, TADS 3 has given me a lot to think about (from what I've read so far). Lot's of great stuff in the (prolific) documentation. I know I can modify the libraries however I want, and that alone is luminawesome (so awesome it glows). Just have to understand those libraries first!

And? You can ditch the TADS standard library if you want. (I wrote an ADRIFT to TADS converter that completely replaces the library.)

(I wrote an ADRIFT to TADS converter that completely replaces the library.)

Cool.

You can ditch the TADS standard library if you want.

I realize that. There's also inertia - I'm already familiar with how to do things with ASL, and I'm at the "creative" stage with it. It's going to take me some time to be at the same stage with TADS (I'm no genius). I've only got so much time on my hands, and fate has placed me here first. I can foresee, however, getting much more into TADS in the future. I may even attempt to make my own IF scripting language/C library some time down the road, after I've learned enough lessons to think I can manage it. We'll see.

You're wrong about Quest being a blank slate. For example, "getobjectname" is written in VB. There's no way to write your own equivalent in ASL.

For example, one of the examples for Inform shows how to modify disambiguation so that if the player tries eating something, the parser will prefer an edible object to a non-edible one:

> I
You are carrying a black forest cake and an issue of Black Mask magazine.

> EXAMINE BLACK
Which black do you mean, the black forest cake or the issue of Black Mask magazine?

> EAT THE BLACK
(the black forest cake)
It's delicious.


Quest treats directions as very special things. Other languages treat them as ordinary objects. For example, in I6, if I wanted to have a Discworld scene, I could replace "north, south, east, west" with "rimwards, hubwards, turnwise, widdershins" for that portion.

You can replace north/south/east/west in appearance to the player.

For example, one of the examples for Inform shows how to modify disambiguation so that if the player tries eating something, the parser will prefer an edible object to a non-edible one...

Yes, I would very much like access to the disambiguation process. Going to put up a Feature Request post in regards to that. All Quest needs is a hook to preprocess the disambiguation, an array that stores the latest objects needing disambiguation, and a function call to allow us to redirect back to the original disambiguation functionality once we modify the array.

define game <SomeGame>

    ambiguous {

        'process AmbiguousItems array here
        $disambiguate(AmbiguousItems)$
    }

end define

Quest treats directions as very special things. Other languages treat them as ordinary objects. For example, in I6, if I wanted to have a Discworld scene, I could replace "north, south, east, west" with "rimwards, hubwards, turnwise, widdershins" for that portion.

I have been implementing my own exit objects for a while now - akin to TADS travel connectors. It is not terribly difficult. Just need to code a few commands & synonyms, and utilize the defaultroom type. Can post the ASL if you like.

Exits as "very special things" ??

They are properties/actions of a room.
The only problem being that Quest doesn't allow you to change then like any other object property/action.

Saying they are "special things" is just wrong - there's no totally different way to handle exits (ie, a totally different coding mechanism, or they are definitely not properties), they are closer to "read-only properties" (which are changable by using some unique commands).

In comparison, l6 treating them like "normal" objects would mean you could pick them up, and otherwise interact with them in the same way as normal objects... Which is odd since exits are NOT normal objects - they are infact a "property of a room" (a door is an object - the exit is a hole/portal/other absence of an object).

As for disambiguation, I'd love for that to happen.
For us to be able to create our own menu, in our own style, rather then Quest pop-ups all the time.

Let me rephrase that.

For each compass direction, there is a corresponding object. (It contains the vocabulary for that direction and tells which property is used for that direction.)

Commands like "push cart (direction)" are handled partially by matching the phrase "(direction)" against the direction objects.

Each connection between two rooms is stored in a property for each room, as you expected.

In Quest, exits are definitely stored differently than properties; unless Alex has changed this, if you change an exit with the "change exit" mechanism, the map will update to the new value, but the value stored in the property isn't.

Yes, exits could possibly be stored differently - since things have slowly evolved into objects and properties for ASL.
I did want to say something about this, but I can't think of a good way to explain the thought, so I'll leave it.