ebayfan414 wrote:
I think that what you're saying is that I should add a 'take' action as part of a type, let's say, type "moveable." That's what I thought of before, only I thought that if your "take" action, let's say, gives the item to the player, but the original "Player can't take item" is checked, then that would override your "take" action.
This is (IMHO) one of Quest's slightly confusing areas. There are actually four possible 'take' methods with Quest and understanding the order of precedence can make your head hurt - when are 'actions' not actions?
At the bottom of the heap is a straightforward 'take' message as typed into the QDK take message box - Quest calls this a 'tag' and it has the lowest rating. if any of the following alternatives are coded, then this take tag is ignored.
Next up is a take 'script', created if you use the 'edit script' box on the QDK take tab. This script will run instead of the simple take tag message if you provide it. It will not run if the object has a take 'action' as described next...
A take 'action' will override both a take script and a take tag, but the potential confusion doesn't end there, because Quest supports object orientated programming techniques, there are actually two ways for an object to gain a 'take' action.
1: The action can be inherited from a type. This is what I did in the example above. Here the 'action' I coded is inherited by the object(s) defined as being of the type 'special'. This action overrides any tag or script that the author provides through QDK, but is not the top of the heap, because it can be overridden by a (local to the specific object) 'action'.
2: The action can be coded in QDK under the 'add actions and properties' window for the particular obect. This action will override any inherited action (i.e. it is a specialisation) and of course also override any take tag or take script provided.
While this is a little bit complicated, it does make ASL very powerful and flexible in practice. Careful declaration of types with their inherited actions and properties makes coding variations on a theme (object wise) really very easy to do - more so because Quest supports
multiple inheritance.
So, the order of precedence (from the top) is:
1: a locally coded action (specialisation)
2: an inherited action (from a type declaration)
3: a take 'script'
4: a take 'tag'
Hope this helps you get your head around the example given.
Al (MaDbRiT)