I’m working through some more inconsistencies in the Standard Library and have come upon some instances where it would be nice to disable implicit take for certain verbs. For instance, the way the solution to this is working out, if I were to attempt to put on or take off an object that doesn’t have the clothing attribute, the parser will attempt to take it first and then let WearSub() or DisrobeSub() tell the player that the object is not wearable. Does anyone have any ideas on how to preempt or selectively disable ImplicitTake() for such situations?
2 Likes
Not off hand. I normally use no_implicit_actions = true for a few reasons, but primarily because of the really stupid responses that the standard library gives in some situations.
Were you thinking of a number of separate variables such as no_implicit_take_actions, no_implicit_unlock_actions and so on?
I think it should be possible to fix the stupid responses in the standard library by changing the order of the various tests. For example, in your clothing example, it should test whether the object is clothing before doing the implicit take, not after doing the implicit take.
The complication with all of this is that implicit take occurs during ParseToken__(), which is before the grammar has a chance to work.
1 Like
Oh, yeah. I wasn’t thinking of that. That has caused me problems elsewhere, where my before rules never get a chance to run, because the stupid parser wants to jump in and do things based on the tokens in the grammar and the actions never get a chance to do their bit. I’ve had to change the tokens in the grammar to work around the issues.
I’d like to remove that implicit take in the parser. Several of the VerbSub() routines do an implicit take themselves. I’m unsure what I’d break by doing it, but that seems to be the only way to restrain things as I want and to remedy your frustrations.
The implicit take in the parser handles instances of when the token is MULTIHELD_TOKEN or MULTIEXCEPT_TOKEN. That is, a verb that works like this:
Verb 'disrobe' 'doff' 'shed'
* multiheld -> Disrobe;
or
Verb 'insert'
* multiexcept 'in'/'into' noun -> Insert;
This is how I7 evolved. The code in ParseToken__() and Parser Letter G which deals with implicit takes has been entirely removed. Instead, there’s a “carrying requirements” step in between Before and Instead.
I see a few actions do an implicit-take step manually, as well. (eating, putting-on, inserting-into).
It seems to me that the main purpose of the implicit take in ParseToken__() is to deal with the multiheld and multiexcept tokens. As I pondered how it works there, I see how I can simply move the implicit take to verbs where it matters - as you suggest. But then I start thinking of unintended consequences of this. As I think about that, I can see some of them, but I can’t tease out exactly what would happen.
a minor point is, if I’m correct on english, there’s also “take off obj from obj”, e.g. “take off cloak from peg”, so I suspect that there’s another worm in this “take off” can…
Best regards from Italy,
dott. Piergiorgio.
The natural English phrasing would be “take X off Y” or “take X from Y”. The standard library parser already handles those cases – there’s no problem there.