Steering asking disamb vs. giving all descs in X [ambiguous]

I’m painfully aware that the title is rather confusing, but I can’t find better, clearer and conciser terms.

an example will, I hope, explain the potential seriousness of the issue, more serious for me, whose I strive toward giving a large set to synonyms and adjectives to objects and in a very specific, if not peculiar, instance I give a really huge list of component to an object, each with its detailed description:
(notice the (WIP-related) spoiler blur; read if you prefer helping against being spoilered)

X GIRL’S

[gives (correctly) a disambiguation list of, I 'fess up, 20 single objects, all components of the specific instance I cited above]

X HANDS
[spews out the rather long and elaborate descs of four objects, three components and a bodypart]

and, OTOH,

X GIRL’S

[gives (correctly) a disambiguation list of, I 'fess up, 20 single objects, all components of the specific instance I cited above]

HANDS

[gives an ulterior, narrower, disambiguation list of the three components, but strangely NOT the single bodpart]

of course, in my specific work(s), is much better that disambiguation is preferable to this form of ALL, but in our case, is not only annoying, but also potentially spoiling the narrative. (I reckon that occasionally, giving ALL in front of two or three ambigous synonyms/adjectives can be useful from a narrative standpoint.

because one of the WIP is to be released soon anyway, for obvious reasons, I can’t get, for now, the luxury of an deliberate and extensive delving into the innards of TADS & a3Lite’s disambiguation handling, so one can give an hand :wink: into cobbling together an acceptable solution to this issue ?

EDIT: what I need is that the disambiguation question is always asked, instead of spewing out all possible description possible, even if are only two alternatives.

TIA and
Best regards from Italy,
dott. Piergiorgio.

2 Likes

Try adding the following to your code:

modify bodyParts    
    initialLocationClass = nil
;

This effectively gets rid of the bodyParts object in newbie.t, which is what seems to be the source of the problem here.

1 Like

Was already done, circa 4-5 months ago, and I just checked to be safe: these lines are still here, untouched.

Perhaps the real solution lies again in an appropriate use of CollectiveGroup ? As you surely have noticed, is an issue akin to the one I misnamed “automatic plural”, and you suggested this solution, this time applied to the hands depicted in what you now know is a rather detailed painting.

I’ll test this and kept you informed, now I have niced to the maximum (if you know Unix environment, you get what I mean (that is, maximum priority) the placing the appropriate <<[component].discover()>> in the various description…

Thanks, and
Best regards from Italy,
dott. Piergiorgio.

1 Like

You might try using a CollectiveGroup. but getting rid of the bodyParts object worked for me when I tried it out right now. But perhaps you have some other hand (singular) object in scope, which will make the parser decide that X HANDS is meant to refer plurally to the single hand object (or objects) and all the the hands objects as an indefinite plural.

If that’s the case then one solution might be to modify the vocab of your single-hand object(s) along the following lines:

+ Thing 'left hand{handx}';

The trick here is to make the parser think that the plural of this hand object is ‘handx’ rather than ‘hands’ so it won’t be matched by X HANDS, in which case you should see the disambiguation message you want (the output of the description of all the hand objects results from their being at least one singular hand object in scope along with all the plural ones).

2 Likes

Nice idea: Tomorrow I’ll try it as fallback if the CollectiveGroup don’t work as expected.

Good afternoon and night from Italy,
dott. Piergiorgio.

1 Like