1. Make the alt property read and write

2. More direct control over the disambiguation popup - perhaps create a built-in string array that gets filled

3. Direct control of quest.lastobject

1. for each property on <object> - stored in #quest.property#
2. for each action on <object> - stored in #quest.action#
3. for each type on <object> - stored in #quest.type#

I thought of maybe only using one variable, such as #quest.element# for all three of these, but then I couldn't nest one inside of the other. Well, actually I could by setting some variables in-loop, but...

for each object in game {
    set string <object; #quest.thing#>
    for each object in <$locationof(#object#)$> {
        msg <#object# says hello to #quest.thing#>
    }
}

I wonder if that works.

for each object in game {
    set string <object; #quest.thing#>
    for each object in <$locationof(#object#)$> {
        msg <#object# says hello to #quest.thing#>
    }
}

That should work, seeing as quest.thing is set in the outside loop once it iterates to each object - and re-set in the inside loop for each iterative object.
.. I'd be fascinated to hear the outcome.

1. for each property on <object> - stored in #quest.property#
2. for each action on <object> - stored in #quest.action#
3. for each type on <object> - stored in #quest.type#

I'd have to agree with you there - except with point 3.
Quest simply applies the types by giving the objects each property/action/etc. (at least, that's the way I'd assume)
I can't remember seeing anything about removing types from objects.

Can I remove a type dynamically?

type <#object#; not Type>

Not sure if this would remove all of the associated properties and actions, though. How would Quest know if an action contained in the type was exclusive to that type, or was overwritten as a process of inheritance. (Not sure if my terminology is right here. I think this is the point you were making.)

Sorry - you lost me with the inheritance.

When you apply a type, I think Quest simply takes the actions/properties assigned to that type and applies them to the object.
If it is a child of another type - then it (the type) inherits the actions/properties of it's parent, overwrites it with it's own defined actions/props, then applies them to the object (also overwriting anything there).

Do not try to think of this as something similar to C++/java/etc. Objects are already defined in ASL to be specific.. all you are doing is assigning values which can change.

I wonder if this is even on Alex's coding schedule... I wonder how he would implement it exactly.

Maybe I'm semantically challenged.

But right. So if I add a bunch of properties and actions by applying a type, Quest wouldn't remove those properties and actions if I were to remove the type. Because it can't know if those properties and actions were inherited from the type being removed, or from another type, or if they were just on the object to begin with.

You could use your property string for types, as type is a property saying to write all the properties listed above... I don't use types, I use property, lots of properties. lol. Just make a procedure that checks if an object has a type property, and add all the real properties. That's what I did!

Why is it that you don't use types, elex? Same for you, tr0n, you mentioned you didn't like them, or something to that effect.

One of the main benefits I see is the organization of the actual ASL. I can have a bunch of neat and tidy types in a .lib file. I don't know. Someone give me some arguments/opinions here.

I find types, especially for use in an MMORPG/MUD, invaluable. Take, for instance, the following:

define type Creature
   eyes
   nose
   ears
end define

define type Human
   hands
   feet
end define

define type Feline
   paws
   tail
end define

You could assign the type Creature to a player's character object and, based upon their choices during character creation, further define the character object by assigning Human or Feline.

I don't use types because I prefer to customize an object (even if it is each object).

If you have an object type of human, then assigned it to a fair amount of people - everything would get so similar for the player..
And what's the point in adding a type to something and then customizing it some more unless you're having very similar things with minor changes.

I could see some things which may be useful, say for being a sock type, or shoe type, or shirt type... which could hold certain things (takeable, could hold things of certain sizes, could be wearable) as demonstrated by Al's library... But I don't like types myself..

It also leads to something similar to spaghetti code - where you need to keep going back and forth between an extra point/file to understand what's happening (I have a terrible memory!).

As for removing types from objects, I don't think it's possible because it doesn't layer it like that.. Quest simply see's an "apply type #" command and just adds those features to the object and toddles onwards. It doesn't even note what types it has applied (as far as I can see in documentation/practice/logical thought).
First it would need to record which types it had applied - and then it would need to sort these into some sort of hierarchy where properties are owned by the highest type and can only be removed when removing that type (ie, types which are already applied - are owned)... except that still means that if you remove type A (owner), then type B may still have a missing property just because it was applied lastly and wasn't an inheritance child.