adv3Lite: AskTellTopic not Firing

Here’s a pretty pickle. I’ve given an NPC two (actually more, but we’ll look at two) AskTellTopic entries. Both are directly in the NPC object, because there’s no reason to limit either of them to a single ActorState. Both are StopEventLists. As far as I can see, the code is identical except for the text contents. But one of them fires, and the other doesn’t. Both are objects that the player has seen. The one that doesn’t fire is about an object that starts out isHidden – but that can’t be the explanation for the malfunction, for two reasons. First, at the point when the PC asks about the object, it’s no longer hidden, and is in plain view. (It can be examined.) Second, I get the same malfunction if I comment out isHidden=true on the object.

Here’s the code. Can your eagle eye spot any difference?

[spoiler][code]

  • AskTellTopic, StopEventList @woodenIndian
    [
    'What do you know about the wooden Indian? you ask.<.p>I think he’s
    really creepy, {the betsy} replies. Sometimes I think he’s staring
    at me. I expect you probably think I’m crazy, but I can’t get over that
    feeling. ',
    'You attempt to pursue the topic, but {the betsy} only murmurs vaguely. ’
    ]
    ;

  • AskTellTopic, StopEventList @rubyRing
    [
    'Trying to sound casual, you point at the ring {the betsy} is wearing. That’s a
    very nice ring, you comment. Can I ask where you got it?<.p>
    She holds out her hand proudly to admire the ring, and beams smugly. My boyfriend gave it to me,
    she proclaims. ',
    'I can’t help thinking the ring looks a lot like one I used to have, you say,
    trying to keep your voice casual. I lost it. In a beauty shop.<.p>
    Just for a moment, you fancy you see a flicker of guilt and terror cross her face. Well,
    my boyfriend gave me this one, she says firmly. ',
    'Pestering her further about the ring is unlikely to do any good. Whether she stole it or only
    found it, she’s never going to admit it. Damn! ’
    ]
    ;[/code]
    You can ask about the wooden Indian – no problem. But asking about the ruby ring flat-out doesn’t work. I get the DefaultAskTellTopic response.[/spoiler]

My immediate guess is that the problem lies elsewhere, in which case there’s not enough to go on in the code you’ve posted. Can you post the definition of the rubyRing and woodenIndian objects?

Another thing to check is whether the player character knows about the rubyRing at the point he’s trying to ask about it. In adv3Lite as in adv3 an object moved into plain sight in the presence of the player character may bypass the mechanism that updates what the player knows about and has seen. What is the value of rubyRing.known at the point when you’re trying to ask about the ruby ring? (You can use the command EVAL rubyRing.known to test it if you like).

Got it – thanks. It’s very odd to me that the player can examine something and read the desc, yet the thing remains known=nil. In this particular case, the ring is in the room when the player enters, but is hidden. In addition, an NPC is wearing the ring.

It’s the latter factor that turns out to be the source of the problem. If the ring is simply in the room, but hidden, setting it to isHidden=nil does not make it known. In addition, if it’s never hidden at all, but is being worn by the NPC, it’s still not known.

This is, I think, a mistake in the library. The sequence of events (I’ve been testing this, and it’s pretty clear) is this: The player does an action (knocking on a door) that causes her to be swept into the room:

me.moveInto(beautyParlor); beautyParlor.lookAroundWithin();

This appropriately sets known=true on everything in the beautyParlor – EXCEPT on items worn or carried by an NPC who is in the room. The item in the NPC’s inventory is not hidden; it can be examined; but it’s still not known=true. As a result, the NPC can’t respond to AskTellTopic inputs about it.

But how could it? Changing the value of one property can’t automatically update the value of another (unless they’re defined to be linked, but seen can’t be linked to isHidden in this way).

However, I’ve now modified the discover() method (which is what should be called to make isHidden nil) so that calling it marks the object as seen provided the player character can see it at that point in time.

Arguably, it’s a matter of what one thinks the library ought to do here, since the library doesn’t automatically list either the player character’s inventory or that of any other NPC in the location when showing a room description (which is why none of the contents of these inventories is marked as having been seen in response to a room listing). Does the player character know what s/he or anyone else is carrying before s/he explicitly looks to see? Arguably that may be the more intuitive behaviour, so I’ve changed it to that for now (but I may subsequently add a flag property to let game authors change this behaviour).

Anyway, these changes along with one or two others (including the lister property scheme discussed in the other thread) have been incorporated in the latest version just uploaded to GitHub.

That makes sense.

That makes sense … but in the particular situation in my game, the object is mentioned as being in the NPC’s possession as part of an AgendaItem. Subsequent to that, it’s not hidden, so the player can examine it … yet it’s still not known (unless my code also makes it known, which I have now done). As an alternative, possibly printing the description of an item should always set it to known, since it’s hardly possible that the PC could see and examine an object without it becoming known in a conceptual sense.

Of course, that might still get fouled up (once in a blue moon) if gPlayerChar was being changed during the course of the game and different characters had different ‘known’ properties.

Agreed, except that “known” should be “seen” here (which in turn makes it “known”). I’ve now incorporated this into the Examine action.