Well, this is odd. I was going to tell Peter that for taking, the parser does prefer taking something you’re not holding, as you can see if you modify Mike’s example to put a gem on the floor. But it prefers taking something you’re holding over taking something that’s part of something else.
But that’s not strictly true. If you’re holding two gems, then it prefers taking the gem that you’re not holding, even though it’s part of something else. That is most mysterious behavior.
Anyway, I thought it might be friendly to automatically redirect an attempt to take a gem that you’re carrying to a visible gem, even if it’s embedded. I did something like that in Tea and Toast where the game would try to make you fill the same teacup over and over unless I grabbed it by the nose and forced it toward a better choice.
But… in this case, when I tried to redirect the taking action using a Before rule, it ran after all of Mike’s nice clarifying the choice of the parser stuff, so the parser still clarified its choice of the gem you were holding (even though you’re about to take a different one). This is bad! So I set up an ugly solution–before clarifying the choice of the parser, it checks to see whether the parser should be choosing a different gem. If so, it sets a flag, picks the gem it should be choosing, and then the clarifying the choice of the parser rule checks to see whether you’re really going to be working with a different gem, and the Before rules redirect the action to the new gem.
So (new code after the test script):
[code]Test Room is a room.
A gem is a kind of thing.
A gem can be embedded or loose. A gem is usually loose.
Understand “stuck” as embedded. Understand “free” as loose.
Understand the embedded property as describing a gem.
Before printing the name of a gem while clarifying the parser’s choice of a gem, say "[if embedded]embedded [otherwise]loose “.
After printing the name of a gem (called G) while clarifying the parser’s choice of a loose gem:
if G is carried by the player, say " that you are carrying”;
if an embedded gem (called EG) that is not G is visible, say “, not the gem stuck in [the random thing that incorporates EG]”.
Understand “in/from/out of/-- [something related by reversed incorporation]” as a gem.
A boulder is here. “A giant boulder rests nearby. Embedded in the stone’s side is a gem.” The boulder incorporates an embedded gem.
Instead of taking a gem that is part of something, say “It’s stuck in [the random thing that incorporates the noun]! OMG!”
The player carries a gem.
test me with " i / take gem / take stuck gem / take embedded gem / take gem out of boulder / take embedded gem from boulder / take the gem stuck in the boulder / drop gem / take gem"
Before taking a carried gem when substituting a different gem is true:
try taking the substituted gem instead.
The substituted gem is a gem that varies.
Substituting a different gem is a truth state that varies. Substituting a different gem is false.
Every turn: now substituting a different gem is false.
Before clarifying the parser’s choice of a carried gem while taking when the player can see a gem that is not carried (called jewel):
now substituting a different gem is true;
now the substituted gem is jewel.
For clarifying the parser’s choice of a gem when substituting a different gem is true:
say “([the substituted gem])[command clarification break]”.[/code]
If there are multiple other gems to take, this will arbitrarily choose one (the first one in source code order, I think), but there’s no way to force disambiguation that I know of. Maybe my biggest discontent with Inform 7 is that everything about disambiguation and the parser choosing things is wedged so deep into the parser that there’s no good way to modify it, really; but as has been explained to me the reason is that it’d be really hard to change that stuff without potentially breaking a lot of code.