I was wondering if someone could explain this behavior to me before I start mucking around with the output.
If you “move” an object to a location, Inform considers this item dropped. If you pick up an item and drop it, Inform considers this item dropped. If you then pick up the item and place it on a table, Inform considers this item placed.
So…
When the scene opens, there’s an item on the table. If I try to drop that item, I get a response from dropping action #2, which tells me correctly that I ain’t got it.
During the course of the scene, I move an item to that location. If I try to drop that item, I get a response from dropping action #1, which tells me that it’s already there. If I then pick up said item, place it on the table and try to drop it again, I get dropping action #2.
Now… Is there a reason to have two separate dropping messages? Can someone give me an example of where this might be necessary?
Also, since I’m finicky and I don’t like the idea of my freshly moved item being “dropped” before it’s ever been touched, is there a way to make the item not flagged as dropped without having to pick it up and place it somewhere first?
I don’t think that objects really are flagged as dropped or undropped (at least not by the Standard Rules). But they are flagged as “handled” or not. And a thing that hasn’t been handled by the player, can’t have been dropped by him/her either (at least not during game-play).
When you try dropping something in scope that you’re not currently holding, you get message 1 if that thing is in or on the same thing as you are without either one being in or on anything that the other is not in or on.
If you or the thing is in or on something that the other is not in or on, you get message 2.
I can see that message 1 could sometimes be inappropriate as replacement of message 2. But message 2 seems general enough to replace message 1. On the other hand, message 1 suggests that the thing you try to drop is actually there for the taking, whereas message 2 would perhaps be given even if the thing in scope is not actually touchable.
"Dropping Messages" by I4L
The Shop is a room. "There are various and sundry items lying about."
There is a screw.
A table is a supporter in the Shop.
A toolbox is on the table.
Instead of examining the toolbox for the first time:
say "A screw falls out and is lying on the floor.";
Move the screw to location.
Test me with "drop toolbox/x toolbox/drop screw/get screw/put screw on table/drop screw/get screw/drop screw/drop screw"
This results in:
Dropping Messages
An Interactive Fiction by I4L
Release 1 / Serial number 111127 / Inform 7 build 6G60 (I6/v6.32 lib 6/12N) SD
Shop
There are various and sundry items lying about.
You can see a table (on which is a toolbox) here.
>test me
(Testing.)
>[1] drop toolbox
You haven't got that.
>[2] x toolbox
A screw falls out and is lying on the floor.
>[3] drop screw
The screw is already here.
>[4] get screw
Taken.
>[5] put screw on table
You put the screw on the table.
>[6] drop screw
You haven't got that.
>[7] get screw
Taken.
>[8] drop screw
Dropped.
>[9] drop screw
The screw is already here.
>
If you type “drop screw” and the screw is on the floor, the response is “The screw is already here.” If the screw is on the table, the response is “You haven’t got that.” This isn’t based on flags, it’s based on where the object is.
Makes sense as far as a technical explanation of what’s happening. I can’t say that I care for the output. So… I guess I’ll see what I can do about that.
One way of thinking about it is this: you’re trying to put the screw on the floor. If the screw is on the table, you get message 1, which tells you that you fail – you can’t put the screw on the floor unless you’ve already got it. If the screw is on the floor, you get message 2, which tells you that you don’t need to try – you don’t have to put the screw on the floor, because the screw is already on the floor.
Message 2 is a bit confusing, because it tells you that the screw is “already here,” which is true even in case 1 (it’s here, it’s just not on the floor). So one way to fix it might be to change it to “The screw is already on the floor/ground,” though that might require implementing the floor/ground as an object.
[I was going to compare this to similar messages for putting things on things, but it turns out that with the Standard Rules you won’t trigger those messages; if you try “put screw on table” when the screw is already on the table, you wind up taking the screw and putting it back on the table, instead of being told it’s already on the table. That seems like something worth hacking the Standard Rules to avoid, if you have the wherewithal.]
Right, I tried putting it on the floor and was told that there was no such thing, which is bothersome.
I understand now the need for the two separate error messages. However, I do think they need to be phrased differently. So I’m gonna go ahead and do that, I guess.
Can someone with a more critical/knowledgable eye point out any potential issues with this type of setup?
"Dropping Messages" by I4L
Include Default Messages by Ron Newcomb.
Use library message alerts.
Table of custom library messages (continued)
library-action library-message-id library-message-text
dropping action 1 "The [noun] is already on the [if player is in Indoors Area]floor[otherwise]ground."
dropping action 4 "You drop the [noun] on the [if player is in Indoors Area]floor[otherwise]ground."
-- 26 "You pick up the [noun]."
putting it on action 8 "You place the [noun] on the [second noun]."
-- 30 "You don't see a [noun] here."
taking action 1 "You pick up the [noun]."
examining action 2 "You see nothing of importance about the [noun]."
Indoors Area is a region. Shop is in Indoors Area. Outdoors Area is a region. Front Yard is in Outdoors Area.
The floor is a backdrop. The floor is in Indoors Area. The sky is a backdrop. The sky is in Outdoors Area.
The Shop is a room. "There are various and sundry items lying about."
There is a screw.
A table is a supporter in the Shop. A toolbox is on the table.
Instead of examining the toolbox for the first time:
say "A screw falls out and is lying on the [if player is in Indoors Area]floor[otherwise]ground.";
Move the screw to location.
Test me with "get toolbox/drop toolbox/x toolbox/x screw/get screw/drop screw/get screw/put screw on table/put screw on table/get screw/n/drop screw"
Front yard is a room. "Your front lawn is trimmed nice and proper." Front yard is north of the Shop.
It does say “You can see a table (on which is a toolbox) here.” This aggravates me because the library message #119 is just “(on”, it seems. So taking it out results in “You can see a table which is a toolbox) here.” I haven’t found this message yet, as searching the Standard Rules for 119 doesn’t turn up anything.
I can set the table to scenery and it has a more attractive output, but if I want the supporter to be something that can be moved, this obviously doesn’t work.
Well, first problem (test your examples before making them public) was the missing periods. That’s been fixed. Second problem is since the floor is set as a backdrop, trying to put something on it results in being advised that doing so would achieve nothing.
Also, the game will respond with dropping action messages number 1 and 4, even when the player is in a container or on a supporter, in which case “floor” or “ground” may not be appropriate.
Ah, you definitely would want something like this (untested):
[code]Check an actor putting something on (this is the convert put on the floor to drop rule):
if the second noun is a floor:
convert to the dropping action on the noun.
The convert put on the floor to drop rule is listed after the convert put to drop where possible rule in the check putting it on [or whatever it’s called] rulebook.[/code]
Or if you like you could rewrite the convert put to drop where possible rule to include that case as well.
You might want to implement the ground as a similar backdrop in Outdoors Area.
I think that the noun variable is not yet set, when the miscellanous library message number 30 is called: so “X SREW” (etc.) will give you “You don’t see nothing here.”
It’s worth noting here that the “handled” property is only set at the end of a turn, not after taking something. So if the screw is in the location and you give the command “put screw on table,” the screw will not be handled even if the command is successful.