Foxaroo project #1: TARDIS Adrift

As it stands, your code begins by creating nine individual objects (Tom’s boots, Gerty’s shirt, Dick’s dungaries etc.); then it creates a kind (WorkGarment); then it says that three individual objects, called “Shirt”, “Dungaries”, and “Boots” respectively, is of the kind WorkGarment, and Inform picks the first objects created that contain the word “shirt”, “dungaries”, and “boots” in their names, which happen to be the things Tom is wearing – so only these three objects are ever declared to be of the WorkGarment kind.

Apparently, you want Shirt, Dungaries, and Boots to be subkinds of WorkGarment. Just explicitly declare them to be so – only you have to do that before you create the individual objects called “Tom’s shirt” etc.

[code]A WorkGarment is a kind of thing. A Shirt is a kind of WorkGarment. Dungaries are a kind of WorkGarment. Boots are a kind of WorkGarment.

In the construction site is a man called Tom. The printed name of Tom is “Tommy”. Tom is wearing a shirt called Tom’s shirt. He wears some dungaries called Tom’s dungaries. He wears some boots called Tom’s boots. To say rundown for (somebody - Tom): say “[if Tom is In WorkGear]Muscle man Tommy is here, in grubby work clothes[Else]Off-duty Tom is here, wearing [a list of things worn by Tom]”. The description of Tom is “[rundown for Tom]”.[/code]etc.

I think you could do more with sub-kinds:

A construction worker is a kind of person. Every construction worker wears a shirt. Every construction worker wears dungaries. Every construction worker wears boots. Tom is a male construction worker. Dick is a male construction worker. Gertie is a female construction worker.

As long as you don’t refer to the “man” and “woman” kinds specifically, I don’t think you really need them.

Also, regarding the “wrists” issue: Unless you actually need to do something with the wrists of arbitrary people, I would advise against creating a large catalog of body parts for every single person in the game. Not only will it confuse the parser, but it could distract the player and slow down the virtual machine.

For my WIP, I use my “Lost Items” extension to catch references to body parts (among other things) when the player might expect them to be there, but doesn’t need to interact with them:

For noticing absence of a body part (called item): say "You only need to deal with [the item]s of the victims, and there are no victims here."

Got it, there they are, thankee Skinny Mike! :slight_smile:
Whoooo boy… more manual pages to read! :open_mouth:

YES!!! It worked. Thanks Felix. :smiley:

This is something I tried at a much earlier stage, and I had great hopes for it because assigning the job as a kind would have streamlined a great deal of code. Not just in the current (curiosity) project but many others.
Unhappily this was the result, and I even tried compiling in an otherwise blank project:

Problem. You wrote ‘Tom is a male construction worker’ , but also ‘Dick is a male construction worker’ : that seems to be saying that the same object (shirt) must be in two different places (Tom and Dick). This looks like a contradiction.

Problem. You wrote ‘Tom is a male construction worker’ , but also ‘Gertie is a female construction worker’ : that seems to be saying that the same object (boots) must be in two different places (Tom and Gertie). This looks like a contradiction.

It produced six rows of this error; one for each of the six objects following the first nine because it interprets them as a contradiction.

(Skinny Mike, haven’t had a chance tonight to experiment with your suggestion for wrists - I’ll need to give that a try tomorrow if I can).

That’s because in addition you also need to declare the shirt, dungaries, and boots kinds. If you don’t, Inform will assume that the shirt, the dungaries, and the boots arnot kinds but three individual objects. This compiles fine:

[code]The Construction Site is a room.

A construction worker is a kind of person.
Tom is a male construction worker in the Construction Site. Dick is a male construction worker in the Construction Site. Gertie is a female construction worker in the Construction Site.

WorkGarments is a kind of thing.
A shirt is a kind of WorkGarments. Some dungaries are a kind of WorkGarments. Some boots are a kind of WorkGarments.

Every construction worker wears a shirt. Every construction worker wears dungaries. Every construction worker wears boots. [/code]

The problem with this for your present project (I guess) would be that all three shirts, dungaries, and pairs of boots would be called just “shirt”, “dungaries”, and “boots”; so there will be no easy way to examine (say) Dick’s dungaries in particular.

I have some code (mostly borrowed from an example in the Punctuation that will automatically make “Tom’s shirt” refer to a shirt worn by Tom, and similarly for anything that’s part of Tom or held by Tom (this is the enclosure relation). I’m pasting an unnecessarily long bit under a spoiler tag:

[spoiler][code]“possessions” by Matt Weiner

Section 1 - Of Hats

clothing is kind of thing.
a hat is kind of clothing.
clothing is always wearable.

understand “hat” as a hat.

The fuschia hat is a hat. The bright red hat is a hat. The bright blue hat is a hat. The purple hat is a hat.
The indefinite article of a hat is usually “a”. The description of a hat is usually “It’s [indefinite article of the noun] [printed name of the noun].”.

Section 2 - Of Sticks

The swagger stick is a thing. The description is “It seems confident, if not arrogant.” The walking stick is a thing. The description is “Sturdy and mostly straight, it looks like it might help you walk.”

Section 3 - Of Noses

A nose is a kind of thing. Every person incorporates a nose.
The description of a nose is usually “[Random person incorporating the item described][’]s nose is noselike.”

Section 4 - Of Enclosures

After reading a command:
let X be indexed text;
let X be the player’s command;
replace the text “'s” in X with " [’]s";
change the text of the player’s command to X;
say “[line break]”.

Understand “[something related by reversed enclosure] 's” as a thing.
Understand “my” as a thing when the player encloses the item described.

Enclosure-querying is an action applying to one thing. Understand “scan [something]” as enclosure-querying. [This is for debugging; you don’t want to include it]
Carry out enclosure-querying: say “[list of things enclosed by the noun].”

Section 5 - Scenario

Starter is a room.

Bob and Mike are men in Starter.

Understand “Robert” as Bob.
Barbie and Sandie are women in Starter.

Bob wears the red hat. Mike wears the blue hat. Barbie wears the fuschia hat. Sandie wears the purple hat. Sandie carries the swagger stick. Mike carries the walking stick.

Persuasion rule: persuasion succeeds.

Test me with “x bob’s hat/x bob’s nose/x sandie’s stick/bob, drop hat/mike, doff hat/x mike’s hat/mike, take hat/x mike’s hat/bright blue hat/x mike’s blue hat/mike, wear red hat/mike, drop blue hat/take hat/x my hat”.
[/code][/spoiler]

I think this works, though there may be some bugs in it and disambiguation might be hinky. However, it probably won’t suit your purposes, because I suspect you want “Tom’s shirt” to refer to the shirt Tom was wearing even when he’s taken it off. To do that, you might try something like the ideas discussed here (unfortunately there’s a lot of fairly irrelevant back-and-forth in that thread), particularly the “embodiment” relation set with the When play begins rule. (Though you probably want to call it “ownership” and certainly want to set it to anything that the person encloses rather than anything that is part of the person.)

Of course, at this point a simpler way might just be to manually declare the items as “Tom’s shirt” etc.

Matt, I don’t think that’s necessary in this case because the compiler automatically calls it “Tom’s shirt” when it’s created. Now if the character were called Tom Jones, then the shirt would be called “Tom Jones’s shirt” and you might have to do some work if you wanted it to be called/understood as “Tom’s shirt” instead. But if you’re not doing that, you should be fine.

I forgot about this until today, but now I’ve posted a thread:

I think that’s true of body parts but not of worn things. So “every person incorporates a nose” will create objects called “Tom’s nose” and “Bob’s nose” but “every person wears a shirt” just creates things called “shirt.” At least, that’s what happened in the Index when I did a test case.

Ahh… you must have discussed that in the last thread about this, but I totally forgot! Bummer.

Thanks Felix, matt w and capmikee!

Firstly, bother! I didn’t get an E-mail notification to say that anyone had appended this thread, so I went ahead and experimented and ultimately I was satisfied with this code:

[code]A WorkGarment is a kind of thing. A Shirt is a kind of WorkGarment. The indefinite article is “a”. Dungaries are a kind of WorkGarment. The indefinite article is “some”. Boots are a kind of WorkGarment. The indefinite article is “a pair of”.

A left wrist is a kind of thing. A right wrist is a kind of thing.
A labourer is a kind of person. A left wrist is a part of every labourer. A right wrist is a part of every labourer.

In the construction site is a male labourer called Tom. The printed name of Tom is “Tommy”. Tom is wearing a shirt called Tom’s shirt. He wears some dungaries called Tom’s dungaries. He wears some boots called Tom’s boots. ] To say rundown for (somebody - Tom): say “[if Tom is In WorkGear]Muscle man Tommy is here, in grubby work clothes[Else]Off-duty Tom is here, wearing [a list of things worn by Tom]”. The description of Tom is “[rundown for Tom]”.

[~~~ And then repeated for the other two labourers ~~~]
[/code]
I didn’t know about the gramar “Every person incorporates” though. Thanks matt w, that helps streamline a lot of code! Eg: “Every labourer incorporates a left wrist and a right wrist.”

Now out of curiosity I tried it this way as suggested by Felix: Every construction worker wears a shirt. Every construction worker wears dungaries. Every construction worker wears boots.
And yes, as Felix warned it does produce identically named objects. That’s not necessarily a problem in my game though, because the next puzzle in my (little) game was to persuade the night watchman to open up the suspect’s work locker (or maybe pick the lock). Thus each set of work gear is separated (unless the player is stupid enough to mix them up.) There’s also a possibility that I’d do a replace of the ordinary shirt with a separate one that has the bloodstain and give that shirt it a different name.

Something I would need to know then, is how to write code for an NPC to pick up and put down objets (the game orchestrating so, not the player). I haven’t had much luck there. I’ve tried “Now [NPC Name] carries” to pick up and “Now the [noun] is in the locker” but it doesn’t always work, and I’m not understanding the cause of the problem. Plus if the objects are identically named that makes it even more tricky to manipulate a particular object.

Where do I find examples of the coding to make NPCs pick up / put down?

Matt W, I’ve put your code in a separate project and yes it compiles and runs very effectively. Am I right in assuming that these two lines of code are what enables Inform to deduce which noun the player is referring to?

Understand "[something related by reversed enclosure] 's" as a thing. Understand "my" as a thing when the player encloses the item described.
How do these work? I haven’t done much with the concept of enclosure. What is the function of “related by reversed enclosure” ?

Also, how does the below code work?

After reading a command: let X be indexed text; let X be the player's command; replace the text "'s" in X with " [']s"; change the text of the player's command to X; say "[line break]".
Am I right in reading that this block of code puts square brackets around apostrophes? Effectively what is the goal/outcome of this?

I look forward to seeing the replies in this thread. It would be good to have a standardised extension created for describing NPCs. Goodness knows they’re used often enough in Interactive Fiction.

You are correct. See section 16.16 of the documentation, “Understanding things by their relations,” which is one of the more magical parts of Inform for my money. “Enclosure” relates a thing to anything it carries, wears, or is part of it, or anything that’s part of that, etc.; so if someone were wearing a backpack that contained a watch that had a button as part of it, the person would enclose the button.

But the key thing is “related by reversed enclosure”; this means that “Tom’s” (or “Tom 's”; see below) will match everything that Tom encloses. Tom encloses the wrist, so Tom is related by reversed enclosure to the wrist, so the string “Tom 's” matches the wrist (it is “[something related by reversed enclosure to the wrist] 's”. Or I may have got the reversed enclosure backwards; I usually have to trial and error that.

Then “Tom 's” matches everything Tom encloses, but if you have “Tom 's wrist” it’ll only match the wrist.

No, it just puts a space before the apostrophe-s, so “Tom’s” turns into “Tom 's”. We need to insert the space so Inform can recognize “Tom” and “'s” as separate words; it can’t parse “Tom” as part of “Tom’s” without a space in between them, since the parser works at the level of words. The brackets are necessary because otherwise Inform will turn the apostrophe into a double quote, which is its default behavior when an apostrophe appears at the beginning or end of a word in quotation marks. (Since you can’t put double quotation marks in quotation marks in your source.) The brackets are just the same brackets you use in a text substitution; ['] is a built-in text substitution that gives you an apostrophe no matter where you put it in quotes.

Thanks matt w!

Now before moving on to the next problem I have a little story to share, and I’d be interested to know if anyone has experienced this same frustration.

A section of my code was producing a compilation error (it was a block assigning a new value to the characters, but that’s not really important). I struggled with it for at least an hour, thinking “What am I overlooking?” I was tempted to do the lazy thing and post it here asking for a solution, but I resovled “No, I’m going to solve this myself.”

I created a blank project and began coding the specific section until I had it working. Such was my zeal that I then copied and pasted it straight over the block with the compilation error and immediately saved the file.

Only after having done so, and lost the ability to undo, did I realise that I’d missed out on the learning experience. IE I had no idea what it was that I’d been doing wrong… nuts. So my learning experience was to pay closer attention to my learning experiences. :unamused:

Now my two current problems:

From last week:
Where do I find instructions on how to make NPCs pick up and put down objects? I’ve found that “Now the [NPC] carries” and “Now the [noun] is in” doesn’t always succeed. This is particularly important if I have those three NPCs who are wearing identically named pieces of clothing.

New problem:
Does concealment work on body parts? I want to put a tattoo on the murderer, but not have it visible under the labourer’s work clothes.

Judging by section 3 of the manual, only carried objects can be concealed.

Chapter 3 - Things
3.24. Concealment
“Rule for deciding the concealed possessions”

If it can’t be done that way, there’s two other possibilities I’ve considered.

  1. Making the tattoo a carried object that is part of the murderer’s inventory but is described as being on their body.
  2. Having a “Instead of examining” condition that prevents the tattoo being examined while covered by clothing.

Which is the best approach?

Seems so. And you do know you can have NPCs perform actions with the try syntax?

[code]The Gym is a room.

Bob is a person. Bob is in the Gym. Bob wears a shirt.

A tattoo is part of Bob. The description is “It is the symbol of the Sacred Chao.”

Rule for deciding the concealed possessions of Bob while Bob is wearing the shirt: if the particular possession is the tattoo, yes.

Instead of examining Bob: if Bob is wearing the shirt, try Bob dropping the shirt; otherwise try Bob wearing the shirt.

After Bob dropping the shirt: say “Bob pulls his shirt off, revealing a curious tattoo.”

After Bob wearing the shirt: say “Bob puts his shirt back on.”

test me with "x tattoo / x Bob / x tattoo / l / x Bob "[/code]

Maybe you could give that thread a bump by posting your own thoughts…

Thanks! :slight_smile: I didn’t realise it was as easy as that! :astonished:

So that is the correct way after all…

I originally put these in my code to test:

When play begins: Try Tom taking the widget; Try Tom dropping the watchamacalit.But I received this error:" Problem. You wrote ‘Try Tom taking the widget’ : but I can’t find a verb here that I know how to deal with, so I am ignoring this sentence altogether."

So then when I saw your instruction I took the code and put it in an empty project and it worked just fine. I then fiddled around until it worked in the original project. I think I had a comma where there should have been a semi-colon or something. Beginner’s mistakes, sorry… :blush:

I most sincerely would if I had a grasp of the code. It’s still early days for me in my learning of Inform. I’ve yet to use any of the following “To decide”,“a truth state”,“is an activity on people”,“For…”,“Pronoun enabled is”. Those are all new to me. I understand the ends; a new extension with standards on how to describe NPCs and how they are examined, but the workings of the code are somewhat beyond me at present. I’m waiting to see what more knowledgeable people say so that I can (hopefully) get more of an idea.

This is the error that you’d get if you write “Try Tom taking the widget.” without a “When play begins:” or similar rule preamble, so my guess is that you might have accidentally put a period after “when play begins.”

Punctuation errors can be seriously annoying!

More likely to have been the immediately preceeding line. I have several statements set up after “When play begins” and they were working fine. Since they were working and “Try Tom taking” produced a compilation error it’s what led me to assume that the command itself was incorrect. All working now. :slight_smile:

Felix, found a problem with the code to conceal the tattoo; it’s concealing all the body features. I added a wrist:

[code]The Gym is a room.

A wrist is a kind of thing. A wrist is part of every person.

Bob is a person. Bob is in the Gym. Bob wears a shirt.

A tattoo is part of Bob. The description is “It is the symbol of the Sacred Chao.”

Rule for deciding the concealed possessions of Bob while Bob is wearing the shirt: if the particular possession is the tattoo, yes.

Instead of examining Bob: if Bob is wearing the shirt, try Bob dropping the shirt; otherwise try Bob wearing the shirt.

After Bob dropping the shirt: say “Bob pulls his shirt off, revealing a curious tattoo.”

After Bob wearing the shirt: say “Bob puts his shirt back on.”

test me with "x tattoo / x wrist / x Bob / x tattoo / x wrist / l / x Bob "[/code]

Result:

[code]>test me
(Testing.)

[1] x tattoo
You can’t see any such thing.

[2] x wrist
You see nothing special about your wrist.

[3] x bob
Bob pulls his shirt off, revealing a curious tattoo.

[4] x tattoo
It is the symbol of the Sacred Chao.

[5] x wrist
Which do you mean, your wrist or Bob’s wrist?

[6] l
The Void
You can see a shirt and Bob here.

[7] x bob
(Bob first taking the shirt)
Bob puts his shirt back on.[/code]Puzzling. The statement references the tattoo specifically, so it shouldn’t be covering the wrist as well.

Slap an “otherwise no” on the end of the rule for deciding concealed possessions and it seems to work. That doesn’t seem to be the documented behavior, but I guess you always need the “otherwise no.”

Worked! Thanks matt w. :slight_smile:

…aaaand onto my next set of challenges.