Having trouble with rear containers in adv3lite

Authoring TADS
1

I’m learning adv3lite, and am attempting to make a refrigerator which can have things on, in, or behind it. However, I don’t understand the behavior I’m getting here with regards to the “behind” portion of it. My code seems simple enough to me:

+fridge: Thing 'broken refrigerator;; fridge'
    ""
    remapIn: SubComponent {
        isOpenable = true
    }
    remapOn: SubComponent { }
    remapBehind: SubComponent { }
    dropItemsBehind = nil
;
++cables: Thing 'nest of cables'
    sLoc(Behind)
;

The fridge and cables both show up in the room description, but when I attempt to manually look behind the fridge, I get this:

>x fridge
You see nothing special about the broken refrigerator.

>l behind fridge
Which do you mean, (1) a broken refrigerator or (2) the closed broken
refrigerator?

>1
You find nothing of interest behind the broken refrigerator.

>l behind fridge 
Which do you mean, (1) a broken refrigerator or (2) the closed broken
refrigerator?

>2
You find nothing of interest behind the broken refrigerator.

I don’t understand 1) why there is a disambiguation message, and 2) why neither option shows anything behind it when you look there.

1 Like
2

Hi,

Try changing the cables object to:

++cables: Thing 'nest of cables'
    subLocation = &remapBehind
;
1 Like
3

I suspect this is because the remapIn is separately matching, in addition to the fridge itself. I’m…not entirely sure why, but that might explain why one of the choices specifies “closed”.

It’s been a while since I’ve used Adv3Lite, and admittedly I think my brain truncated a lot of my knowledge while dealing with a few back-to-back crises, but I remember a SubComponent copies the vocab of its parent for itself, which might be why both are matching your input.

4

After changing this I now get Behind the broken refrigerator you see a nest of cables. (which had previously only been printed in the room description) as a response to x fridge. But I also now get that response when I change it back to the macro. I didn’t change anything else and I’m not sure why I didn’t get that response before. Nothing else changes, though (neither the disambiguation message nor the response to looking behind the fridge).

That’s what it looked like to me, but I figured I must be doing something wrong for that to happen, because it doesn’t seem like the intended behavior based on how this feature is used in the Learning T3Lite manual. Do you know if there is some way to work around it?

1 Like
5

Yes, though this gets a bit weird.

From this part of the docs (see “filterResolveList()”)…

filterResolveList(np, cmd, mode)
{
    if(np.matches.length > 1)
        np.matches = np.matches.subset({m: m.obj != self});
}

If you apply this to the SubComponent, then if it matches along with anything else, it assumes that it must not be the match, and voluntarily removes itself from the list of matches. If, somehow, it is the only thing to match, then it accepts being matched.

Where it gets weird: This will make it nearly impossible to match the SubComponent, so what you’ll need to do is remap all opening and closing actions attempted on the parent fridge object to the SubComponent, since the parent fridge object will be solely matched every single time. You’ll also want to remap actions for PutIn and TakeFrom (and any other actions which involve openable containers).

This is something I had to do for a very similar kind of complex container in I Am Prey. I actually wound up using filterResolveList quite a lot to nuance exactly when certain objects would voluntarily allow themselves to be matched.

Complex containers are very weird to implement and can cause a bit of headache, but they are powerful in service to intuitive handling by the player, once you get all the details ironed out.

EDIT: Actually, just start with filterResolveList, and then if opening and closing the fridge doesn’t work, then remap the actions. I think a SubComponent automatically remaps the actions from the parent.

3 Likes
6

Just adding the filterResolveList appears to have done it. Looking behind it now correctly displays the contents of the rear container and no longer shows a disambiguation prompt. Thanks for the help. :slight_smile:

1 Like
7

I regard this as a bug in the library, inadvertently introduced in version 2.1 to fix problems with enterable SubComponents (if the actor is inside an enterable Subcomponent you might want the parser to prefer that SubComponent to its parent object).

For some reason I haven’t been able to discover, this bug only seems to occur when an object has more than two SubComponents. Rather than trying to figure out why this should be, I’m fixing it by incorporating the fillterResolveList method suggested above into the library’s version of SubComponent, with an exception for when the actor is inside a SubComponent.

5 Likes
8

Your work continues to be wholeheartedly appreciated, Eric! ^^

2 Likes
9

Fully concur with Joey’s last post, but Joey’s earlier post is more important, because give an important insight in a major problem I have (players of The Portrait has experienced the “combinatorial disambiguation explosion”, but I leaved it here, because reviews has revealed that in the end, was involuntarily a major QoL for players) but in the “main dish” will led to a larger combinatorial explosion, potentially overflowing the hardcoded limits (20 entries) of the disambiguation list, a major no-no, stemming from the two major NPC being also in the scope… currently I’m fooling with badness, but handling via filterResolveList is a very interesting, if not promising, alternative…

I’ll wait how Eric handle the bug, but in meantime I wonder if filterResolveList can change on the fly the badness level, storing somewhere the original level and elsewhere at the end of the parsing, the original badness is restored… but are experimentations to be done after June…

Best regards from Italy,
dott. Piergiorgio.

1 Like