New to Ropes

You’d want something like this for your example check rule

Check attaching something to something:
   If the noun is the cable and the second noun is the pedestal:
       Rule succeeds;
   Otherwise:
       Say "There doesn't seem to be any way to attach [the noun] to [the second noun].";
       Rule fails.

And then you’d actually manipulate the environment in a carry out rule, and report the results in a report rule. I’d actually try this first and see if it works at all:

Check attaching something to something:
    Say "denial";
    Rule fails.

Check attaching the cable to the pedestal:
    Rule succeeds.

But I’ve never really explored how check rules stack myself, because in this sort of case an instead rule is usually what you want.

Instead of attaching the cable to the pedestal:
   ...

What does the /-- do? Google is not being helpful.

And then the things you want to do will usually be in “Now” commands. See section 8.11 of Writing with Inform for this syntax (and chapter 8 in general on how to change things – well, skip 8.2 and 8.3). So inside your rule you’d have something like:

Now the cable is attached to the pedestal; Now the cable is in Monocable End;

That last line takes care of moving the cable out of the player’s inventory and into Monocable End, assuming Monocable End is the name of the room. They don’t need to be done separately. For the first line, you’d have to define some kind of property for the cable that allows it to be attached to the pedestal; Inform won’t understand “attached to the pedestal” just because there’s an “attaching to” action. For a way to do something like this you could look at the example Otranto (it’s a good idea to look at that example anyway). For instance, you’ll have to write rules that prevent the game from describing the cable as being on the floor and other stuff like that.

Another thing you could do is this:

Now the cable is part of the pedestal:

which will take care of taking the cable out of the player’s inventory and won’t leave it described as being on the floor. Then you want to write rules that make sure that the cable and pedestal have the right description when the cable is part of the pedestal, and that let the player take the cable back (or perhaps even better, give the player a helpful refusal like “The cable is exactly where it needs to be”), and that let the player climb the cable when it’s in the pedestal.

(I hear you cry, “But all I want is a rope like in Zork III! Why can’t I just have a simple rope like in Zork III?” If it’s any consolation for the amount of work we’re trying to get you to do, the rope in Zork III is buggy in a way that really messed up my business – scroll to comments.)

It should be a blank [UPDATE: but it isn’t; see zarf’s post below]. It means [UPDATE: or would mean, if it worked in this context] that the game will understand “attach rope to pedestal” and “attach rope pedestal.”

Option 1 - This had the same effect as before, I keep hitting the default rule, that’s why I believe they need to be nested or stacked in some way. I’ve also tried different ordering of the two rules, which also had no effect.

Check of attaching the cable to the pedestal: say "You clip the end of the cable around the pedestal base and throw it into the abyss."; Now the cable is stuck to the pedestal; Now the cable is in Monocable End; Rule succeeds.
Option 2 - OK, I tried it this way and it didn’t work either–kept running into the “there doesn’t seem to be anyway…” I really need the default rule to keep the cable from being attached to anything and everything. I was thinking of having the silly thing drop to the floor after all this and use it again somewhere, but at this point I can just about say for certain that it won’t be worth it. :slight_smile:

[code]Instead of attaching the cable to the pedestal:
say “You clip the end of the cable around the pedestal base and throw it into the abyss.”;
Now the cable is stuck to the pedestal;
Now the cable is in Monocable End.

Check attaching something to something:
	Say "There doesn't seem to be any way to attach [the noun] to [the second noun].";
	Rule fails.[/code]

Lastly, I commented out the default rule, and that’s where it gets a little strange. When I command “tie cable to pedestal” it brings me immediately back to a blank prompt. It does not do the say or anything else…my guess is that it isn’t matching the rule either as an instead or a check.

Got it. It works, but sadly, I’m not sure exactly why it wasn’t working before. However, the key seems to center on putting the rules in the right order top to bottom. So it works, but then code falls through to also say “There doesn’t seem to be anyway to attach the coil of the cable to the pedestal.” Traditionally, this would be a place for an If, Then, Else clause.

There are still a few other minor issues issues, but they should be easy to clear up. For instance, once the cable is attached it completely goes away as a distinct entity. And that’s fine, but I need to create a check rule so it can still be seen in case anyone looks or tries to pick it back up. I am no longer “moving” it to the next room, since I don’t want to deal with it any longer, I am just checking attachment to allow the player to move down.

I’m going to post a long snippet, which might be bad form for the forum, but I didn’t see any posting guidelines forbidding it. Anyway, just in case someone is following after and wants to see how I ended up. Also, if anyone sees something unnecessary or that could be tightened up, please say so. Thanks for all the help, everyone!

[code][Drawbridge]
Drawbridge is a room. “You are standing over a dark abyss on bridge even now retracting inexorably into a featureless wall. [if unvisited]You stand alone within this long-empty and mysterious facility deep beneath the surface of a dead planet known as First Light. Despite the movement of the platform beneath your boots, the silence in the cavern deafens you. The door cutting you off from your friends just disappeared into the wall of an immense cyndrilical structure before you. Unless something changes, the bridge will be drawn completely out from under your boots. [end if]Time grows short as the gap between the wall and the bridge grows wider.” The player carries a helmet. The player wears a space suit, a coil of cable.

Up from the Drawbridge is the Ceiling.  Check going up from the Drawbridge: say "The rocky cavern ceiling arches unreachable hundreds of meters overhead." instead.
Down from the Drawbridge is the Monocable End.  
	
Check climbing the cable when the cable is stuck to the pedestal: try going down instead.
Check going down from Drawbridge when the cable is not stuck to the pedestal: say "You peer over the brink into the darkness but think better of it." instead.  

The pedestal is a thing.  The pedestal is in the Drawbridge.  The pedestal is fixed in place.  The description of the pedestal is "Raised to nearly chest height, the square pedestal measures about twenty centimeters on each side.  It is fashioned from the same strange material as the bridge itself.  On the topmost face of the pedestal a few controls glow."

The cable is a thing.  The cable is wearable.  The description of the cable is "The monofilament cable runs about two hundred meters in length, but remains nicely compact and easy to carry, coiled over one shoulder.  It rates at two hundred kilograms of capacity and features a clip at both ends."

Attachment relates things to each other in groups. 
The verb to be stuck to implies the attachment relation.
Understand "cable" as coil of cable.
Understand the command "attach", "fasten", "tie" as something new.
Attaching it to is an action applying to two touchable things.
Understand "attach [something] to/-- [something]" as attaching it to.
Understand the command "connect" or "tie" or "hook" or "clip" or "fasten" as "attach".
Definition: a thing is noncable if it is not a cable.
Definition: a thing is tied if the number of things stuck to it is greater than 1.
Definition: a thing is free if it is not tied.
Definition: a cable is free if the number of noncable things stuck to it is less than 2.
Definition: a thing is hindering if it is stuck to the noun and it is not within the location.
Definition: something is anchored if it is fixed in place or it is scenery or it is part of an anchored thing.
Before attaching the cable to the pedestal:
	Say "You clip the end of the cable around the pedestal base and throw it into the abyss.";
	Now the cable is stuck to the pedestal;
	[Now the cable is in Monocable End.]

Check attaching something to something:
	Say "There doesn't seem to be any way to attach [the noun] to [the second noun].";
	Rule fails.[/code]

Nothing wrong with posting a big excerpt – it makes it easier to look at your code! If it’s megabig you might want to put it in a spoiler tag but this doesn’t seem too long to me.

So what makes this code work is not the rule order in the source text but your use of the “before” and “check” rulebooks. “Before” rules always run before “check” rules which is why the “Before” rule is running first. Then there isn’t anything stopping the “check” rule from running.

I’m not sure why your Option 1 didn’t work; I changed the “Before” rule to this:

Check attaching the cable to the pedestal: Say "You clip the end of the cable around the pedestal base and throw it into the abyss."; Now the cable is stuck to the pedestal; rule succeeds.

and it worked, even when this rule was listed after the other one in the source text. The idea is that more specific rules run first so “Check attaching the cable to the pedestal” runs before “check attaching something to something.” And “rule succeeds” stops the other rules from running.

If you want to get fancy, it’s considered baddish form to have all this stuff going on in a “check” rule; you can have a “check” rule to see whether the action is possible (and print a message if it isn’t), a “carry out” rule to perform the effect of the action, and a “report” rule to print the message. They will run in that order if not stopped, the way your “check” rule stops attaching something to something. In this case, we can use “instead” in the middle of the rule which basically is the same thing as “stop the action” except it doesn’t require its own line, and use our “check” rule to check whether we’ve got the right stuff:

[code]Check attaching something to something:
unless the noun is the cable and the second noun is the pedestal:
Say “There doesn’t seem to be any way to attach [the noun] to [the second noun].” instead.

Carry out attaching the cable to the pedestal:
	now the cable is stuck to the pedestal.

Report attaching the cable to the pedestal:
	say "You clip the end of the cable around the pedestal base and throw it into the abyss."
	[/code]

“Unless” works as in English: “If this is not true, do this.” This may not be necessary for your purposes but it might be nice. BTW, to get the nested indents to work I had to make sure that rule started without any indentations; I wonder if part of your problem is that you’re indenting your rules too much. The first line of a rule doesn’t need to be indented.

Good to know–different forums have different ways.

Groovy. That helps.

I discovered the “stop the action” bit, and got my little issue resolved, but I think I would like to try it your way. Not having it look a mess remains a goal, maybe not the highest priority, but at least somewhere on the continuum.

Yeah, I’m big on indenting code. Just began to get the picture that I am probably targeting my own foot with it. I’ll try to stop it. :slight_smile:

Thanks again to everyone that helped!

You’d probably want this to work the other way around as well, so “attach pedestal to cable” works in exactly the same way as “attach cable to pedestal”. It would be a little harsh to punish the former.

This is a helpful feature, actually, but it doesn’t seem to like any type of null (that I could find) to make the command “attach rope pedestal” function. Which is really alright with me anyway. I tried a space, and two brackets , but then realized I didn’t really care. :slight_smile: Now OTHER words I did care about, such as around and on.

Understand "attach [something] around/on/to [something]" as attaching it to.

That pair of hyphens is the blank (or a placeholder for nothing as it were).
In that context “to/–” means that a player’s command can have either the word TO or nothing in that position.

I have no reason not to believe you other than it doesn’t seem to work that way in practice. :slight_smile: I get the response “I don’t understand that sentence.” I’m sure it’s my own fault–some kind of issue with syntax–but since everything else works, this small bit doesn’t bug me.

Not true, as Fourthlaw has discovered.

That abbreviation can be used in defining phases (“To say the/-- banner text: …”) but not in grammar or topics.

Oops! My bad… Sorry.

How odd. It compiles just fine… and then fails to match a blank.

It matches “–”, you see.

That’s an… interesting design decision.

What’s interesting about it?

That the slash syntax is available (unless I’m completely confused, which is always possible) for phrases, grammar, and topics, but “–” matches a blank in phrases and “–” in grammar and topics. Seems like something that would naturally lead to people trying to use “–” in grammar lines and getting confused why it doesn’t work.