turning something in a direction is an action applying to one thing and one topic.
Understand "turn [something] [text]" as turning something in a direction.
You can see this action requires 2 bits of data.
An action like ‘taking’ only requires 1 bit of data, so from within Inform, I can redirect another action to it with something like this:
instead try taking noun;
How could I redirect an action to my ‘turning something in a direction’ action above?
I was not surprised that when I tried this higgledypiggledy–
instead try turning something in a direction roundabout topic understood;
where ‘roundabout’ was the intended (something) and the topic understood was the intended (text), that it did not work.
I am redirecting from an action which requires only one thing, a text - IE the player will have supplied a topic, but no noun. So I’m supplying the noun (the roundabout) but I wanna grab the player’s topic, then feed it into the ‘turning something in a direction’ action.
I recently dealt with what may be a similar situation. The game includes a firearm, which can be used in one of two ways. One way is a “shooting” action, which requires one object (the shootee). The other way is first to use an “aiming” action, which takes one object (the target), and then to use a “triggerpulling” action which takes no objects. The triggerpulling action redirects to “shooting,” using the noun previously designated as the target (in the aiming action) as the object of “shooting.” I don’t seem to recall any real problems in getting this to work, although I don’t know if redirecting from a single-noun action to a double-noun action is different in this regard than redirecting from a no-noun action to a single-noun action.
I’m at work now and don’t have access to the code, but I’ll try to post it when I get home this evening.
You need to include the word “it” in any action’s name that takes two nouns (or a noun + topic). “It” is replaced by the first noun when needed.
[code]Turning it in a direction is an action applying to one thing and one topic.
Understand “turn [something] [text]” as turning it in a direction.
Instead of turning the foo in a direction:
try turning the bar in a direction topic understood.
(Personally I’d name the action something that reads better in rules, but that’s just personal preference.)
Me too. Maybe just “turning it in” or perhaps “turning it in the direction of”
I don’t like using topics, though - their parsing is so different from everything else, and they’re especially tricky when redirecting actions as you are. I’d probably use a kind of value in a case like this:
[code]Roof is a room.
There is a weather vane in roof. The weather vane has a direction called the orientation.
Rotation is a kind of value. The rotations are left and right. Understand “counterclockwise” as left. Understand “clockwise” as right.
Turning it towards is an action applying to one thing and one rotation.
Understand “turn [something] to [rotation]” as turning it towards.
Understand “turn [something] [rotation]” as turning it towards.
Understand “turn [something] [text]” as a mistake (“You can only turn something to the left or to the right.”)
Check turning something towards a rotation:
say “It’s stuck.”;
stop the action.
test me with “turn weather vane to north/turn weather vane to left/turn weather vane clockwise”[/code]
That was a pretty cool demo, capmikee. Almost cool enough to get me to rewrite this chunk of the game your way for the sake of learning a new way to do stuff (I have yet to create my own value). Though of course I’ve got it all working my way now, so I’m reticent to redo a thing that works.
Also, your value way removes a degree of error checking. There’s a hitch with doing it with topics like I have been - the topic understood could be any number of words.
EG - Say there’s a wheel in the game, but the wheel’s not in the current room and someone types ‘turn wheel left’. Wheel doesn’t snag a noun, so ‘turn (thing) (topic)’ doesn’t go off. Instead the whole action falls through to ‘turn (topic)’ (which was designed to catch plain old ‘turn left’), and the topic is now ‘wheel left’. At this point Inform tries to match ‘wheel left’ to a direction, fails, and says ‘that isn’t a direction you can turn’ - which is not a graceful response to what was entered (even if what was entered was kinda dumb.)
To eliminate that, I had to throw in a check to make sure there was only 1 word in the topic the player entered before it gave the above error message.
It sounds like it may no longer be relevant, but here is the code I referred to earlier. Actually, my memory was a bit faulty in couple of respects: First, the shooting action in fact involved two nouns (albeit one that could be supplied if omitted by the player). Second, I did not create a separate "triggerpulling action; instead, I used the existing “pulling” action. Thus, the redirection (like yours) was from a one-noun action (pulling [the trigger]) to a two-noun action (shooting it with).
[code]Shooting it with is an action applying to one visible thing and one thing.
Understand “shoot [anything] with [something]” as shooting it with. Understand “shoot [something] at [anything]” as shooting it with (with nouns reversed). Understand “shoot [something]” as shooting it with.
Rule for supplying a missing second noun while shooting:
If the player has the gun:
Now the second noun is the gun;
Say “You have nothing to shoot with.” instead.
Check shooting it with:
If the second noun is not the gun:
say “You can[apostrophe]t shoot with that!” instead;
If the player does not have the gun :
say “You can[apostrophe]t shoot with a gun that you aren[apostrophe]t carrying.” instead.
Carry out shooting:
Say “BANG! You shoot [the noun]”.
The target is an object which varies. The target is nothing.
Aiming it at is an action applying to one thing and one visible thing.
Understand “aim [something] at [a visible thing]” as aiming it at.
Rule for supplying a missing noun while aiming:
If the player has the gun:
Now the noun is the gun;
Say “What do you want to aim at [the second noun]?” instead.
If the player does not have the noun:
Say “You don[apostrophe]t have [the noun].” instead;
If the second noun is not visible:
Say “You can[apostrophe]t aim at something you can[apostrophe]see.” instead;
If the noun is not the gun, say “You can[apostrophe]t aim [the noun].” instead.
Carry out aiming:
Now the target is the second noun;
Say “You point the gun at [the second noun].”.
Before doing anything other than aiming or pulling the trigger or shooting when the target is not nothing:
Now the target is nothing;
Say “(Lowering the gun first)”.
Instead of pulling the trigger:
If the player does not have the gun:
Say “You do not have any object with a trigger to pull”;
Stop the action;
If the target is nothing:
Say “It would be dangerous to pull the trigger on a firearm which is not aimed at anything.”;
Stop the action;
Try shooting the target with the gun.
Every turn when the target is not nothing:
If the target is not visible:
Now the target is nothing.
“Anything” and “something” are synonymous to Inform, but “something” and “any thing” (in two words) are not.
The [something] and [anything] tokens in a command line correspond to an “applying to one thing” in an action definition.
The [any] token ([any thing], [any person], [any door], etc.) in the command line corresponds to an “applying to one visible thing” in an action definition.
And defining an action as applying to a visible thing means that the action will work at a distance, as it were, i.e. that the action can successfully take nouns or second nouns that are NOT visible or otherwise in scope. (But I guess you knew that…)
On the first point, I think I may have been under the mistaken impression that I needed to use the “anything” formulation in order to allow aiming or shooting where the target is visible but not necessarily reachable.
On the second point, I thought that using the [apostrophe] formulation was necessary in order to avoid Inform 7 reading an actual apostrophe character as a single quote (which it then transforms into a double quote). Is that not correct?
I’m not sure my solution would do any better. The problem is that when you have a grammar that works on unseen things (like kind of value), you get the “that noun did not make sense in that context” error instead of the “you can’t see any such thing error.” I try to create a fallback grammar for cases like that, which is why I added the “Understand ‘turn [something] [text]’ as a mistake” grammar… but that might possibly give you equally inappropriate failure messages.
If there are only two allowed directions, I’d make two separate actions that have the directions hardcoded and avoid the whole topic issue altogether:
[code]Turning it right is an action applying to one thing.
Understand “turn [something] right/clockwise” as turning it right.
Turning it left is an action applying to one thing.
Understand “turn [something] left/counterclockwise” as turning it left.
You can use the “turn (thing) (topic)” to catch all other cases.
Understand "turn [something] [text]" as a mistake ("You can turn things only left or right.")
If you want to save some typing you can group the both actions into one so you can write rules like “Carry out directional turning when the noun is the wheel: …”
Turning something left is directional turning.
Turning something right is directional turning.
That looks pretty smart. Though after analysing it a bit, I realised it would probably use up more grammar tokens for the command ‘turn’ than I have left (even when replacing current grammar, and then after adding back in my desired variations). Which is unlikely to be most people’s problem, but it’s my problem
Today, Inform told me I had already used too many alternative phrasings on the ‘turn’ command, and wouldn’t compile. So I already had to ditch some of the deeper error-catching in that area and simplify. I can now see that an advantage of putting all your alternatives in a table is that it only takes up one grammar slot to match all alternatives (turn thing [text]), no matter how many words are in each alternative.