Identity Confusion with 'which do you mean?' Activity

[grbaptist]

Hi everyone,

I’ve come across an interesting problem when trying to identify a specific object out of a list of similar objects. Here is the code:

A monster is a kind of person. A monster has a number called identifier. Understand the identifier property as referring to a monster.

A skeleton is a kind of monster. 

Rule for printing the name of a skeleton:
	say "[printed name] [identifier]".

Instead of attacking:
	say "You attack the [noun]."

When play begins:
	allocate identifiers to skeletons;
	
To allocate identifiers to (name of kind of value K):
	let current identifier be 1;
	repeat with monster running through K in the location:
		now the identifier of the monster is the current identifier;
		increase current identifier by 1;
		say "[monster][line break]".

The Graveyard is a room. In the Graveyard are 15 skeletons.

When I follow through this sequence of commands I am unable to attack the first skeleton. I can attack any of the others, just not the first.

attack skeleton
Who do you mean, the skeleton 14, the skeleton 12, the skeleton 10, the skeleton 8, the skeleton 6, the skeleton 4, the skeleton 2, the skeleton 1, the skeleton 3, the skeleton 5, the skeleton 7, the skeleton 9, the skeleton 11, the skeleton 13 or the skeleton 15?

attack 1 skeleton
(the skeleton 14)
You attack the skeleton 14.

attack 2 skeleton
You attack the skeleton 2.

attack 13 skeleton
You attack the skeleton 13.

What seems to be happening is that skeleton 1 is being matched to the first one appearing in the ‘Who do you mean?’ list.

Interestingly though if I type the following it works:

attack skeleton 1
You attack the skeleton 1.

Anyone have an idea of the reason behind this?

Thank you.

[Erik_Temple]

I suspect that this is a similar bug to this one:

inform7.com/mantis/view.php?id=488

(see eMacsUser’s comments at the bottom.)

I don’t know whether this “1” thing is a new feature or if it’s an old feature that’s behaving badly, but you’re probably stuck with the problem until a new build of Inform is released. Or until someone identifies the bug in the template layer and specifies a patch.

–Erik

[Ron_Newcomb]

Maybe because it’s parsing as “attack a skeleton”, much like “take 1 coin” when there are several indistinguishable coins?

[Erik_Temple]

Yes, I think that’s it. In the bug I linked to, the “1” is parsed in that sense when it ought not to be. Here, it should be parsed that way, I guess (though it’s not a feature I’ve ever used in any game), but it seems to me that the author should also be able to disable that reading of “1”.

–Erik

[Felix_Larsson]

I tried the same thing in 5Z71 and got this:

attack skeleton
Which do you mean, the skeleton 14, the skeleton 12, the skeleton 10, the skeleton 8, the skeleton 6, the skeleton 4, the skeleton 2, the skeleton 1, the skeleton 3, the skeleton 5, the skeleton 7, the skeleton 9, the skeleton 11, the skeleton 13 or the skeleton 15?

attack 1 skeleton
You attack the skeleton 1.

attack a skeleton
(the skeleton 14)
You attack the skeleton 14.

attack one skeleton
(the skeleton 14)
You attack the skeleton 14.

So maybe the new behaviour qualifies as a bug after all.

Note:[rant]I had to modify the source text to make it compile on the earlier build, but I don’t think that should make the difference:

To allocate identifiers to skeletons: let current identifier be 1; repeat with horror running through skeletons: now the identifier of horror is the current identifier; increase current identifier by 1; say "[horror][line break]". [/rant]

[Ron_Newcomb]

I’m less inclined to believe it a bug than the problem is being tackled in an unusual way. How about just:

A skeleton is a kind of animal.  There are 15 skeletons.

And then defined various properties on skeletons such as “damaged”, “dinged”, “broken”, and “most recently attacked” on them, and expose those adjectives to the player. It would solve the repetitive narrator issue the original sample has.

Mind, I haven’t looked at the problem in any depth.

[Erik_Temple]

I do think that this is a bug. Inform should be prioritizing its parsing decisions so that, when the grammar allows for a command that has a user-defined “1” vs. a command that automatically understood “1” to mean a quantifier (as in “Take 1 goblet”), the former is always chosen. In both the bug report I linked to and the test Felix posted (thanks, Felix!), 5Z71 did prioritize things that way, and the situation was handled gracefully. In contrast, when 6G60 gives priority (unintentionally, I’m sure) to the “1” as a quantifier, there is no way for the author to override that behavior, at least without digging deep in the internals of the parser.

–Erik

[grbaptist]

Thanks everyone.

Ron,

I do agree that the repetition of this narrative is poor but I can assure you this isn’t my final product. The code was just helping to clarify my problem.

Thanks again.