++ paper: Thing ‘piece of paper’
"A piece of paper. "
As expected (because it isFixed) the trash can is not listed in the room description; but I don’t want its contents listed either (whatever they are) – and yet they seem to be. So after the room description I get “In the trash can you can see a piece of paper.”
And if the player sits on the chair, then I get (printed at the end of the room description) “You are on the chair.”, although again I don’t really want that (not least because I already get, sensibly, “(on the chair)” after the room name, so the information is redundant).
I had assumed that contentsListed or contentsListedInLook would take care of these things, but they don’t seem to; I have not defined any variant lister. Am I barking up quite the wrong tree? Which tree should I be heading for?
I get the same results you do. I had not updated from 1.3 to 1.4, so I did that … but that didn’t help. I still get the same unsatisfactory output with your test code. In looking through the library code, I don’t see an obvious problem … but then, I probably wouldn’t see it even if it were obvious.
Looks like this is an issue Eric Eve will need to sort out.
Thanks, Jim. I am using v 1.4. The most likely explanation is that I am simply going about this the wrong way, I expect. There’s no rush, anyway, and I’ll hope Eric can put me straight when he’s next around.
Edited to add: In case it matters, if I set the paper to isListed=nil it doesn’t get listed in the trash can, but then it doesn’t get listed either when you look explicitly in the trash can (which reports that it contains “nothing interesting”) or when you remove it and just drop it; the player Actor is reported to be on the chair, however, whether or not I set isListed=nil explicitly on that Actor (though I had sort-of-assumed that was unnecessary in any case).
Very helpful, thank you. Here’s what I’m finding, using the Watch Expression window. When that line is reached, the value of obj.(lister).contentsListedProp is &contentsListedInLook. It’s not nil.
This is presumably due to a T3 syntax detail, about which I know very little. But I’ll try editing the library code a bit and see what I can find out.
According to the T3 manual: “When applied to a property name, [the unary &] operator simply yields the property ID value for the named property. It does not invoke the property. This operator has no side effects.” That’s normally what one wants, but in this particular line of code, one wants the property to be evaluated. And I have no idea how to force that to happen.
Ah, sorry, then maybe || (obj.(lister).contentsListedProp) == nil. I’m not testing it, nor reading coresponding part of the library. But Jim said obj.(lister).contentsListedProp yields property id so parentheses should help to evaluate.
I tried that. It didn’t work. What’s needed is a way to evaluate a property based on its address (the symbol starting with &). I don’t know how to do that. I looked up val and eval in the Library Reference Manual – no help there.
and the fix for the condition in adv3lite thing.t is:
|| obj.(obj.(lister).contentsListedProp) == nil
And now some explanation - obj is trashCan. local variable lister is a property id &roomSubContentsLister. So when we evaluate obj.(lister), we got lookContentsLister. It is an equivalent of evaluating obj.roomSubContentsLister, but the point is we have a variable saying which property to evaluate on obj object, so it is not hardcoded. So now we look for contentsListedProp on lookContentsLister and we get &contentsListedInLook which is another property id. So we add the whole statement into yet another parenthesis to evaluate it on obj, therefore we evaluate obj.contentsListedInLook which is compared to nil.
This will lead to the following transcript:
A bare room.
You can see a chair here.
A trash can. In the trash can you see a piece of paper.
Thanks, but I’ve already added the fix to my own copy of the code; I just haven’t got round to pushing it to GitHub yet. I’ll probably get round to it at the weekend when I’ve had a chance to run a couple of tests and to see if I can fix the other bug (the one relating to a ConsultTopic not matching on a regex; I’ve worked out the cause, I just need to work out the solution).