[I7] clue unlocking but not when unlocking

In the example below, I’ve hardcoded things so you get a hint how to use a red key (or other item) if you just take it, but you don’t get the hint if you unlock it and implicitly take it.

Unfortunately, this isn’t a good general example for other actions that may need a specific verb. Flagging RULES turns up nothing before “(First taking)” and the unlock verb applies to one held thing.

Is there a better more general way to do what I have below? How do we sneak in before the “one held thing” rule, or figure out that the current action is taking but the meta-action/previous action requiring it is unlocking?

[code]“brute force cluing” by Andrew Schultz

the red door is a lockable locked door. the red door is east of room 1. the red door is west of room 2.

the red key unlocks the red door. the red key is in room 1.

check taking red key for the first time:
if word number 1 in the player’s command is not “unlock”:
say “Note: You can [italic type]unlock X with red key[roman type].”;

test nomsg with “unlock red door with red key”

test msg with “take red key”
[/code]

Thanks!

This is one approach:

To decide whether keeping silent: (- keep_silent -).

Check taking red key for the first time:
	unless keeping silent:
		say "Note: You can [italic type]unlock X with red key[roman type].";

This blocks the message for all implicit takes. This is imperfect, obviously (“eat key” will take the key without showing the message).

My solution (which doesn’t answer your question) would be to place the message on both taking and examining. Use an explicit flag, so that it appears at most once – the first examine or the first non-implicit take. And silently set the flag when the unlock succeeds, so that the message won’t appear after the player has already gotten the idea.

I think he wants to do the opposite. It’s not showing the message when he unlocks, and he’d like it to.

[edit]Every time I read this thread I switch which way he wants it.[/edit]

Blocking a message on all implicit takes is definitely a fantastic start. I think it’s more about the flexibility in what I want to say and not hard-coding than whether the message pops up. Again, it’s the sort of thing I’ll need to look at.

Perhaps it makes more sense to give the fourth-wall hinting when the player examines the red key.

I suppose I could also redefine “unlock” to be with something preferably held. I could also use stored actions, but that gets a bit icky. (I just learned about them from googling.)

I thought I thought this all through before posting, but I guess not. Anyway, thanks for yet more help coding Inform 6. It may not fully be natural-language, but it’s closer than I thought it was.

You could also do it like this.

[code]Silent mode is a truth state that varies. Silent mode is false.

A specific action-processing rule (this is the globalise action keeping silent variable rule):
now silent mode is whether or not action keeping silent is true.

The globalise action keeping silent variable rule is listed before the check stage rule in the specific action-processing rules.

Check taking red key for the first time: if silent mode is false, say “Note: You can [italic type]unlock X with red key[roman type].”.[/code]

Hope this helps.

How does that differ?

Dang, there probably is no difference! Looks like I didn’t find the code the connects the I6 “keep_silent” variable to the I7 “action keeping silent” one! I still can’t find it!

Heh – I missed the I7 “action keeping silent” flag entirely. Would have used that in my example if I’d seen it.

The I6 variable is shoved into the current-action heap block by the GenericVerbSub() routine.