Topic for AskTellTopic defined in separate file?

Authoring TADS
1

Hi,

I like to keep my sources in separate files for my TADS projects (e.g. one file for conversations with Joe, one file for the conversation with Sally, one for the area around the stream …)
All these separate files are “included” in the main file with several #include commands.

But I ran into a problem concerning the conversations. When I use AskTellTopic for example and make a reference to the “burner” (which has it’s definition in a separate file) and ask the conversation target about burner, when conversation falls through to the DefaultAskTellTopic node. If I define the burner in the same file as the conversation itself, everything works fine.

++ AskTellTopic @burner
    "<q>Do you know {the burner/him}, the old fellow who works in the forest?</q>
    you enquire innocently.<.p>
    <q>He's not <i>that</i> old,</q> she replies coyly."
;

How exactly does the compiler handle separate files when he does his work. I was under the impression, that all files are stitched together as one large single file, which will be compiled afterwards. Is this assumption false?

Jens

2

Hm, I made a little test project, that sets up exactly the situation as I described above, but in this project everything works as it should be. Will do a little more testing …

Jens

3

Ok, now I figured out what causes the AskTellTopic to give the wrong answer.

hunter : Person 'hunter' 'hunter'
  @insideShop
  "Dressed greenish, he looks like a hunter. "
    globalParamName = 'hunter'
  isHim = true
;

burner : Person 'charcoal burner' 'charcoal burner'
  @fireClearing
  "It's rather difficult to make out his features under all the grime and soot. "
  properName = 'Joe Black'
  globalParamName = 'burner'
  isHim = true
;

++ AskTellTopic @hunter
    "<q>Do you know {the hunter/him}, the old fellow who works in the forest?</q>
    you enquire innocently.<.p>
    <q>He's not <i>that</i> old,</q> she replies coyly."
;

++ AskTellTopic @burner
  "<q>Do you know {the burner/him}, the old fellow who works in the
   forest?</q> you enquire innocently.<.p>
  <q>He's not <i>that</i> old,</q> she replies coyly. "
;

The hunter and the burner are not located in the same rooms. If I ask the shopkeeper “ask about burner” I get the default answer for an unknown topic.
If I ask about the hunter, I get (as expected) the hunter-specific answer (“Do you know …”)

Now, if I move the burner from “fireClearing” to “insideShop”, recompile and ask about the burner, I get the burner-specific answer, just like I got for the hunter before.

Hm, is this a bug or am I doing something wrong here?

Jens

4

If an object is not in the same location, then it’s assumed to not be known about because it’s not been seen and cannot currently be seen. The Actor class has:

knowsAbout(obj) { return canSee(obj) || hasSeen(obj) || obj.(knownProp); }

You can explicitly set objects as known by everyone by setting their isKnown property to true.

/*
 *   Flag: this object is explicitly "known" to actors in the game,
 *   even if it's never been seen.  This allows the object to be
 *   resolved as a topic in ASK ABOUT commands and the like.
 *   Sometimes, actors know about an object even before it's been seen
 *   - they might simply know about it from background knowledge, or
 *   they might hear about it from another character, for example.
 *   
 *   Like the 'seen' property, this is merely the DEFAULT 'known'
 *   property that we use for actors.  Each actor can individually use
 *   a separate property to track its own knowledge if it prefers; it
 *   can do this simply by overriding its isKnownProp property.  
 */
isKnown = nil

Note that the documentation above is wrong (typo). It’s knownProp, not isKnownProp. By default, the Actor class (in actor.t) sets:

/*
 *   My 'known' property.  By default, this is simply 'known', which
 *   means that we don't distinguish who knows what.
 *   
 *   As with 'seenProp' above, if you want to keep track of each NPC's
 *   knowledge separately, you must override this property for each
 *   NPC who's to have its own knowledge base to use a separate
 *   property name.  For example, if you want to keep track of what
 *   Bob knows individually, you could define 'knownProp = &bobKnows'
 *   in Bob.  
 */
knownProp = &isKnown

A couple lines above that, you can also see that there’s these methods:

knowsAbout(obj)
setKnowsAbout(obj)

This should hopefully make it clear how to have actors know about some things but not about others. Usually, you don’t need control that is so fine-grained as to have to change knownProp.

1 Like