Prevent "drop all" from considering one particular item

#1

Man, it’s easy to come up with a ton of questions really quickly when you start working on a project. I hope I don’t get annoying here.

I searched and couldn’t find anyone else who had asked about this, or an answer that would solve the problem.

The player has a personal key to their house. I don’t want them to be able to drop it, in case at some point later in the game I put in a location only temporarily accessible, and forget about this key that could leave them in an unwinnable state or something. So I do

Instead of putting or inserting or dropping your personal key, say "The last time you left your key lying around, you couldn't find it again, and had to go through the embarrassing process of getting everything re-keyed."

So far so good. (This does cover all “discards,” correct?)

But if the player wants to “drop all,” I don’t necessarily want them to see a cutesy message every time it tries to drop their personal key. So I want to remove it from consideration.

I did this:

Rule for deciding whether all includes your personal key when putting or inserting or dropping: it does not.

Which works fine when the player is carrying several things:

But produces this bizarre behavior when the player is only carrying their key (actions on):

Strangely enough, putting all on or putting all into correctly produces the result “there are none at all available!” It’s just that dropping is magically changing into throwing the object at itself.

Any thoughts?

Is this even a good idea, to exclude something from “all” when the player would expect to see “all” inventory items represented in the attempt?

EDIT: I went ahead and submitted this as a bug because the behavior definitely doesn’t seem intended.

0 Likes

#2

Working with “all” can be tricky, and this is an awkward edge case in the parser. (Briefly, it can’t match DROP ALL to the dropping action, since ALL doesn’t match any objects. So it does its imperfect best to match your command to the throwing it at action instead, since this is another action taking the verb DROP.)

I’m not sure disregarding the key from DROP ALL is a good plan. As a player I’d rather be told. Maybe after the first time it would be OK.

Anyway, here’s one way to do it.

A multiple action processing rule when dropping:
	if the personal key is listed in the multiple object list and the number of entries in the multiple object list is at least 2:
		let L be the multiple object list;	
		remove the personal key from L;	
		alter the multiple object list to L.

One problem is that if you are carrying exactly two things, you’ll get the response

(with no itemization) so the player won’t know what they dropped (and didn’t drop). You could override this behaviour as follows:

Before dropping when the number of entries in the multiple object list is 1:
	say "[noun]: [run paragraph on]".
0 Likes

(Petter Sjölund) #3

Another way to at least get rid of the bizarre response is this:

Rule for deciding whether all includes your personal key when putting or inserting or dropping: unless the number of things carried by the player is 1: it does not.which gives[code]>i
You are carrying:
a hat
your personal key

drop all
hat: Dropped.

drop all
(your personal key)
The last time you left your key lying around, you couldn’t find it again, and had to go through the embarrassing process of getting everything re-keyed.
[/code]

0 Likes

#4

Thank you both. I really like that solution, angstsmurf. Particularly because if the player is wondering “hey, why didn’t drop all drop my key too?” and they try it again, they will then find out.

It’s perhaps too much effort spent on such an edge case, but also nice to see a few solutions.

I wonder why failed putting and inserting don’t try throwing, or even dropping? The fact that dropping goes to throwing seems silly, since throwing is sort of a useless action in default Inform and often a useless action in most stories as well. Nobody likes throwing! :slight_smile:

0 Likes

(Petter Sjölund) #5

I guess it makes some kind of sense that THROW STONE is a synonym for DROP STONE. But because THROW and DROP are listed as synonyms in the library, DROP STONE AT CEILING becomes synonymous with THROW STONE AT CEILING, which makes less sense (and defies gravity).

0 Likes

(matt w) #6

This looks like another parser bug that Graham marked “won’t fix.” There, the issue was that once the parser kicked away from the proper “drop” line it got to “drop this in that” which was inserting.

I also agree that nobody likes throwing! Or at least, nobody likes trying “throw rock” and being told that you’ve put the rock down.

0 Likes

#7

I would argue this is much less desirable than implicitly attempting to insert, particularly because it’s not just throwing the object…it’s throwing it at itself. :open_mouth: :question:

Pure luck that the resulting parser error “futile” is simple and blunt enough that it almost fits and doesn’t reveal the strangeness going on under the hood, but surely that can’t be intended.

0 Likes