I’m a relative newbie at IF, trying to find an example somewhere in Inform 7 of how to fish a key out of a vent using fishing rod. Any help is most most welcome! 
I don’t think there’s an example that’s exactly about fishing things with other things, but basically you would need to create a new action (chapter 12.7. in the manual) for fishing stuff with the rod, and you would need to prevent the player from taking the key without the rod (Instead of taking; see ch. 7.2). What have you tried and where are you having problems?
Fishing is an action applying to one thing. Understand “fish for/out [something]” and “fish for/out [something] with rod” as fishing. [INCLUDE OTHER UNDERSTANDS]
Check fishing:
if the player does not carry the rod, say “You have nothing to fish with.” instead.
Carry out fishing:
if the noun is the key and the key is in the grate, say “You fish out the key.”;
now the player carries the key.
Instead of taking something which is in the grate, say “You can’t reach.”
You’ll also need a default response for fishing out other things with the rod. I’d put fishing the key under a check condition:
Check fishing:
if the noun is the key and the key is in the grate, say “You fish out the key.”;
now the player carries the key instead.
And use something generic for “carry out”:
Carry out fishing:
say “You can’t fish [that-those]!”.
(You’d need Plurality to do [that-those] - otherwise, you’ll need to come up with a generic refusal.)
Consider also that people may want to fish wish, fish in, fish around, etc. You’ll need to add these clauses for a smooth play experience.
Something like this (not compiled - sorry!) would properly address the situation when someone types >FISH IN GRATE (assuming you’ve added the appropriate “understand” clauses.)
Check fishing a container:
if there is something in the noun:
try fishing a random thing in the noun instead.
I wouldn’t do that: while it works, it’s the complete opposite of what the check and carry out rules are designed to do. Check rules should stop unsuccessful attempts and carry out/report should be used when the action is successful.
[code]Fishing it with is an action applying to one visible thing and one carried thing. [+ understands]
Check fishing something with the rod when the noun is not the key: [unsuccessful attempts]
say “You can’t fish [that-those]!” instead.
[+ checks for fishing with something other than the rod, fishing the key after the first time etc]
Carry out fishing with: [the outcome of fishing]
now the player carries the key.
Report fishing with: [report of successful fishing]
say “You fish out [the noun].”[/code]
Nah, I use check rules that way all the time.
It wrecks the compiler’s built-in notion of “if we have fished”, since check outcomes don’t count as successful actions. But then, I don’t use those.
Juhana, I agree with you in most cases; you should follow the intent of the rule structure in general (particularly if you’re using extensions like Aaron Reed’s Intelligent Hinting, which depend on proper action success/failure behavior), but there are often problems with the placement of report text in the output, as well as problems with complex condition tests where the initial conditions that obtained in the check rule no longer do after the “carry out” phase. In those cases, lumping your logic into Check rules might be the best way to go.
Sure, but that’s what instead rules are for, right?
Assuming I understand what you mean (e.g., that the report rule is tricky because it requires printing something based on information that has since changed): the official solution (whether you want to use it or not) is to add action variables and store that information for the duration of the action processing.
They’re probably overkill for a one-off exception, but useful if you want to do complex things systematically, like have a lot of different exceptions about what gets fished from what.
@Juhana – yes, but Check rules are action-specific, so they don’t bloat up the Instead rulebook that gets evaluated for every action. I know these can be automatically optimized in some circumstances, but I’ve been trying to speed up a slow WIP under Quixe lately, so please forgive my performance anxiety. 
@Emily, you did understand me and your point is well-taken. I’ve used standalone variables for this also, but action variables would certainly be cleaner.
Matt
Yes, I’ve been hearing talk about this but I’m extremely sceptical about how much the instead rules actually slow the game down. How many insteads does it take for the difference to be noticeable? 10? 50? 1000? Is the limit anywhere within realistic boundaries? Has anyone ever actually measured this? Because just that they are evaluated doesn’t automatically mean that they actually slow the game down any more than milliseconds. I might be wrong about this, but I’ve heard people removing instead rules because they show up in the RULES ALL list, but the “lag between turns halved after I did this” stories are conspicuously missing.
I can’t answer that; I’ve not run hard test numbers. That sounds like a great experiment to try, though, so I’ll try to work up a test under Quixe and give it a shot. Just off the cuff I’d suspect that you’re right, that you’d need a lot of (unoptimized) Instead rules to see marked slowdowns, but hard numbers would be nice.
I do know that Eric Eve implemented Conversation Responses at least partially for this reason. From his documentation:
I’ll try to see if I can run a quick Quixe test tonight and let you know the results.
Thank you so much everyone! I’ll tackle the fishing problem asap and let you know how it all goes. And groovy that I even managed to spark a debate about it!
BTW, although I can’t off much in return advice on the technical front, I’m going to start a thread about storytelling and offer knowledge in that way (have been a full-time pro screenwriter now for four years). So any story or writing questions you have - fire away!
Hi all - I’ve just tried Grave’s code and it’s almost working 
The only problem is that it’s not recognising when the player is carrying the rod. Is there a line I need to put in, something about allowing the action if the player carries the rod?
I tested this last month. By now I don’t remember details, but I found that when the compiler sees more than eight or ten Instead rules, it optimizes the code, so that they’re not ALL consulted.
In other words, it appeared from my tests that while the manual tells you (on p. 12.2) that there is one Instead rulebook, in games of any size there will be separate Instead rulebooks for various actions.
If you want to test it, write a test game and then start adding Instead rules, one at a time, while running the game with ‘rules all’. At some point you’ll stop seeing consultation of all of your Instead rules in response to irrelevant actions. Now, this could be because ‘rules all’ is suppressing information, but that seems less likely to me than that the compiler is performing optimization.
–JA
The short answer: Yes. The longer answer: This is why using check rules in the canonical way is better. Inserting a bunch of conditions into a check rule, and in the desired order, is the graceful way to handle complex actions. Here’s some code. I tested it a bit, and it seems to work. Obviously you’d need to add more synonyms.
[code]The Patio is a room. The grate is a container in the patio. The key is in the grate.
Instead of taking something when the noun is in the grate, say “You can’t. The bars of the grate get in the way.”
The player carries a fishing pole and a nickel.
Fishing it out with is an action applying to two things and requiring light. Understand “fish [something] out with [something]” and “fish out [something] with [something]” as fishing it out with.
Check fishing it out with:
if the second noun is not the fishing pole:
say “You can’t fish with that.” instead;
otherwise if the player does not carry the fishing pole:
say “You need to be holding the pole to do that.” instead;
otherwise if the player carries the noun:
say “You’re already holding [the noun].” instead;
otherwise if the noun is not in the grate:
say “Why not just pick up [the noun]?” instead;
otherwise if the noun is not the key:
say “[The noun] is too slippery. The hook on the end of the fishing line can’t hook it.” instead.
Carry out fishing it out with:
now the player carries the key.
Report fishing it out with:
say “Using the fishing pole, you retrieve a key from the grate.”
Fishing for is an action applying to one thing and requiring light. Understand “fish for [something]” and “fish out [something]” as fishing for.
Check fishing for:
if the player does not carry the fishing pole:
say “You have nothing to fish with.” instead;
if the player carries the noun:
say “You already have [the noun].” instead;
otherwise if the noun is not in the grate:
say “Why not just pick up [the noun]?” instead.
Carry out fishing for:
try fishing the noun out with the fishing pole instead.[/code]
The point is, by writing a check rule in this way, you can stuff all sorts of conditions in it, and put them in the most desirable order.
I’ve added a couple of enhancements. I created a ‘fish for X’ action, because that’s an input that a player might use. You’ll want to add other synonyms to both actions. I also made it so that if the player puts something else in the grate, such as a nickel, the pole can’t retrieve it. Here again, I would want to enhance that code for a real game. Among other things, the grate should refuse to accept large objects! As it stands, the game can be made unwinnable by putting the pole in the grate (which is a command a player might try first…).
Hope that helps.
–JA
Beautiful, thank you JA! I’ll try this code out as soon as I can this afternoon. Am itching to see this puzzle finally fall into place!
If you’re going to have “Fish out key with rod” as the command that yields the desired behavior, you should also allow “take key with rod/get key with rod/etc.” or at least answer that with a hint that the player ought to be using “fish.” Otherwise you’re likely to create a guess-the-verb situation. Or you could provide explicit instructions when you introduce the rod – “(To fish for something with the rod, type FISH OUT whatever WITH ROD)”, though even then I think it’d be user-friendly to allow TAKE KEY WITH ROD as well.
A good point! I’ll suss that out.
My current problem now is getting the game to recognise that the player is carrying the fishing rod.
Have had to use this to allow the character to construct the rod out of three items:
Limbo is a container. Limbo contains a hookless fishing rod, a hooked line, and a complete fishing rod.
Of course now it won’t allow me to have Player carries the fishing rod.
Is there a way of moving the rod from limbo to being carried or do I have to rewrite some other stuff first?
Yes, with “now”. “Now the player carries the complete fishing rod.” (Manual chapter 2.2). Although it might be easier to not use separate objects: you could do
[code]
The fishing rod is a thing. The hooked line is a thing.
Definition: the fishing rod is complete rather than incomplete if the hooked line is part of it.
Instead of tying the hooked line to an incomplete fishing rod:
say “Now it’s a complete fishing apparatus.”;
now the hooked line is part of the fishing rod.[/code]
and then test the complete or incomplete status wherever needed.
(Also note that you don’t necessarily need a special limbo container; you can just say “A hookless fishing rod is a thing. A hooked line is a thing. A complete fishing rod is a thing.” Things are out out of play (in a “limbo”) if they aren’t specifically designated anywhere.)