Types in Quest 5.0

“Types” let you share sets of properties between objects. They work in the same way as Quest 4.x, except slightly more efficiently in that instead of copying the properties to the object, the object just references the underlying the type if it doesn’t have its own override for a property.

You can view all the properties of an object using the Debugger, which is accessed via the Tools menu. Properties from an inherited type are shown in grey.

Types are defined using a <type> element, and properties are defined in the same way as for an object. Objects and types can both inherit from other types using an <inherit> tag.

  <type name="food">
    <health type="int">0</health>
    <eat>It looks tasty, but you're not hungry right now.</eat>

  <type name="fruit">
    <inherit name="food"/>

Default behaviour

If the ASLX defines a type called “default”, then it is applied to all objects – there is no need to specifically inherit from this type. Core.aslx uses this to define the default behaviour for objects:

  • The displayverbs and inventoryverbs properties are defaulted to give the standard buttons on the panes on the right-hand side of the Quest screen (“Look at”, “Take” and “Speak to” for the objects list, and “Look at”, “Use” and “Drop” for the inventory list)
  • All objects are droppable by default
  • The neutral gender and article (“it”) are set
  • Default container properties are set – by default the object is not a container, cannot be opened or closed, etc. This is just for convenience really – if we didn’t set these in the default type, then properties such as “isopen” would default to null instead of false, which would make the container logic messier. (An enhancement might be to add special logic so that in an expression “null=false” would be true, but I’m not sure how good an idea this would be – I’m open to feedback on this)
  • Advertisements

4 thoughts on “Types in Quest 5.0

  1. Jon D. (Overcat)

    Regarding null:

    I think the default type might expand proportionally to the complexity of the world model if null != false. After all, you’d have to explicitly set new properties to false in the default type as the model grew.

    What are some of the foreseeable drawbacks of equating null to false in expressions?

  2. Alex Warren Post author

    A drawback I see is that it makes it impossible to tell if the object actually has a null value for a boolean, or if it’s genuinely a boolean false.

  3. Jon D. (Overcat)

    Hmm. Perhaps it is best to leave the two as distinguishable. I guess that’s why you have Quest defining the IsNull function?

  4. Alex Warren Post author

    Actually that info on the wiki is out of date – there’s no IsNull function any more. You can just check for equality with null as normal, e.g. “if (object = null) …”

Comments are closed.