Need some advice on what’s surely a very basic thing but having a hard time figuring out the syntax. The player already has a Silver Mug. There’s a rack of mugs in the Cargo. The player is to take a second mug from that rack. Ideally the mug they receive is undescribed until that moment (or they examine the rack and then the “recommended” one appears). That is the Yellow Mug.
Actually, things are working fairly ok with the code below, but I’m running into two issues:
When you type “x mugs” you receive the response “You can’t use multiple objects with that verb.” How do I dictate that response so that it describes the rack (or asks the player to be more specific)?
When you type “take mug” it behaves properly, giving the Yellow Mug, but also prints a “(the silver mug)” message beforehand which isn’t correct.
Cargo is south of Cockpit.
Cargo_HangMugs is a supporter in Cargo. Understand "row of coffee mugs" and "row of mugs" and "rack of mugs" and “new mug” and “row of mugs” and “coffee mugs” as Cargo_HangMugs. Cargo_HangMugs is fixed in place. Printed name of Cargo_HangMugs is "row of coffee mugs". The description of the Cargo_HangMugs is "An assortment of mugs hanging on hooks.[RevealYellowMug].”.
To say RevealYellowMug:
Now the Cargo_YellowMug is described.
A mug is a kind of thing. The Cargo_YellowMug is a mug. The Cockpit_SilverMug is a mug. Understand "mug" as a mug.
The Cargo_YellowMug is a thing. The Cargo_YellowMug is on the Cargo_HangMugs. The Cargo_YellowMug is undescribed. Understand "yellow mug" as Cargo_YellowMug. Printed name of Cargo_YellowMug is "yellow mug". The description of the Cargo_YellowMug is "Her favorite mug."
The Cockpit_SilverMug is a thing. The Cockpit_SilverMug is carried. Understand "silver mug" as Cockpit_SilverMug. Printed name of Cockpit_SilverMug is "silver mug". The description of the Cockpit_SilverMug is "My favorite mug."
Instead of taking Cargo_HangMugs:
say "[if the player has the Cargo_YellowMug] You have enough coffee mugs already.[otherwise if the Cargo_YellowMug is described and the player does not have the Cargo_YellowMug]You take the yellow mug off a hook.[GiveCoffeeMug][otherwise if the Cargo_YellowMug is undescribed]You take a yellow mug off a hook.[GiveCoffeeMug][end if]".
Instead of taking a mug:
say "[if the player has the Cargo_YellowMug] You have enough coffee mugs already.[otherwise if the Cargo_YellowMug is described and the player does not have the Cargo_YellowMug]You take the yellow mug off the rack.[GiveCoffeeMug][otherwise if the Cargo_YellowMug is undescribed]You take a yellow mug off the rack.[GiveCoffeeMug][end if]".
To say GiveCoffeeMug:
Now the player has Cargo_YellowMug.
That way, ‘x mugs’ will map to it. For ‘Understand ‘row of coffee mugs’…’ you have to type the whole thing (‘take row of coffee mugs’) for it to map to the rack.
‘(the silver mug)’ is a parser clarification message. You have defined ‘mug’ as a kind of thing; you have also said ‘Understand “mug” as a mug.’ The parser clarification appears when the parser is trying to determine what you mean by ‘mug’–it will go to your statement ‘Understand “mug” as a mug.’ This probably maps to the mug that is already in hand. So, the parser thinks, by your command, that you mean the silver mug. But then, you wrote an Instead rule, which supercedes the command–printing the statement and then giving the yellow mug to the player.
What could work here is, instead of ‘Understand ‘mug’ as a mug.’, you can write –
Understand "yellow/-- mug" as the Cargo_YellowMug. Understand "silver/-- mug" as the Cargo_SilverMug.
The ‘/–’ makes the word before it optional. Either mug can now be referred to as a mug. And since you already have the silver mug in hand, the parser will naturally assume you mean the yellow mug. And you probably won’t need the GiveCoffeeMug line.
Or, you could just name each object outright–
A yellow mug is on the Cargo_Hangmugs. A silver mug is on the Cargo_HangMugs.
Of course you could have your own reasons for doing things this way, and I apologize if this made you feel criticized.
Colour is a kind of value. The colours are yellow, silver and gold.
Concealmentstate is a kind of value. The concealmentstates are hidden and nothidden.
The plural of mug is mugs. A mug is a kind of open container. A mug has a colour. A mug is usually yellow. Understand the colour property as describing a mug. A mug has a concealmentstate. A mug is usually nothidden.
The mug-collective is a thing. The printed name of the mug-collective is "mugs". The description of the mug-collective is "There's [a list of visible mugs]."
Before printing the name of a mug: say "[colour] ".
Before printing the plural name of a mug: say "[colour] ".
Understand "examine [things]" as examining.
Understand "look at [things]" as examining.
A multiple action processing rule when the current action is examining (this is the examine kinds rule):
let L be the multiple object list;
let F be L;
let the mug count be 0;
repeat with item running through L:
if the item is a mug:
increment the mug count;
remove the item from F;
if the mug count is greater than one:
add the mug-collective to F;
alter the multiple object list to F.
Instead of taking a mug for the first time:
say "As you reach for the mug, you see a group of yellow mugs you did not originally notice and decide to take one of them instead (leaving your original selection where it was). Taken.";
let P be a random yellow mug not carried by the player;
if P is not nothing:
now P is nothidden;
now the player carries P;
let L be the list of yellow mugs not carried by the player;
repeat with item running through L:
now item is nothidden;
move the item to Cargo;
stop the action;
The Cargo is a room. In the Cargo are a pen, four silver mugs and a gold mug. The description of Cargo is "This is a small cramped cargo area.".
Cargo is east of Cockpit. The description of Cockpit is "Before you is a vast array of blinking lights and gauges.".
There are six hidden yellow mugs.
Here is an idea of what the game play looks like when dealing with taking or examining single / multiple objects:
Cargo
This is a small cramped cargo area.
You can see a pen, four silver mugs (empty) and a gold mug (empty) here.
>take mug
Which do you mean, a silver mug or the gold mug?
>silver
As you reach for the mug, you see a group of yellow mugs you did not originally notice and decide to take one of them instead (leaving your original selection where it was). Taken.
>i
You are carrying:
a yellow mug
>l
Cargo
This is a small cramped cargo area.
You can see five yellow mugs (empty), a pen, four silver mugs (empty) and a gold mug (empty) here.
>take pen and 3 yellow mugs and two silver mugs and the gold mug. put pen in gold mug.
pen: Taken.
yellow mug: Taken.
yellow mug: Taken.
yellow mug: Taken.
silver mug: Taken.
silver mug: Taken.
gold mug: Taken.
You put the pen into the gold mug.
>w
Cockpit
Before you is a vast array of blinking lights and gauges.
>examine mugs
There's a gold mug, two silver mugs and four yellow mugs.
>look at the mugs. put the pen in the gold mug.
There's a gold mug, two silver mugs and four yellow mugs.
(first taking the pen)
You put the pen into the gold mug.
>drop gold mug
Dropped.
>l
Cockpit
Before you is a vast array of blinking lights and gauges.
You can see a gold mug (in which is a pen) here.
>e
Cargo
This is a small cramped cargo area.
You can see two yellow mugs (empty) and two silver mugs (empty) here.
>examine the mugs
There's four silver mugs and six yellow mugs.
>i
You are carrying:
two silver mugs
four yellow mugs
>drop all mugs
silver mug: Dropped.
silver mug: Dropped.
yellow mug: Dropped.
yellow mug: Dropped.
yellow mug: Dropped.
yellow mug: Dropped.
>l
Cargo
This is a small cramped cargo area.
You can see six yellow mugs (empty) and four silver mugs (empty) here.
Looking for specific phrasings in an “after reading a command” rule is really nonscalable and hard to support. I can think of three things that will go wrong just in this example.
A standard way to do this, which might avoid a lot of the workarounds you seem to be doing, is to create the yellow mug offstage, and move it into its location after the player does the triggering action (in this case, taking the first mug).
Thanks! I thought I did something similar to that with the following statements:
Instead of taking a mug:
if the player is not holding a yellow mug:
[... more code here to deal with moving duplicates of mugs to some location ...]
There are six hidden yellow mugs.
I will update it to operate only on the first mug taken. For a single mug like 1 silver mug or 1 yellow mug, the code for moving things was rather straight forward. Dealing with duplicates of mugs like six yellow mugs or four silver mugs presented a problem though. I just could not get any other simple syntax to work for cases when you have duplicates of an object and ran into a problem similar the author of this post.
In particular ‘look at mugs’ or ‘examine mugs’ did not work. To work around the issues I hit dealing with duplicates I resorted to lists. Other suggestions or approaches for dealing with looking at or examining duplicates of items would be appreciated!
For reference, I am using The Left Hand of Autumn as a general guide for implementing code when groups of duplicate objects have meaning apart from their individual significance.
Lol. I post a question, go off to a busy day, and come back to quite the discussion!
The concept of “nowhere” was one I had forgotten and that has fixed the (the silver mug) question. I’m still not sure how to get around the multiple objects v. examine issue.
Understand "mugs" as the Cargo_Hangmugs. does not work. I suspect because it’s the plural of the kind that I’m also declaring.
While I appreciate @interactivefiction’s enthusiasm, that seems like quite a lot of code for what’s ultimately an insignificant part of the game (even if I ultimately intend for it to deliver a silly pun).
Well I have to confess I got mixed up in the thread and was looking at the OP’s code when I typed that comment. sorry!
One thing is it seems like the “hidden” property could probably be got rid of–it seems as though in the code, a yellow mug is hidden if and only if it’s off-stage. So you could just check whether the mug is off-stage.
Also I’m not sure whether you want to test on whether the player has the yellow mug. If they take the yellow mug and put it down, then the next time they try to take the silver mug, the whole thing will trigger again, including the statement that they are just now noticing the mugs! Take a mug, take all the yellow mugs, go west and drop them, and go back east and take a mug, and it’ll be weird. (And the message hardcodes that the mug they tried to take is silver–you probably want to replace “[the silver mug]” with “[the noun]”.)
As for dealing with duplicates–it’s still risky to try to have your command trap specific strings when it really should be a command. You have “examine mugs” and “look at mugs” as multi-mug looking, but the player could type “look at all the mugs”!
I think there’s no substitute here for allowing examining to apply to multiple objects. If you look at example 328 in the documentation, “Western Art History 305,” that gives you a way to examine a collective of things using the multiple action processing rulebook to figure out whether you’re examining more than one painting, and give a list of paintings instead of examining each individually.
I also wrote an extension to handle Left Hand of Autumn-style cases (this was for 6L versions of Inform, before the multiple action processing rulebook was implemented). But for a case where you just want to do a multi-examine, that would be using a howitzer to swat a fly.
Thanks a lot for these tips, I will check out example 328. I am interested in learning more about how to deal with duplicates after attempting a few different approaches
I agree it is a lot of code! Your original post made me go learn a few new things and in the process I got swept away in trying to learn how to deal with examining duplicates of mugs
I just looked at this example, it is exactly what I was attempting to achieve . Thanks Matt! One thing that had me tied up in knots was that I was on a 6L38 build of the Inform7 IDE, and as you point out, that example was added as of 6M62. I loaded up 6M62 and migrated the multiple action processing rule into my prototype code (replacing the hard coded “examine mugs”) and it is a great improvement! I will update the code above after I test drive it a bit more.
I agree it is a lot of code! Your original post made me go learn a few new things and in the process I got swept away in trying to learn how to deal with examining duplicates of mugs
. Thanks Matt! One thing that had me tied up in knots was that I was on a 6L38 build of the Inform7 IDE, and as you point out, that example was added as of 6M62. I loaded up 6M62 and migrated the multiple action processing rule into my prototype code (replacing the hard coded “examine mugs”) and it is a great improvement! I will update the code above after I test drive it a bit more.