Do we allow an implicit say command to be directed to this object? Normally we don't. Thuis property is only really meaningful on the Actor class but we define it here because it's needed by parser.t.

While it's possible to pour stuff into any container, we probably don't want to allow it on most of them

The allowPourOntoMe property controls whether we want allow anything to be poured onto this thing (even if it's possible). By default we don't.

Handled on iobj

Remap the lock action to our remapIn object if we're not lockable but we have a lockable remapIn object (i.e. an associated container).

If an actor within me cannot reach an object from me, should the actor automatically try to get out of me?

If the actor finds something in a hiddenPrep list and there's nowhere obvious for it go, should he take it? By default the actor should take it if the object he's found it in/under/behind is fixed in place.

Flag, do we want to attempt to unlock this item it it's locked when we try to open it?

[BRIGHTNESS EXTENSION]

The strength of the light the object is giving off, if indeed it is giving off light. This value should be one of the following:

0: The object is giving off no light at all.

1: The object is self-illuminating, but doesn't give off enough light to illuminate any other objects. This is suitable for something like an LED digital clock.

2: The object gives off dim light. This level is bright enough to illuminate nearby objects, but not enough to go through obscuring media, and not enough for certain activities requiring strong lighting, such as reading.

3: The object gives off medium light. This level is bright enough to illuminate nearby objects, and is enough for most activities, including reading and the like. Traveling through an obscuring medium reduces this level to dim (2).

4: The object gives off strong light. This level is bright enough to illuminate nearby objects, and travel through an obscuring medium reduces it to medium light (3).

There is nothing to stop game code using a higher value still to model a a super-powerful light source if that seems suitable to the situation being modelled in the game, but this probably will only rarely be necessary.

Note that the special value -1 is reserved as an invalid level, used to flag certain events (such as the need to recalculate the ambient light level from a new point of view).

Most objects do not give off light at all.

Return the appropriate on/off brightness, depending on whether or not we're currently lit

The brightness needed for us to be able to read this object (as opposed to merely examine it) By default we'll set this at 3 (the brightness used by adv3) but game code can overrife this to some other value if desired. [BRIGHTNESS EXTENSION]

Our brightness when unlit. This would normally be 0, but if we're visible in the dark it will be 1. [BRIGHTNESS EXTENSION]

Our brightness when lit [BRIGHTNESS EXTENSION]

This object's bulk, in arbitrary units (game authors should devise their own bulk scale according to the needs of their game).

The maximum bulk that can be contained in this Thing. We set a very large number by default.

By default we can't use most things as weapons

By default we assume most things can't be used to burn other things with.

We assume most objects aren't suitable for cleaning other objects with. Since the dobj is resolved first canCleanWithMe could be a method that checks whether the proposed iobj is suitable for cleaning gDobj; but a better way of doing it might be to list suitable objects in the mustBeCleanedWith property.

Most things can't be used to cut other things with

Most objects aren't suitable digging instruments

Flag: can our contents be dropped when we're in the actor's inventory (if they can, an implicit TaksFrom us will be performed to enable the Drop). By default they can't.

Entering something on means ENTER FOO ON BAR where FOO is a string literal and BAR is an object such as a computer terminal. Most objects can't be entered on in this sense.

Most things cannot be gone along

Most things cannot be gone through

Can we hear in from my exterior to my interior? That is, can an observer on the outside of this container hear a sound source on the inside?

By default, we can hear in for all containers, since most materials transmit at least some sound even if they're opaque to light. For a soundproof material (a glass booth, say), you could override this to make it (!enclosing) instead.

Can we hear out from my interior to my exterior? That is, can an observer on the inside of this container hear a sound source on the outside?

By default, we can hear out for all containers, since most materials transmit at least some sound even if they're opaque to light. For a soundproof material (a glass both, say), you could override this to make it (!enclosing) instead.

It should be possible to jump off something if and only if the actor is on it in the first place.

It usually isn't possible (or at least useful) to jump over things.

Usually, if something can be used to unlock things it can also be used to lock them

By default we make it possible to look behind things, but there could be many things it makes no sense to try to look behind.

By default we make it possible to look through things, but there may well be things you obviously couldn't look through.

We can look under most things, but there are some things (houses, the ground, sunlight) it might not make much sense to try looking under.

In general there's no reason why most objects can't be moved to.

Most things can't be used to move other things with. Note that since the dobj is resolved first, objects or subclasses could override this with a method that returns true or nil depending on the identity of the dobj.

The message to display if something can't be dropped.

Jumping off something has much the same effect as getting off it, i.e. moving the actor to our exitLocation.

[MODIFIED FOR POSTURES EXTENSION]

Note that the player char has seen the purloined item. Not doing this can make it appear that the player character doesn't know about an object that's in his/her inventory.

If we're actually a rear-like object (i.e. if our contType is Behind) then something put behind us can be moved inside us. Otherwise, all we can do with something put behind us is to add it to our hiddenBehind list and move it off-stage.

If we're actually a container-like object (i.e. if our contType is In) then something put in us can be moved inside us. Otherwise, all we can do with something put in us is to add it to our hiddenIn list and move it off-stage.

The most usual reason why we can't put something somewhere is that we can't pick it up in the first place, so by default we'll just copy cannotPutMsg from cannotTakeMsg.

If we're actually an underside-like object (i.e. if our contType is Under) then something put under us can be moved inside us. Otherwise, all we can do with something put under us is to add it to our hiddenUnder list and move it off-stage.

Note that this message should never display in an English-language game since removeDoer will intercept the action before it gets to this point.

[MODIFIED FOR POSTURES EXTENSION]

[MODIFIED FOR POSTURES EXTENSION]

Report that we've been taken. Note that if the action causes several items to be taken, this method will only be called on the final item, and will need to report on all the items taken.

Particular instances will nearly always need to override with a less generic and more plausible refusal message.

The default result of throwing something in a compass direction is that it lands in the dropLocation of its outermost room.

Presumably it's possible by default to pour something into me if I'm a container; but this could be overridden simply to true for objects like the sea or a river.

Most things can probably have something poured onto them in principle, though we might want to prevent it in practice. The canPourOntoMe property controls whether it's possible to pour onto this thing.

Normally we don't distinguish PushTravel from PullTravel, but if we want something to be pushable between rooms but not pullable, or vice versa, we can set these to different values.

By default we can't push travel most things. Push Travel means pushing an object from one place to another and traveling with it.

Flag: can under objects be placed behind us? By default they can if our contType is Behind. If this is set to true and our contType is not Behind, anything placed behind us will be treated as hidden behind.

Flag: can under objects be placed inside us? By default they can if our contType is In. If this is set to true and our contType is not In, anything placed in us will be treated as hidden in.

Flag: can under objects be placed under us? By default they can if our contType is Under. If this is set to true and our contType is not Under, anything placed under us will be treated as hidden under.

Can we reach in from my exterior to my interior? That is, can an observer outside this object reach something inside of it? By default, we can reach in if we're non-enclosing.

Can we reach out from my interior to my exterior? That is, can an observer inside this object reach something outside of it? By default, we can reach out if we're non-enclosing.

Most things can't be used to screw other things with.

Can we see in from my exterior to my interior? That is, can an observer outside of this object see things located within it? By default, we can see in from outside if we're transparent or we're non-enclosing.

Can we see out from my interior to my exterior? That is, can an observer inside this object see things located outside of it? By default, we can see out from inside if we're transparent or we're non-enclosing.

Although we don't track postures as such, some objects may be better choices than other for sitting on (e.g. chairs), lying on (e.g. beds) and standing on (e.g. rugs), so we allow these to be tested for individually at the verify stage.

Note that none of these three properties (canSitOnMe, canLieOnMe, canStandOnMe) should normally be overridden to simply true, since they cannot make it possible to sit, lie or stand on something for which isBoardable is not true (or which contType is not On).

Can we smell in (from an observer on my exterior to an odor source on my interior)? By default, we can smell in if we're non-enclosing, since most solid materials aren't very permeable to scents (at human sensitivities, at least).

Can we smell out (from an observer on my interior to an odor source on my exterior)? By default, we can smell out if we're non-enclosing, since most solid materials aren't very permeable to scents (at human sensitivities, at least).

By default we can't stand, sit or lie in anything. [POSTURES EXTENSION]

Flag, can we supply more items from us that are currently in scope? By default we can't; but a DispensingCollective may be able to.

We don't bother to define isAskable etc. properties since we assume that no inanimate object can be conversed with, and that game code will use the Actor class to allow conversation. In any case since there's never any difficult in talking about oneself, the various illogicalSelf checks aren't needed.

Indeed, the handling of conversational commands on Thing is minimal; they are simply ruled out at the verify stage, since most Things can't converse. The implementation of these actions that allows conversation to take place is on the Actor class. We do however define a canTalkToMe property so that Actor can use the verify handling defined on Thing by just overriding it.

Things can't be talked to, so game code shouldn't normally override this property; it's there to be overridden on the Actor class.

Most objects can the target of a throw, but it's conceivable that some might be obviously unsuitable

Most objects cannot have things thrown to then, since this would imply that they might be able to catch them, which only animate objects can do.

By default things can't be used to turn other things with

Most things can't be typed on.

Most things can't be used to unlock with. In practice there's probably little point in overriding this property since if you do want to use something to unlock other things with, you'd use the Key class.

Most things can't be written on.

If we want Attack to fail at the check stage we can supply a message explaining why.

This property can be defined to display a message at the check stage (and so stop the FEEL action there). Normally checkFeelMsg would be defined as a double-quoted string, but it can also be defined as a double-quoted string or a method that displays some text.

If we want Kissing to fail at the check stage we can supply a message here explaining why. This is most simply given as a single-quoted string, but a double-quoted string or method will also work.

CollectiveGroup, or a list of CollectiveGroups, to which this item belongs.

The list of things directly contained by this object

Flag: should this item's contents be listed? This can be used to control both contentsListedInLook and contentsListedInExamine.

Flag: should this item's contents be listed when its container is examined.

Flag: should this item's contents be listed as part of a room description (when looking around).

Flag, should this item's contents be listed when it is searched (by default this is simply true, since it would be odd to have a container that failed to reveal its contents when searched).

This object's containment type - that is, the locType for direct children. This is given as one of the spatial relation types (In, On, Under, Behind etc).

The currentInterlocutor is the Actor this object is currently in conversation with. This property is only relevant on gPlayerChar, but it is defined here rather than on Actor since the player char can be of kind Thing.

The value we're currently set to.

The name to display at the head of a room description when it's dark

The list of actions this object will respond to specifically if isDecoration is true. All other actions will be handled by dobjFor(Default) and/or iobjFor(Default). Game code can override this list (usually to expand it) for decorations that are required to handle additional actions.

If we're compiling for debugging, it will be useful to allow the GONEAR command with Decorations for testing purposes, but this can't be included in a release build without causing a compilation error, so we define the decorationActions property with different lists of actions depending on whether we're compiling for debugging or release.

The posture that's adopted by default by an actor entering or boarding this this. [DEFINED IN POSTURES EXTENSION]

The description of this Thing that's displayed when it's examined. Normally this would be defined as a double-quoted string, but in more complicated cases you could also define it as a method that displays some text.

Get everything I'm directly holding, which is everything in my immediate contents which is neither fixed in place nor being worn.

get everything that's directly in me

get everything I'm directly wearing

Can I be distinguished in parser messages by my contents? If so, we can be distinguished (in parser messages) from similar objects by our contents, or lack thereof: "bucket of water" vs "empty bucket". If this is true, our nominalContents property determines the contents we display for this.

Flag, should any items behind me be left behind when I'm moved; by default, they should.

Flag, should any items behind me be left behind when I'm moved; by default, they should.

The location in which something dropped in me should land.

Do we fully enclose our interior contents (true), or only partially (nil)? By default, we assume that our contents are fully enclosed. This can be set to nil for objects that represent spaces that are open on one side, such as a nook in a rock or a create without a lid.

For an object that's sometimes fully enclosing and sometimes not, such as a cabinet with a door that can be opened and closed, this should be overridden with a method that figures the current value based on the open/closed state.

Note that this only applies to our *interior* contents, such as contents of location type In. Contents that are atop the object or otherwise arranged around the exterior aren't affected by this.

Have we been examined? This is set to true when the player character examines the object. For a room, LOOK AROUND counts as examination, as does triggering a room description by traveling into the room.

Flag: is this item listed when its container is examined.

The lister to use to list an item's contents when it's examined.

Our exitLocation is the location an actor should be moved to when s/he gets off/out of us.

Get my list of unenclosed direct contents. This is the subset of my direct contents that have exterior location types (On, Outside, Behind, Under).

Whether the player character knows of the existence of this object, if if it hasn't been seen. Set to true for objects that the player character should be familiar with at the start of play, or make true when the PC learns of them.

The description displayed in response to a FEEL command

Where should an item that's been hidden in/under/behind something be moved to when its found? If it's taken, move into the actor; otherwise move it to the location of the object it's just been found in/under/behind.

Sometimes we may have a container, such as an oilcan, from which we want to pour a liquid, such as oil, and we're using the same object to do duty for both. We can then use the fluidName property to say 'the oil' rather than 'the oilcan' in messages that refer specifically to pouring the liquid.

In case isAttackable is changed to true but no other handling is added, we need to provide some kind of default report.

It's more logical to kiss actors, so we give the Kiss action a lower logical rank on ordinary things.

The total bulk of items hidden in, under or behind this object

A list of objects that are facets of this object, and so can be referred to with the same pronoun.

Our outermost room, i.e. the top level Room in which we are indirectly or directly contained.

Flag, if this is a nested room, should an actor get out of it before executing an intransitive Jump command. By default it should.

The total weight of items hidden in, under or behind this object [WEIGHT EXTENSION]

Our globalParamName is an arbitrary string value that can be used to refer to this thing in a message substitution parameter; for code readability it may be a good idea to make this a string representation of our programmatic name (where we want to define it at all).

Group order. This gives the relative order of this item within its list group.

A list of objects that are treated as hidden behind this one. A LOOK BEHIND command will list them and move them into the enclosing room. It follows that objects placed in this property should not be given an initial location. This should deal with the most common reason for wanting items to be placed behind things (i.e. to hide them). Note, the items in the hiddenBehind property should also be revealed when the player moves the hiding item.

A list of objects that are treated as hidden inside this one. A LOOK IN command will list them and move them into the enclosing room (or in this one if we're a container). It follows that objects placed in this property should not be given an initial location.

A list of objects that are treated as hidden under this one. A LOOK UNDER command will list them and move them into the enclosing room. It follows that objects placed in this property should not be given an initial location. This should deal with the most common reason for wanting items to be placed under things (i.e. to hide them). Note, the items in the hiddenUnder property should also be revealed when the player moves the hiding item.

[BRIGHTNESS EXTENSION]

The illumination threshold is the available brightness (returned by the brightnessWithin method) that needs to be exceeded in our interior to be able to examine objects or look around or satisfy other visibility criteris (mostly where the objVisible precondition is applies to the current action). The default illuminationThreshold is 1, which mimics the behaviour of both the adv3 library and the adv3Lite library in the absence of this extension.

An optional description to be displayed instead of our normal desc and any status information (such as our contents) if we're examined in a dark room and visibleInDark is true. Note that if visibleInDark is nil inDarkDesc will never be used.

Our look up table for things we've been informed about

The list of things we start the game knowing about. This list can contain a mix of game objects (Things and/or Topics) and fact tags. Note that it would be redundant to include Things and Topics already defined as familiar if this property is overridden on the initial player character object.

A specialDesc that's shown until this item has been moved

Get my list of enclosed direct contents. This is the subset of my direct contents that have interior location types (In).

The "inside" description. This is displayed when an actor LOOKS AROUND from within this object. Note that this applies not only to top-level rooms but also to things like chairs, platforms, and booths that can contain an actor. By default, we simply show the ordinary EXAMINE description (or the darkDesc if there's no illumination). Non-room containers such as chairs or booths should usually override this to provide the view from inside the object, which usually differs from the ordinary EXAMINE description. For a top-level room, you don't usually override this, since the only description needed for a room is normally the LOOK AROUND perspective.

Flag: is this item listed in an inventory listing.

By default most things can't be attached to any things. The base handling of ATTACH and DETACH on Thing merely rules them out at the verify stage. The SimpleAttachable and NearbyAttachable classes define in the optional attachables.t module provide fuller handling.

Although in theory we can attack almost anything, in practice there's seldom reason to do so.

Can an actor enter (get in or on) this object. Note that for such an action to be allowing the contType must also match the proposed action.

By default treat everything as breakable, but there are somethings that clearly aren't like sunbeams, sounds and mountains.

By default we assume most things aren't burnable

Assume most things start out not as clean as they could be

Most things probably could be cleaned, even if they're not worth cleaning in practice. Some things like a mountain or the moon probably can't be cleaned and could reasonably define isCleanable = nil.

Most things can't be climbed

By default something is closeable if it's openable

Most things aren't consultable

By default things can't be cut

If I declare this object to be a decoration (i.e. isDecoration = true) then its default behaviour will be to display its notImportantMsg for every action except Examine or GoTo. We can extend the actions it will respond to by adding them to the list in the decorationActions property.

Most things are not suitable for digging in

By default we assume that something's doffable if it's wearable

Most things aren't drinkable

By default we can drop anything that's held

Flag: Can this thing be eaten

Flag, can we enter (i.e. get inside) this thing? For most objects, we can't

Most things are extinguishable if they're lit, but some things (like the sun or a nuclear explosion) might conceivably not be. Note that this property should only be set to nil for things that couldn't be extinguished even if they were lit (the flames of Hell, for example, which might be considered undousable for all eternity, if you're bent on writing an infernal game).

Fasten by itself presumably refers to objects like seat-belts. There are not many such fastenable objects so we may things not fastenable by default.

Most things start out unfastened.

By default we can try feeling most things, but there may be some things it would be inappropriate to try feeling (like a blazing fire or Aunt Mable) or somethings that cannot be felt (like a ray of light).

Flag to indicate whether this item is portable (nil) or fixed in place (true). If it's fixed in place it can't be picked up or moved around (by player commands).

Since FLIP X is often synonymous with SWITCH X , by default we make something flippable if it's switchable.

Flag: can this object be followed? Most inanimate objects cannot, so the default value is nil.

Flag, do we want to treat this object as hidden from view (so that the player can't interact with it)?

The isInitialPlayerChar property was formerly used as an alternative method of identifying the player character. This method of doing so is now deprecated, except for its use on the Player class. Instead you should now define the player character on gameMain.initialPlayerChar

We can try kissing most things, even if it isn't very rewarding

Is this object lightable (via a player command)? Note that setting this property to true also automatically makes the LitUnlit State applicable to this object, allowing it to be referred to as 'lit' or 'unlit' as appropriate.

A global isListed property that can be used to set the value of all the others. By default we're listed if we're not fixed in place.

Is this object lit, i.e. providing sufficient light to see not only this object but other objects in the vicinity by.

Flag: is this object currently locked. By default we start out locked if we're lockable.

By default we assume anything fixed isn't moveable. That's not necessarily the case since we may be able to move something by pushing it around (say) even if we can't pick it up.

is this item currently switched on?

Is this object open. By default we'll make Things open so that their interiors (if they have any) are accessible, unless they're openable, in which case we'll assume they start out closed.

Is this object openable. If this property is set to true then this object can be open and closed via the OPEN and CLOSE commands. Note that setting this property to true also automatically makes the OpenClosed State apply to this object, so that it can be referred to as 'open' or 'closed' accordingly.

Is this object the player character?

Most things can't be plugged into other things or have other things plugged into them.

Most things aren't pourable (they can't be poured into or onto other things.

Is the this object's listenDesc displayed in response to an intransitive LISTEN command? (Only relevant if listenDesc is not nil)

Is the this object's smellDesc displayed in response to an intransitive SMELL command? (Only relevant if smellDesc is not nil)

We can at least try to pull most things.

We can at least try to push most things.

By default an object is readable if it defines a non-nil readDesc

By default an object is removeable if it's takeable

Most things can't be screwed

Most things aren't settable.

By default everything is smellable, but you can override this to nil if something isn't

Can this object be switched on and off?

By default a Thing is takeable if it's not fixed in place

By default everything is tasteable, but there might well be things the that it would not be appropriate to taste.

By default something is throwable unless it's fixed in place.

Are we transparent to light? If this is true, then an observer outside this object can see through it to objects on its interior, and an observer inside can see through to objects on its exterior.

This property controls transparency symmetrically (looking in from outside and looking out from within). The library also lets you control transparency asymmetrically, using canSeeIn and canSeeOut. Those values are by default derived from this one, but you can override them separately to create something like a one-way mirror.

By default we make everything turnable, but lots of things clearly won't be.

Flag; is this Thing a vehicle for an actor? If so then issuing a travel command while in this vehicle will call this vehicle to travel

is this object something that can be worn

If we've found a possible key but it doesn't actually work on this object, report that we're trying this key but it doesn't work.

A list of Keys that can be used to lock or unlock this Thing. Any Keys in this list will cause this Thing to be added to the plausible and actual lock lists of that Key at PreInit. This provides an alternative way of specifying the relation between locks and keys.

The logical rank assigned to kissing this object if kissing is allowed. Kissing an inanimate object is less likely than kissing an Actor.

Test whether this Thing is known to the player character.

A list of Keys that the player character starts out knowing at the start of the game can lock our unlock this Thing.

If we want to track whether characters other than than the player char know about or have seen this object, we can define knownProp and seenProp as the properties used by this Thing to track what it knows about and has seen.

The last location where the player character saw this object. Whenever the object is described or listed in the description of a room or another object, we set this to the object's location at that time.

The list of lightSources and their adjusted (for opacity and/or distance) brightness generated by the most recent call to brightnessWithin(). Each element in the list is itself a two-element list of the form [obj, adjustedBrightness] where obj is the object providing light and adjustedBrightness is the brightness of that object adjusted for transmission through distance or partial opacity. [BRIGHTNESS EXTENSION]

The subset of our contents that should be listed.

The description displayed in response to a LISTEN command

The response to LISTENing TO this object when the actor can't see us. [DEFINED IN SENSORY EXTENSION]

The response to LISTENing TO this object when the actor can see us. [DEFINED IN SENSORY EXTENSION]

Listing order. This is an integer giving the relative position of this item in a miscellaneous item list. The list is sorted in ascending order of this value.

List group. At the moment this does nothing, but it has been retained from the Mercury library for possible future use.

The location of this object, i.e. this object's immediate container (which may be another Thing, a Room, or an Actor such as the player char). Note that while you should specify the initial location of an object via this property you should never directly alter this property in game code thereafter; to change the location on object during the the course of a game use the moveInto(loc) or actionMoveInto(loc) method.

The lockability property determines whether this object is lockable and if so how. The possible values are notLockable, lockableWithoutKey, lockableWithKey and indirectLockable.

By default our lookInMsg just says the actor finds nothing of interest in us; this could be overridden for an objecy with a more interesting interior.

Flag: is this item listed in a room description (when looking around).

Flag, if our contType is Carrier (i.e. we're an Actor), should our contents be marked as seen even though it hasn't been listed in a room description? By default this is set to true, on the basis that the inventory (and parts) of an actor would normally be in plain sight.

Check if the player specifically asked to PULL this object somewhere. In the main library we assume not, but language-specific code will need to override to check what that player's command actually said.

Check if the player specifically asked to PUSH this object somewhere. In the main library we assume not, but language-specific code will need to override to check what that player's command actually said.

The maximum bulk that can be hidden under, behind or in this object, assuming that the player can put anything there at all. Note that this only affects what the player can place there with PUT IN, PUT UNDER and PUT BEHIND commands, not what can be defined there initially or moved there programmatically.

The maximum number of items we can hold, irrespective of their bulk (or weight). By default we make this a very large number so there's no effective limit; game code can set a lower limit on the player character and/or other actors.

The maximum bulk that a single item may have to be inserted into (onto, under, behind) this object; by default this is the same as the bulk capacity, but you could set a lower value, e.g. to model a bottle with a narrow neck.

The maximum weight of any single item we can contain [WEIGHT EXTENSION

The maximum weight that can be hidden under, behind or in this object, assuming that the player can put anything there at all. Note that this only affects what the player can place there with PUT IN, PUT UNDER and PUT BEHIND commands, not what can be defined there initially or moved there programmatically. [WEIGHT EXTENSION]

Has this item been mentioned yet in a room description. Note that this flag is used internally by the library; it shouldn't normally be necessary to manipulate it directly from game code.

Has this object ever been moved by the player character? This is set to true when the PC takes the object or puts it somewhere.

The notional location (other object) this object has been moved to as the result of a MoveTo command.

If this is non-nil then this is an object or a list of objects that must be/can be used to clean this object.

The lister to use when listing this object's inventory. By default we use the standard inventory lister for the default WIDE inventory listing and the inventoryTallLister for the TALL inventory listing.

The lister to use when listing the objects behind me in response to a LOOK BEHIND command. By default we use the lookInLister.

The lister to use when listing the objects inside me in response to a LOOK IN command. By default we use the lookInLister.

The lister to use when listing the objects under me in response to a LOOK UNDER command. By default we use the lookInLister.

The lister to use when listing my contents when I'm opened. By default we use the openingContentsLister.

The ThoughtManager object associated with this Thing (if this Thing does any thinking); this is only relevant if thoughts.t is present and this Thing becomea a player character.

The lister to use when listing what this object is wearing.

But that most things don't actually need cleaning in the game

My nominal contents is the special contents item we can use in naming the object. This is useful for containers whose identities come primarily from their contents, such as a vessel for liquids or a box of loose files. Returns an object that qualifies the name: a "water" object for BOX OF WATER, a "files" object for BOX OF FILES. Nil means that the object isn't named by its contents.

Note that this is always a single object (or nil), not the whole list of contents. We can only be named by one content object. (So you can't have a "box of books and papers" by having separate nominal contents objects for the books and the papers; although you could fake it by creating a "books and papers" object.)

This object cannot be dropped if game code deems it to be undroppable for reasons beyond throse enforced in the objCarried PreCondition.

We're also a poor choice if none of the tentative direct objects is in our list of notional contents

If we are lockable with key, then were a good choice of object for an UnlockWith action provided we're currently locked.

The preposition that should be used to describe containment within this thing (e.g. 'in', 'on' , 'under' or 'behind'). By default we get this from our contType.

The preposition that should be used to describe movement to within this thing (e.g. 'into', 'onto' , 'under' or 'behind'). By default we get this from our contType.

[MODIFIED FOR POSTURES EXTENSION]

[DEFINED IN POSTURES EXTENSION]

Make us locked.

[MODIFIED FOR POSTURES EXTENSION]

[DEFINED IN POSTURES EXTENSION]

[MODIFIED FOR POSTURES EXTENSION]

[DEFINED IN POSTURES EXTENSION]

Make us unlocked.

[BRIGHTNESS EXTENSION]

Our opacity is the extent to which we reduce the brightness of any light that passes through us. An opacity of 4 or more will cut off the brightest light, while an opacity of 0 means we're transparent. By default we have an opacity of 0 if we're transparent and 4 otherwise.

Note that if we want any light to penetrate us at all we should set transparency to true (we're at least somewhat light permeable) and then set opacity to some suitable value (if we don't want it to be zero, which is otherwise the default for a transparent object).

Flag, has this object ever been opened. Note that this is nil for an object that starts out open but has never been closed and opened again.

Do we want this object to report whether it's open? By default we do if it's both openable and open.

The owner or owners of the object. This is for resolving possessives in the player's input, such as BOB'S WALLET. By default, an object has no explicit owner, so this is an empty list.

This should only return the *explicit* owner(s), not an implied locational owner. For example, if Bob is holding a key, it's implicitly BOB'S KEY. However, the key may or may not still be Bob's after he drops it. If the key is something that's understood to belong to Bob, whether it's currently in his physical possession or not, then this routine would return Bob; otherwise it would return nil.

An object can have multiple explicit owners, in which case it'll be recognized with a possessive qualifier for any of the owners. The first owner in the list is the nominal owner, meaning its the one we'll use if we're called upon to display the object's name with a possessive phrase.

Are we the nominal owner of the objects we contain? This controls whether or not we can be chosen as the nominal owner of a contained object for display purposes. If a contained object has no explicit owner, it can still be implicitly owned by an actor carrying it, or by another suitable container. (Note that this only applies as a default. When an item in our contents has an explicit owner, that will override the implied container ownership for that item. So, for example, Bob can be carrying Bill's wallet wallet, and as long as the wallet has its explicit owner set, we'll still describe it as Bill's despite its location.)

By default, most objects are not nominal owners. Actors generally should set this to true, so that (for example) anything Bob is carrying can be described as Bob's. Something with contType = Carrier is likely to be an actor and hence something that can own its contents.

Do we want paragraph breaks between the listings of subcontents (i.e. the contents of this item's contents)? By default we take our value from the global setting on gameMain.

The posture currently adopted by this Thing. We define this on Thing rather than Actor mainly because the player character can be a Thing, but it could also use to describe the metaphorical posture of inanimate objects (A rug lies on the floor, the jug sits on the rug, the tall grandfather clock stands by the door). [DEFINED IN POSTURES EXTENSION]

The text we display in response to a READ command. This can be nil (if we're not readable), a single-quoted string, a double-quoted string

Can the player character recognize this room (enough to know its name and have a rough idea of its location) in the dark? (If so then looking around in this room in the dark makes it visited and familiar, otherwise it doesn't).

If our contType isn't Carrier we're unlikely to be an actor, so we're a poor choice of object if the parser has to select an actor, typically when the player has entered a command targeted at an NPC.

If non-nil, remapUnder specified the object that acts as our proxy rear, i.e. the object to which any PUT BEHIND or LOOK BEHIND action directed at us will be redirected.

If remapIn is not nil, a LOOK IN, PUT IN, OPEN, CLOSE, LOCK or UNLOCK command performed on this Thing will be redirected to the object specified on remapIn. In other words, remapIn specifies the object that acts as our proxy container.

If non-nil, remapOn speficies the object that acts as our proxy surface, in other words the object to which PUT ON will be redirected.

The list of possible remap props

If non-nil, remapUnder specified the object that acts as our proxy underside, i.e. the object to which any PUT UNDER or LOOK UNDER action directed at us will be redirected.

The contents lister to use for listing this room's miscellaneous contents. By default we use the standard lookLister but this can be overridden to use a CustomRoomLister (say) to provide just about any wording we like.

The room part (e.g. defaultNorthWall) with which we're notionally associated. [DEFINED IN ROOMPARTS EXTENSION]

The description of ourselves to be displayed when our associated roomPart is examined. [DEFINED IN ROOMPARTS EXTENSION]

The contents lister to use for listing this room's miscellaneous subcontents. By default we use the standard lookContentsLister but this can be overridden.

The name to display at the head of a room description

Flag: is this item listed when is container is searched (or looked in).

Have we been seen? This is set to true the first time the object is described or listed in a room description or the description of another object (such as LOOK IN this object's container).

Probably most things shouldn't be broken though.

The sightSize can be small, medium or large and controls how visible this object is from a remote location. If it's small, it can't be seen from a remote location at all. It it's medium, the object can be seen, but it's not possible to discern any detail. If it's large, it can be seen and described. Note that this behaviour is only the default, however, since it can be changed by overriding the isVisibleFrom() and remoteDesc() methods. Note also that sightSize is not related to the bulk property (unless you override sightSize to make it so).

As well as ruling out certain objects for sitting, lying or standing on, we can also give them a score for each of these postures; e.g. a bed may be particularly suitable for lying on (although you could lie on the sofa) while a chair may be particularly suitable for sitting on (though you could sit on the bed.

By default we'll give each posture a score of 100, the normal logical verify score. Note that these scores have no effect if the corresponding can xxxOnMe property is nil.

The description displayed in response to a SMELL command

The response to SMELLing this object when the actor can't see us. [DEFINED IN SENSORY EXTENSION]

The response to SMELLing this object when the actor can see us. [DEFINED IN SENSORY EXTENSION]

Our associated Odor object, if we have one [SENSORY EXTENSION]

The smellSize can be small, medium or large. By default something is smellable from a remote location either if its smellSize is large or if it smellSize is not small and its remoteSmellDesc() method has been defined. Overriding isSmellableFrom(pov) may change these rules.

Our associated Noise object, if we have one. [SENSORY EXTENSION]

The soundSize can be small, medium or large. By default something is audible from a remote location either if its soundSize is large or if it soundSize is not small and its remoteListenDesc() method has been defined. Overriding isAudibleFrom(pov) may change these rules.

If present, a description of this object shown in a separate paragraph in the listing of the contents of a Room. If specialDesc is defined then this paragraph will be displayed regardless of the value of isListed.

Is this item listed before or after the list of miscellaneous contents in the room. By default we'll show the specialDesc of items before miscellaneous items in a room description but afterwards otherwise: this places specialDescs in a more logical order in relation to the text of listers used to list the contents of obejcts other than rooms.

For possible future use; at the moment this doesn't do anything

The specialDescOrder property controls where in a series of specialDesc paragraphs this item is mentioned: the higher the number, the later it will come relative to other items. Note that this does not override the specialDescBeforeContents setting.

Our staging location is where we need to be to get on/in us

The state-specific description of this object, which is appended to its desc when examined. This is defined as a single-quoted string to make it easy to change at run-time.

The description displayed in response to a TASTE command

The message to display if there's not enough light to read this item. [BRIGHTNESS EXTENSION]

The message to display when it's too dark to see anything

Otherwise say this object is too far away for the actor to hear.

Otherwise say this object is too far away for the actor to see any detail.

Otherwise say this object is too far away for the actor to smell.

Our total weight, including the weight of our contents [WEIGHT EXTENSION

By default we use the initSpecialDesc until the object has been moved, but this can be overridden with some other condition.

Should the specialDesc be used? Normally we use the specialDesc if we have one, but we may want to override this for particular cases. For example, if we want an item to have a paragraph to itself until it's moved we could define useSpecialDesc = (!moved) [making it equivalent to initSpecialDesc]. Note that the useSpecialDesc property only has any effect if specialDesc is not nil.

Is this object visible in the dark without (necessarily) providing enough light to see anything else by, e.g. the night sky.

A property that can be used to boost this object being chosen by the parser, other things being equal; it can be used as a tie-breaker between two objects that otherwise have the same verification scores. Game code should normally use fairly small values for this property, say between -20 and +20, to prevent overriding the verification score.

Our own weight, not counting the weight of our contents [WEIGHT EXTENSION]

The total weight we're capable of containing [WEIGHT EXTENSION

If this object is currently being worn by someone, the wornBy property contains the identity of the person wearing it.

Announce Best Choice name. This can be used in those rare cases where you want to override the name the parser uses to describe an object when announcing its best choice of object. For example, if you have a bottle of wine from which you can fill a glass, you might prefer '(with wine from the bottle)' to '(with the bottle of wine)' following FILL GLASS; action is the action being carried out for which the object has been chosen and role(DirectObject or IndirectObject) is the role the chosen object is playing in the action. By default this method just returns theName.

[BRIGHTNESS EXTENSION] The accumulateBrightness() method is a stub (or hook) for a user-defined algorithm for accumulating the brightness of multiple ligjt sources if this is desired. By default we simply return the value of the maxBrightness parameter that is passed to us (which is the brightness returned by the latest call to brightnessWithin()), but game code can override this method to provide some other calculation of accumulated brightness by iterating over the list of objects and their adjusted brightnesses in our lightSources property.

Note that accumulateBrightness is provided to allow it to be readily overridden by game code, but is not designed to be directly called from game code, which should call it only via accumulatedBrightnessWithin();

[BRIGHTNESS EXTENSION] This is little more than a hook for user code to provide its own means of accumulating the brightness from multiple light sources.

Move into generated by a user action, which includes notifications

Modified in cmdhelp.t[863]:
Modified for CMDHELP EXTENSION. Note the last turns on which this object was moved and on which something was moved into this object.

Modified in roomparts.t[178]:
We modify actionMoveInto here so that an action that results in moving an object (e.g. taking a picture that's notionally hanging on a wall) removes the association between the object and its room part. [MODIFIED FOR ROOMPARTS EXTENSION]

Modified in signals.t[275]:
emit a actmoveSignal or unlitSignal when this object moved as part of action handling. [SIGNALS EXTENSION]

The before action handling on this Thing if it's the current actor. We define it here rather than on Actor since the player character can be a Thing. By default we do nothing.

Add an item to this object's contents. Normally this method is used internally in the library than directly by game code. If the vec parameter is supplied, the object added to our contents is also added to vec; again this is intended primarily for internal use by the library.

After action notification on this Thing; this is triggered whenever an action has just been performed when we're in scope. The action we'd test for here would normally be one that *doesn't* involve this Thing.

After travel notification. This is called just after traveler has traveled via connector.

Return a list of everything that's directly or indirectly contained within us.

Check whether the actor can reach out of this object to touch obj, if obj is not in this object.

Defined on TIAAction extension.

Before action notification on this Thing; this is triggered whenever an action is about to be performed when we're in scope (and could be used to veto the action with an exit macro). The action we'd test for here would normally be one that *doesn't* involve this Thing.

Use the travelVia() method of the iobj to move the dobj to its new location.

Before travel notification. This is called just before traveler attempts to travel via connector. By default we do nothing

How bright is it within us (assuming, in practice, that we're either a Room or an enterable container (aka Booth)? [BRIGHTNESS EXTENSION]

This method is primarily intended for use with the symconn extension, where it is redefined, but other code may find a use for it.

Is obj audible from us?

Display a message explaining that push travel is not possible

Return a message (single-quoted string) explaining why target can't be reached from inside this Thing (when this Thing is typically some kind of nested room such as a Booth or Platform).

Is obj reachable (by touch) from us?

Is obj visible from us?

Is obj smellable from us?

Can this Thing (which might be the Player Char for instance) talk to other?

Check if displaying prop could possibly produce any output. The only tests we apply here is that prop is not defined as nil.

Check for contradictions betwen the new piece of information (tag) and information we already know about.

Check whether an item can be inserted into this object, or whether doing so would either exceed the total bulk capacity of the object or the maximum bulk allowed for a single item.

Modified in weight.t[48]:
Check whether obj can be inserted into us without exceeding our bulk and weight constraints. [WEIGHT EXTENSION]

Check the travel barriers on the indirect object of the action

Check whether the actor can reach (touch) this object. If this method displays anything (which should be the reason this object can't be touched) then the object can't be reached. Note that this only has any effect when the touchObj preCondition is defined.

Check whether an actor can reach inside this object (for reasons other that it enclosing its contents; e.g. because it's out of reach). If this method displays anything (which should be the reason the interior of this object can't be reached) then disallow reaching inside. Note that this only has any effect when the touchObj preCondition is defined on this object. By default we can reach inside if we can reach this object and not otherwise. If the optional target parameter is supplied, it's the object that actor is trying to reach.

checkRemove is called from the check stage of an action (typically TAKE) that might remove obj from me. If it wants to object to the removal of the object, it should simply display a message explaining why. By default we call the same method our container to check whether anything in our containment hierarchy objects to the removal. If this method is overridden in game code it may only need to call inherited(obj) on any branch that doesn't itself object to the removal.

Check that the actor has enough spare bulkCapacity and enough items carried capacity to add this item to his/her inventory. Since by default everything has a bulk of zero and a very large bulkCapacity, by default there will be no effective restriction on what an actor (and in particular the player char) can carry, but game authors may often wish to give portable items bulk in the interests of realism and may wish to impose an inventory limit by bulk by reducing the bulkCapacity of the player char.

Modified in weight.t[99]:
Check whether the actor has the bulk and weight capacity to hold us. [WEIGHT EXTENSION]

If the setting is valid, do nothing. If it's invalid display a message explaining why. We do nothing here but this is overridden on the Settable class, which may be easier to use than providing your own implementation on Thing.

Get the containment relationship between 'child' and 'self'. This returns the containment type of the immediate child of 'self' that contains 'child'.

Find the nearest common containing parent of self and other. Unlike commonInteriorParent this doesn't take account of the type of containment (it can be In, On, Under, Behind or anything else) just so long as we find a common parent in the containment hierarchy.

Find the nearest common interior parent of self and other. This finds the nearest parent that both self and other are inside of.

Get the interior containment path from 'self' to 'other'. This returns a list containing three elements. The first element is a sublist giving the interior containers you have to traverse outwards from self up to the common interior parent. The second element is the common container; this will be nil if the two objects are in separate rooms. The third element is a sublist giving the containers you have to traverse inwards from the common parent to other.

Search for a "blockage" along the container path between 'self' and 'other'. 'outProp' and 'inProp' are "can" properties (&canSeeOut, &canReachIn, etc) that test a container to see whether we can see/reach/hear/etc in or out of the container.

We trace the containment path, using traceContainerPath(). For each outbound container on the path, we evaluate the container's outProp property: if this is nil, we add that container to the blockage list. Next, if there's no common parent, we add the outermost room containing 'self' to the list. Next, we trace the inbound path, evaluating each container's inProp property: if nil, we add that container to the blockage list.

Finally, we return the blockage list. This is a vector giving all of the blockages we found, in the order we encountered them.

The description of the room when it's dark

Otherwise do nothing, because our 'connector' must be a string or method that explains why travel that way isn't possible.