Trying a standard action which has been changed

I’m currently working on trying to rip up an replace how the locking and unlocking standard actions work and I’m finding it difficult to wrap my head around what I’m doing wrong. I’m not too sure what segments of the code are really relevant but to start what I’ve been trying is to use:

Understand the commands "lock" and "unlock" as something new.
Understand nothing as locking it with.
Understand nothing as unlocking it with.

To ignore the standard locking and unlocking actions.

I am then defining two new actions which use the old command:

Keyed Locking it with is an action applying to two things.

Understand "Lock [a door] with [a key]" as keyed locking it with.

Keyed unlocking it with is an action applying to two things.

Understand "Unlock [a door] with [a key]" as keyed unlocking it with.

However when I go to use try:

try unlocking test door with test key.

This carries out the standard rules for locking it with and unlocking it with, not my new action. I’ve also noticed I can’t clarify which action by using:

try keyed unlocking test door with test key.

Which fails to compile.

Is this just a problem with trying to use the same command for a new action? Or is there something I need to do to more completely remove the old actions?

1 Like

The issue here I think is that all this stuff…

Understand the commands "lock" and "unlock" as something new.
Understand nothing as locking it with.
Understand nothing as unlocking it with.

…is about removing the player’s ability to invoking the looking it with/unlocking it with commands – you’ve removed the Understand statements linking player input to those actions. But they still exist in the Standard Rules, so when you tell Inform to do this:

try unlocking test door with test key.

It understands you as invoking the standard unlocking action. When you’re writing code, you can’t use the various forms of alternate grammar/syntax an Understand command lets you offer to the player; this is just the same issue playing out in reverse.

In theory I guess you could remove the actions from a custom version of the Standard Rules and include those in your project instead; fortunately, you don’t need to get so drastic, since you should be able to just name your new commands something that doesn’t overlap with the old action – keyed-unlocking it with should work, I’d think – and never mess with the out-of-the-box locking and unlocking actions.

3 Likes

I’ve tried using:

Try keyed unlocking the test door with the test key.

But this results in a failure to compile even though this is how I have the new actuons defined with:

Keyed unlocking it with is an action applying to two things.

Thank you for explaining how those other statements only affect the parsers understanding though. Perhaps i will just need to completely replace this section of the standard rules as you state. I’ll have to read more on what the best way to do that is unless you or someone else could suggest the best approach for this.

What kind of error message does the compiler give, and in which context are you using the “Try …” statement?

It works fine for me in a minimal project including your action definitions above, a test door and a test key, and this line as an example:

Instead of jumping:
	try keyed unlocking test door with test key.
3 Likes

The error message is:

Problem. You wrote ‘try the actor keyed unlocking the noun with the key’ : but this is not an action I recognise, or else is malformed in a way I can’t see how to sort out.

See the manual: 7.4 > 7.4. Try and try silently

I was trying to match this phrase:

try (actor keyed unlocking the noun with the key - action)

But I didn’t recognise ‘actor keyed unlocking the noun with the key’.

From the otherwise statement in this block of code:

The new can't open what's locked rule is listed instead of the can't open what's locked rule in the check opening rulebook.

Check an actor opening when the noun is locked (this is the new can't open what's locked rule):
	if the noun is keyless locked:
		if the location of the actor is the lockable side of the noun:
			try the actor unlocking the noun;
	otherwise if the noun is key locked:
		if the actor carries a key that key-unlocks the noun:
			repeat with key running through keys carried by the actor:
				if the key key-unlocks the noun:
					try the actor keyed unlocking the noun with the key;
	if the actor is the player:
		say "[regarding the noun][They] [seem] to be locked." (A);
	stop the action.

The syntax for instructing Inform to try to let actors try something is slightly different; it should work if you insert a “trying” before the action:

try the actor trying keyed unlocking the noun with the key;

By the way, note that the way the rule is written in your example will mean that if the player carries the key, he will unlock the door when opening it, and then the message “It seems to be locked.” will still come up.

Edited to add: You might also take a look at the extension “Locksmith” by Emily Short, maybe it already provides the functionality you need. Edited to further add: Mathbrush already posted it while I was typing, timing. :slight_smile:

4 Likes

This isn’t directly related to the question, but I was messing with locks a lot today, and found it really useful to look at Emily Shirt’s code for the Locksmith extension. You can find it by clicking the file menu and Open Installed Extensions. She does some really neat stuff, some of which is almost identical to what you’ve typed here.

3 Likes