[Inform] multiple objects
Rhywsut
from one another. The class looks something like this right now:
Class Scrap
has
legible,
with
short_name "scrap of paper",
plural "scraps of paper",
name 'scrap' 'scraps//p';
The problem is, when I run the game, I get some strange results. I finally got
it to say "You are carrying two scraps of paper", but then if I type (say)
"drop all", it drops ONE scrap of paper. Then if I drop the other scrap, one of
them seems to disappear: it says "You see a scrap of paper here." And if I
take that scrap and do 'tree', it shows both the scrap I am carrying and the
other scrap in the room, even though the other scrap is gone from the game. Am
I missing something simple or do I have to add some sort of 'parse_name'
routine (which I really don't want to do, given the inscrutability of the
examples of this that I've seen)? Help!
-cph
Joyce Haslam
Rhywsut <rhy...@aol.com> wrote:
> > but then if I type (say) "drop all", it drops ONE scrap of paper. Then
> >if I drop the other scrap, one of them seems to disappear: it says
> >"You see a scrap of paper here."
> Let me reply to myself by confessing that it seems that my disappearing
> objects were disappearing because they had 'concealed'. So I took away
> 'concealed' after the player touched them, and now they seem to work
> fine! Who knew? Live and learn....
Concealed has lovely little traps for the user. I've been in one or two.
Joyce.
--
Joyce Haslam
dljh...@argonet.co.uk
Andrew Plotkin
> > Let me reply to myself by confessing that it seems that my disappearing
> > objects were disappearing because they had 'concealed'. So I took away
> > 'concealed' after the player touched them, and now they seem to work
> > fine! Who knew? Live and learn....
> Concealed has lovely little traps for the user. I've been in one or two.
I refuse to use "concealed" at all. It is never, ever what I want. If I
don't want the player to know about an object, I *don't put the object
there.*
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Joyce Haslam
Andrew Plotkin <erky...@netcom.com> wrote:
> Joyce Haslam (dljh...@argonet.co.uk) wrote:
> > Concealed has lovely little traps for the user. I've been in one or
> > two.
> I refuse to use "concealed" at all. It is never, ever what I want. If I
> don't want the player to know about an object, I *don't put the object
> there.*
Yes, that makes sense on first reading. And many times I did wind up
creating the object after the player had done whatever. But if an object
is to be seen if the player has the lamb/lamp/magic wand/toothbrush and
not otherwise, isn't the test the same? And what do you do instead of
'give object ~concealed' ?
Andrew Plotkin
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> > Joyce Haslam (dljh...@argonet.co.uk) wrote:
> > > Concealed has lovely little traps for the user. I've been in one or
> > > two.
> > I refuse to use "concealed" at all. It is never, ever what I want. If I
> > don't want the player to know about an object, I *don't put the object
> > there.*
> Yes, that makes sense on first reading. And many times I did wind up
> creating the object after the player had done whatever. But if an object
> is to be seen if the player has the lamb/lamp/magic wand/toothbrush and
> not otherwise, isn't the test the same?
The same as what?
I don't use concealed because it does several related things, and I
generally want to do *one* thing.
> And what do you do instead of
> 'give object ~concealed' ?
"move object to room", or whatever.
Or sometimes "object.describe = NULL". (If I want a movable object that
doesn't show up in a room description, I give it a describe property that
does nothing and returns true. Later, I can get rid of that property, and
the object is listed normally.)
(Actually, I'd be more likely to write:
with describe [;
if (toothbrush in player)
rfalse;
else
rtrue;
];
That way the property can't get out of sync with whether the player
really has the toothbrush. I hate trying to trap every single method by
which the toothbrush might enter or leave the player's possession.)
Laurel Halbany
wrote:
>I refuse to use "concealed" at all. It is never, ever what I want. If I
>don't want the player to know about an object, I *don't put the object
>there.*
Isn't the point of concealed not to hide the object, but to avoid
repeating item descriptions that are in the room description?
Andrew Plotkin
No, that's "scenery".
"Concealed" does that, but it also makes it harder (maybe impossible?)
for the player to refer to the object.
I'd rather deal with those aspects separately. If I want the object
un-referable-to, I change the name or remove the ojbect. If I want the
description to not appear, I use scenery or the describe property.
Jonadab the Unsightly One
> > > Concealed has lovely little traps for the user. I've been in one or
> > > two.
Almost every Inform library attribute holds at least one trap.
> Andrew Plotkin <erky...@netcom.com> wrote:
>
> > I refuse to use "concealed" at all. It is never, ever what I want. If I
> > don't want the player to know about an object, I *don't put the object
> > there.*
Joyce Haslam <dljh...@argonet.co.uk> wrote in article
> Yes, that makes sense on first reading. And many times I did wind up
> creating the object after the player had done whatever. But if an object
> is to be seen if the player has the lamb/lamp/magic wand/toothbrush and
> not otherwise, isn't the test the same? And what do you do instead of
> 'give object ~concealed' ?
move object to location;
================
When I use concealed:
When I have an object that is described in the room description, but needs
to be referrable by the player, that is when I use the scenery attribute.
But
if the same object also needs to be takeable, then I use concealed.
Two caveats:
Do not forget to give it not concealed after a Take action.
The room description needs to be a routine and account for its
absense by excluding that part of the description.
I also have used concealed for containers that are children of
a supporter, in lieu of add_to_scope, as this allows the drawers
to (if they allow it) actually be removed and put back. (This could
still be done with add_to_scope, but would be a hack.)
And we wouldn't want to see three drawers sitting on the desk ;-)
--
At Your Service,
Jonadab the Unsightly One.
remove spaces: j o n a d a b @ b r i g h t . n e t
Michael Gentry
Andrew Plotkin wrote in (an earlier) message ...
>> >I refuse to use "concealed" at all. It is never, ever what I want. If I
>> >don't want the player to know about an object, I *don't put the object
>> >there.*
>
If that's the case, I'm curious as to how you coded a few of the objects in
"So Far" -- for example, the ring under the bushes in the World of Blue And
Yellow People. You know, where if you attempt, using prior knowledge, to
interact with the ring without having actually looked for it, you get this
clever retort:
"What, you mean the ring under the bushes?"
I thought that was pretty neat, and it occurred to me at the time that the
"concealed" attribute would be a simple way to do it. Even did a similar
thing myself in LBM, though I eventually threw out that puzzle.
If you didn't use "concealed", how did you do it?
--Michael Gentry
"If you don't eat your meat, you can't have any pudding.
How can you have any pudding if you don't eat your meat?"
Andrew Plotkin
> Andrew Plotkin wrote in (an earlier) message ...
> >> >I refuse to use "concealed" at all. It is never, ever what I want. If I
> >> >don't want the player to know about an object, I *don't put the object
> >> >there.*
> If that's the case, I'm curious as to how you coded a few of the objects in
> "So Far" -- for example, the ring
> [spoilers trimmed -- watch that, please]
> You know, where if you attempt, using prior knowledge, to
> interact with the ring without having actually looked for it, you get this
> clever retort:
Good question. Let me look at my code.
Code following is partial and names have been changed, obviously.
Object glittering "ring" pile
with
description [;
if (self hasnt moved) {
print "What, that glint in the pile? ";
give self moved;
}
"It's a plain ring.";
];
Object pile "pile of stuff"
with
description [;
print "It's a pile of stuff.^";
if (glittering in self) {
if (glittering hasnt moved)
print "^Something glints in the pile.^";
else
print "^There's a ring in the pile.^";
}
rtrue;
],
before [;
Search:
if (glittering in self) {
give glittering moved;
"You see a ring in the pile.";
}
"Just a pile.";
],
after [;
LetGo:
if (noun == glittering) {
if (glittering hasnt moved)
print "What, that glint in the pile? ";
"You reach in and snag the ring.";
}
],
has scenery container open;
As you see, I'm not interfering with *referring* to the ring at all. As
far as the parser's concerned, it's a normal object in a normal open
container.
It's not mentioned in the room description, because the contents of
scenery containers aren't listed by default.
Then I just use the "moved" flag to check whether it's been seen. This
isn't what "moved" was meant for, but since I'm not using object scoring
or an "initial" property, it doesn't screw anything up.
If you want to try this, remember that this was written and built with
library 5/12 (Inform 5.5). No guarantees for modern environments.
Michael Gentry
Andrew Plotkin wrote in message ...
>Good question. Let me look at my code.
[code snipped]
>As you see, I'm not interfering with *referring* to the ring at all. As
>far as the parser's concerned, it's a normal object in a normal open
>container.
Ah-ha. That makes sense.
I wasn't aware that "concealed" interfered with the player's referring to to
the object, though. If I recall correctly, my own code looked like this:
Object "nickel" with
name "coin" "nickel" "money",
description "It's got a buffalo on one side and
a human head on the other.",
before
[; if (self has concealed)
"Nickel? What nickel?"
! This belays any interaction with the nickel until the player
! specifically looks for it (and yes, it's supposed to give away
! that something's there). But notice it's not the "concealed"
! attribute that gets in the way, but rather the "before" routine
! that checks the attribute to see if it should interfere.
else rfalse;
],
has concealed;
Object "vending machine" with
name "vending" "machine",
description "A coin-operated vending machine.",
before
[; LookUnder:
if (nickel has concealed)
{ give nickel ~concealed;
"You notice a nickel on the floor, just underneath the
vending machine.";
}
if (nickel hasnt moved)
"That nickel's still there.";
],
has static;
This worked just fine for my purposes. It's not in the game anymore, but
only because my purposes changed.
I've also noticed, while perusing the TakeSub routine in the standard
library, that taking/removing an object automatically removes the
"concealed" attribute along with assigning the "moved" attribute. So you
don't have to explicitly do it yourself.
I don't actually use it very often, myself -- but it does come in handy
occassionally.
--M
Graham Nelson
> > Concealed has lovely little traps for the user. I've been in one or two.
>
> don't want the player to know about an object, I *don't put the object
> there.*
Perhaps I should replace it with "congealed", for soups and the
like. Or "conceited", for non-player characters?
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Doeadeer3
<edr...@email.msn.com> writes:
>I don't actually use it very often, myself -- but it does come in handy
>occassionally.
>
>--M
I use it fairly frequently. But one has to watch out for concealed doors (the
player can't go through) them and objects put down on concealed objects
disappear. But if I want to include something in a room description, something
that will not have a "You also can see" line, an object that COULD BE takeable,
but actually isn't for one reason or another (I will say why, I don't like
having the message, "That isn't exactly portable." for EVERYTHING big --
"You'll need a crane for that."), it is handy. It is also handy sometimes for
revealing something suddenly (although move obj to location is usually better).
It has it uses, despite Zarf's dislike.
Doe :-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Joyce Haslam
Michael Gentry <edr...@email.msn.com> wrote:
> I've also noticed, while perusing the TakeSub routine in the standard
> library, that taking/removing an object automatically removes the
> "concealed" attribute along with assigning the "moved" attribute. So you
> don't have to explicitly do it yourself.
Really? I had to put in code like
before[; Take: give self moved; give self ~concealed; rfalse; ]
because objects that should have been moved and unconcealed weren't.
My wonderful playtesters told me so.
Andrew Plotkin
> In article <erkyrathE...@netcom.com>, Andrew Plotkin
> <URL:mailto:erky...@netcom.com> wrote:
> > > Concealed has lovely little traps for the user. I've been in one or two.
> >
> > I refuse to use "concealed" at all. It is never, ever what I want. If I
> > don't want the player to know about an object, I *don't put the object
> > there.*
> Perhaps I should replace it with "congealed", for soups and the
> like. Or "conceited", for non-player characters?
...or for know-it-all game authors...
--Z (who, me?)
Denis M. Moskowitz
Hmm. In my clothing library, I use "concealed" on articles of
clothing that are entirely covered by other articles. It made
sense at the time (they're concealed, right?) and it seemed to
work OK once I changed the inventory flags, but is this a
legitimate use? Or have I consigned users of the library to many
traps unknowingly?
--
Denis M Moskowitz Jen feroca malbona kuniklo; rigardu liajn
d...@cs.hmc.edu sovagxajn vangharojn, kaj liajn ungojn kaj
This Is Realtime! -><- lian faldan voston.
<a href="http://www.cs.hmc.edu/~dmm/dmm.html">My WWW page</a>
Michael Gentry
Joyce Haslam wrote in message <48785ea99...@argonet.co.uk>...
>In article <uhwb6l7y9GA.113@upnetnews05>,
>
>Really? I had to put in code like
>
> before[; Take: give self moved; give self ~concealed; rfalse; ]
>
Ouch -- I'm embarassed. I went looking for the code and I couldn't find
it -- so probably I'm wrong.
I DID discover that the "Purloin" meta-verb removes the "concealed"
attribute, though. Strange. Maybe that's what I was thinking of.
--M
================================================
Jonadab the Unsightly One
> I've also noticed, while perusing the TakeSub routine in the standard
> library, that taking/removing an object automatically removes the
> "concealed" attribute along with assigning the "moved" attribute. So you
> don't have to explicitly do it yourself.
This is new in Inform 6, I believe. (Not moved, but removing concealed).
It is probably a good thing, since forgetting to remove concealed is a
common bug among those who use concealed.
I personally rig Examine to assign an xed (short for examined) attribute,
too.
This is very useful for context-sensitive hints.
Joyce Haslam
Michael Gentry <edr...@email.msn.com> wrote:
> Joyce Haslam wrote in message <48785ea99...@argonet.co.uk>...
> >In article <uhwb6l7y9GA.113@upnetnews05>,
> >
> >Really? I had to put in code like
> >
> > before[; Take: give self moved; give self ~concealed; rfalse; ]
> >
> Ouch -- I'm embarassed. I went looking for the code and I couldn't find
> it -- so probably I'm wrong.
> I DID discover that the "Purloin" meta-verb removes the "concealed"
> attribute, though. Strange. Maybe that's what I was thinking of.
Probably. The game became big enough that I resorted to purloin and
gonear. Also I never thought to pick an object up and put it down again
two locations later. That is for mazes, and mine are small and I have the
maps.
Doeadeer3
M. Moskowitz) writes:
>Subject: Re: [Inform] multiple objects
>From: d...@turing.cs.hmc.edu (Denis M. Moskowitz)
>Date: 20 Aug 1998 17:36:57 GMT
>
>[discussion of "concealed"]
>Hmm. In my clothing library, I use "concealed" on articles of
>clothing that are entirely covered by other articles. It made
>sense at the time (they're concealed, right?) and it seemed to
>work OK once I changed the inventory flags, but is this a
>legitimate use? Or have I consigned users of the library to many
>traps unknowingly?
>--
Not that I know of. And as you know I have used your library. I encountered no
problems. A concealed object in the player's inventory it is visible in the
inventory. (Which is why the "bits" in the inventory's writefromlist need to be
changed for you library to work correctly.)
But the player doesn't disappear when they put on concealed clothes, if that is
what you mean.
Doe :-) Hehehe.
Ed Stauff
(Denis
M. Moskowitz) writes:
> >Hmm. In my clothing library, I use "concealed" on articles of
> >clothing that are entirely covered by other articles.
I have developed a clothing library of my own, which features layering
(e.g. you can't but a bra on over a coat), length (a short jacket won't
cover a pair of shorts but a long coat will), and enforcing put-on/
take-off order. I'm interested in comparing my library with others;
is Denis's library available on line somewhere?
BTW, I didn't use a "conceal" attribute, I made garments opaque and
had them contain each other.
-- Ed (no longer *quite* an Inform newbie, but still learning)
Ed Stauff
> is Denis's [clothing] library available on line somewhere?
Duh. Look first, Ed. I found it on the ftp site.
Sorry...
-- Ed
Mark J Musante
> I have developed a clothing library of my own, which features layering
> (e.g. you can't but a bra on over a coat),
You obviously never have been to one of my parties.
-=- Mark -=-