[Inform] Doors and Locks
Paul Harker
Ok, I'm sure this has been done a million times, and rather than
reinvent the wheel I'm going to ask.
How do I implement a door that acts like a "normal" door when it comes
to the locks? That is, what is the best/easiest way to make a
double-sided door which locks/unlocks with a key on one side, and on the
other side can be locked/unlocked without a key?
It *seemed* really straight forward to simply capture "Unlock" in the
'before []' routine, but the parser prompts "What would you like to
unlock the door with?" before the 'before []' routine can intercept.
Thanks in advance....Paul
Greg Falcon
Paul Harker <har...@iserv.net> wrote:
>Thanks in advance....Paul
What about something like this?
Extend the grammar like so:
[ UnlockNoKeySub; if (noun hasnt lockable) "You can't unlock that.";
if (noun hasnt locked) "It's already unlocked.";
print_ret "You try to unlock ", (the) noun,
"with your bare hands, but fail.";
];
Extend "unlock" * noun -> UnlockNoKey;
[ LockNoKeySub; if (noun hasnt lockable) "You can't lock that.";
if (noun hasnt locked) "It's already locked.";
print_ret "You try to lock ", (the) noun,
"with your bare hands, but fail.";
];
Extend "lock" * noun -> LockNoKey;
(These extentions should go somewhere after the line
Include "Grammar";)
Now the game will still respond intelligently to a command without an
indirect object like "UNLOCK BOX", and you can now trap LockNoKey and
UnlockNoKey in before routines.
Object door "door"
with name "door",
description "It's doorlike.",
before [; LockNoKey: if (self hasnt locked && location==indoor_side)
{give self locked; "Locked.";}
UnlockNoKey: if (self has locked && location==indoor_side)
{give self ~locked; "Unlocked.";}
],
found_in indoor_side outdoor_side,
!
! (Other door properties here)
!
has door static openable lockable locked;
(This is all assuming you're making one door object present in two
rooms, as suggested in chapter 8 of the designers manual...)
Hope this helps.
Greg Falcon
Greg Falcon
I myself (Greg Falcon) wrote:
>[ LockNoKeySub; if (noun hasnt lockable) "You can't lock that.";
> if (noun hasnt locked) "It's already locked.";
^^^^^ Yipes! I messed up there (For those
with mono-spaced fonts... ;-)
> print_ret "You try to lock ", (the) noun,
> "with your bare hands, but fail.";
>];
>Extend "lock" * noun -> LockNoKey;
The second line of that should be
if (noun has locked) "It's already locked.";
Greg Falcon
Russell Wain Glasser
In <322CBC...@iserv.net> Paul Harker <har...@iserv.net> writes:
>
>Ok, I'm sure this has been done a million times, and rather than
>reinvent the wheel I'm going to ask.
>
>How do I implement a door that acts like a "normal" door when it comes
>to the locks? That is, what is the best/easiest way to make a
>double-sided door which locks/unlocks with a key on one side, and on the
>other side can be locked/unlocked without a key?
>
>It *seemed* really straight forward to simply capture "Unlock" in the
>'before []' routine, but the parser prompts "What would you like to
>unlock the door with?" before the 'before []' routine can intercept.
>
>Thanks in advance....Paul
The problem is that the "unlock" verb is designed to only accept
commands with a noun at the end. But you can fix that by changing the
definition of the verb. Add these lines of code:
Extend "unlock" replace
* noun -> Unlock !This line of code lets you unlock
!with no indirect object
* noun "with" noun -> Unlock; !This line lets you unlock in the
!usual way
You can then fix up the door with a before routine like you wanted to,
for instance:
Object FrontDoor "front door"
has door openable lockable,
with
...........
before
[;
Unlock:
if (location == Foyer)
{
if (second == nothing)
{
give self ~locked;
"You turn the knob to unlock the door.";
}
"You don't need a key to unlock it from this side.";
}
if (location == FrontLawn && second == nothing)
"You'll have to say what you want to unlock it with.";
];
Yes, "nothing" really is a valid indirect object. In fact, it
appears to me that "nothing" is automatically generated as a noun AND
as a second if you don't supply them. Am I right? Anyone?
Russell
Kevin Lo
In article <322CBC...@iserv.net>, har...@iserv.net says...
> Ok, I'm sure this has been done a million times, and rather than
> reinvent the wheel I'm going to ask.
>
> How do I implement a door that acts like a "normal" door when it comes
> to the locks? That is, what is the best/easiest way to make a
> double-sided door which locks/unlocks with a key on one side, and on the
> other side can be locked/unlocked without a key?
>
> It *seemed* really straight forward to simply capture "Unlock" in the
> 'before []' routine, but the parser prompts "What would you like to
> unlock the door with?" before the 'before []' routine can intercept.
Nice conecpt! I scoured through all my Inform stuff, and couldn't find
an "easy" way to do this, other than modifying the source code itself, because
Inform automatically tests the following if you are trying to lock a door: Is
it lockable, is it already locked, is it open, and does the direct object (the
supposed "key") match the with_key variable on the door.
I suppose there might be a way to code some sort of subroutine to extend
"lock", but I'm not that advanced yet. :)
--
^
_' `_ * Kevin Lo -- http://www.nexusprime.org/personal/klo/
.-~' `~-. - k...@bigfoot.com - HTML / Perl / C / Java
( ' __. ` ) - Callsign: KF4JXF - AKA Radnor & FDC Merlin
`-'' ``-'
Julian Arnold
In article <50j1fd$a...@sjx-ixn5.ix.netcom.com>, Russell Wain Glasser
<URL:mailto:rgla...@ix.netcom.com> wrote:
>
> [...]
> Yes, "nothing" really is a valid indirect object. In fact, it
> appears to me that "nothing" is automatically generated as a noun AND
> as a second if you don't supply them. Am I right? Anyone?
`nothing' is a pseudo-object, defined by the compiler I think, and is
always object number 0, so "if ( noun == nothing ) ...;" is the same as
"if ( noun == 0 ) ...;".
So, if noun (or second) isn't specified in a command, it must equal 0,
which means it must equal nothing.
Jools
--
Greg Falcon
rgla...@ix.netcom.com(Russell Wain Glasser) wrote:
>Extend "unlock" replace
> * noun -> Unlock !This line of code lets you unlock
> !with no indirect object
> * noun "with" noun -> Unlock; !This line lets you unlock in the
> !usual way
> You can then fix up the door with a before routine like you wanted to,
>for instance:
Unfortunately, this example forgot to take two things into account:
error messages and the possible absence of with_key.
For example, say you extend unlock and lock using the above given
method. You might get something acceptable like this:
Living Room
You are in your living room. The only important thing in this example
is a door, which can be easily locked and unlocked without a key.
>unlock door
You unlock the door.
>lock door
You lock the door.
So far, so good. But...
>n
Kitchen
You are in your kitchen. The only important thing in this example is a
cupboard, which can only be locked and unlocked with a key.
>unlock cupboard
That doesn't seem to fit the lock.
See, the Inform libraries never expected to handle the UNLOCK action
without an indirect object, so the error messages go batty. An even
worse consequence:
>e
Dining Room
You are in the dining room. The only important thing in this example
is a mysterious cube, which has the attributes locked, lockable, and
openable, yet has no with_key defined, and therefore can never be
unlocked with any object in the game.
>unlock cube with key
That doesn't seem to fit the lock.
>unlock cube with banana
That doesn't seem to fit the lock.
>unlock cube
You unlock the cube.
Making a separate action for unlocking and locking without an indirect
object seems to be the best workable solution.
My $0.02.
Greg
C:\INFORM>inform thid.inf
Unix Inform 5.5 (v1502/a)
line 3841: Fatal Error: Couldn't open output file "thid.inf.z5"
c:\INFORM>
Ross Raszewski
Kevin Lo wrote:
>
> In article <322CBC...@iserv.net>, har...@iserv.net says...
> > Ok, I'm sure this has been done a million times, and rather than
> > reinvent the wheel I'm going to ask.
> >
> > How do I implement a door that acts like a "normal" door when it comes
> > to the locks? That is, what is the best/easiest way to make a
> > double-sided door which locks/unlocks with a key on one side, and on the
> > other side can be locked/unlocked without a key?
> >
> > It *seemed* really straight forward to simply capture "Unlock" in the
> > 'before []' routine, but the parser prompts "What would you like to
> > unlock the door with?" before the 'before []' routine can intercept.
>
> Nice conecpt! I scoured through all my Inform stuff, and couldn't find
> an "easy" way to do this, other than modifying the source code itself, because
> Inform automatically tests the following if you are trying to lock a door: Is
> it lockable, is it already locked, is it open, and does the direct object (the
> supposed "key") match the with_key variable on the door.
> I suppose there might be a way to code some sort of subroutine to extend
> "lock", but I'm not that advanced yet. :)
That's it, precicely. you have to extend "lock" first * noun
->HandLock; and then trap Handlock. or something similar.
Phil Goetz
In article <323233...@skipjack.bluecrab.org>,
Ross Raszewski <rras...@skipjack.bluecrab.org> wrote:
>Kevin Lo wrote:
>>
>> In article <322CBC...@iserv.net>, har...@iserv.net says...
>> > Ok, I'm sure this has been done a million times, and rather than
>> > reinvent the wheel I'm going to ask.
>> >
>> > How do I implement a door that acts like a "normal" door when it comes
>> > to the locks? That is, what is the best/easiest way to make a
>> > double-sided door which locks/unlocks with a key on one side, and on the
>> > other side can be locked/unlocked without a key?
This is related to something I found while writing my Prolog IF engine:
it makes more sense to ask whether you can reach the inside or the
outside of something, or side A or side B of a door, than whether
you can reach the object.
Phil Go...@cs.buffalo.edu