The active property is used by any TopicGroups and TopicEntries located directly within us to determine whether they in turn are active. Normally there is no reason for game code to override this on an ActorState; the property is simply provided so that TopicGroups and TopicEntries can call location.active regardless of whether they're located in TopicGroups, ActorStates or Actors.

Our actor's attention span while our actor is in this ActorState. This is the number of turns the actor will wait for the player character to say something when a our actor is the player character's current conversation partner, before our actor gives up on the conversation and terminates it through 'boredom'. A value of nil (the default) means our actor is infinitely patient and will never terminate a conversation for this reason.

Our associated actor. This is set to our location at preinit by our initializeActorState method.

Should other actors who can notionally hear the PC talking to us overhear when information is imparted to us and we're in this ActorState? I.e. should their setInform() methods be called too? By default they should.

Set isInitState to true if you want this ActorState to be the one the associated Actor starts out in.

If the noResponse method is defined (i.e. non-nil) then this ActorState will behave like a TADS 3 HermitActorState, i.e. the noResponse message will be displayed in response to any conversational command

noResponse can be either a single-quoted string, a double-quoted string or a method. If it's a string then it will be displayed instead of any TopicEntry. It it's a method it will be executed; if it then displays anything no attempt will be made to match a TopicEntry, but it if doesn't display anything the conversational command will go on to be handled as normal.

Flag -- has the player character just arrived?

The specialDesc from the actor's current ActorState is used as the specialDesc for that actor in a room listing.

The stateDesc from the actor's current ActorState is appended to the desc defined on the actor when the actor is described via an EXAMINE command.

Activate the state - this is called when we're about to become the active state for an actor. We do nothing by default.

Add this ActorState to our actor's list of ActorStates

The afterAction() method is called on an actor's current ActorState when the actor is in scope for the action that's just taken place. This allows game code to define state-specific reactions.

The afterTravel notification triggered when the Actor is in this ActorState and traveler has just traveled via connector. By default we do nothing.

the arrivingTurn method is executed when an actor in this state has just followed the player char to a new location.

The beforeAction() method is called on an actor's current ActorState when the actor is in scope for the action that's just about to take place. This allows game code to define state-specific reactions.

The beforeTravel notification triggered when the Actor is in this ActorState and traveler is just about to travel via connector. By default we do nothing.

Determine whether our actor will allow a current conversation to be terminated for reason when in this ActorState. Return true to allow the conversation to be terminated and nil otherwise. By default we simply return true. If we return nil we should also display a message explaining why we're not allowing the conversation to end.

Deactivate the state - this is called when we're the active state for an actor, and the actor is about to switch to a new state. We do nothing by default.

The getBestMatch() method is already defined on TopicDatabase, from which ActorState inherits via ActorTopicDatabase. ActorState overrides it to allow certain modifications particular to ActorState, such as the possibility that the prop parameter might be passed as either a list or a property pointer to a list property, and the need to take into account the actor's activeKeys list.

Initialize this ActorState (this is actually called at preinit).

If our associated actor is viewed from a remote location, use the ActorState's remoteSpecialDesc to describe the actor in a room listing. By default we just use the specialDesc.

The message to display when the player char sees this actor arriving after traveling from loc. By default we simply use our actor's sayActorArriving(fromLoc) method.

Display a message saying that our associated actor (typically an NPC whose departure is being viewed by the player character) is departing via conn. By default we simply use our actor's sayActorDeparting(conn) method.

Display a message saying that we're following the player character from oldLoc when our actor is in this ActorState (and the actor is following the player character)