Preference an action during a scene

[wmodes (Wes Modes)]

I have an action room_navigating, as in *go to grassy clearing." To do this I need to allow the player to go to any room:

Room_navigating is an action applying to one thing.
Understand
	"go back/- to/around/near/by/-- [any room]",
	"return to [any room]",
	"walk to/-- [any room]",
	"run to/-- [any room]",
	"follow [any room]" 
	as room_navigating.

Check room_navigating:
	if the noun is the location, say "Well, happily you're already here." instead;

Carry out room_navigating:
	let initial location be the location;
	let the destination be the noun;
	if the initial location is the destination,
		say "." instead;
	let heading be the best route from the initial location to the destination;
	[ say "(DEBUG: heading toward [noun] is [heading])[line break]"; ]
	if heading is nothing:
		say cant_find_that instead;
	else:
		now player is not discouraged_from_compass_navigating;
		try going heading.

There’s also a fail-room-navigating action to catch those rooms that are unreachable and render a sensical message.

This form of navigating is used during the majority of the game as a response to the unnatural IF convention of using compass directions. (I also have compass directions disabled during most of the game.)

All that is fine and works pretty well.

In one section of the game (Scene_Lost), we have elusive landmarks that are selected at random for the player to head for.

The_distance is a container.
The_distance is in Limbo.
Definition: an elusive_landmark is distant if it is in the_distance.

landmark_navigating is an action applying to one thing.
Understand
	"go to/near/by/-- [any distant elusive_landmark]",
	"walk to/near/by/-- [any distant elusive_landmark]",
	"run to/near/by/-- [any distant elusive_landmark]",
	"landmark_navigate [any distant elusive_landmark]"
	as landmark_navigating.

Check landmark_navigating:
	if the noun is visible:
		say "Well, that's right here." instead;
	if the noun is not in the_distance:
		say cant_find_that instead;

To say cant_find_that:
	say "You're no longer sure how to get there. [looking_for_available_exits]";

Carry out landmark_navigating:
	say "You head toward the [noun].[run paragraph on] ";
	move_within_dark_woods.

The can't reach inside rooms rule does nothing if landmark_navigating.

move_within_dark_woods does the dirty work of moving the distant landmark to the current location, moving the old landmark to Limbo, and selecting a new distant landmark.

All that works pretty good as well. However…

In the scene where the player should be landmark_navigating (Scene_Lost), I want a command such as go to tree to privilege landmark_navigating rather than room_navigating.

>l
[looking]
Dark Woods
You are not completely certain which way to go. The woods look familiar and altogether strange. It’s difficult to get your bearings. The forest slopes down into a shallow draw. Here there is a broad trail.

Wait, in the distance, you can just make out a white tree. This may be the way back to Honey and Grandpa. You long to give him a hug and never let go.
[looking - succeeded]

>go to tree
[room_navigating Top of the Sentinel Tree]
You’re no longer sure how to get there. You take a quick look around you: Whew, in the distance you can just make out a white tree.
[room_navigating Top of the Sentinel Tree - failed]

>go to white tree
[landmark_navigating the white tree]
You head toward the white tree. You bushwhack your way through the underbrush.

[(1) looking]
Dark Woods
You are confused. The woods look familiar and altogether strange. It’s difficult to get your bearings. The trail tops a small rise. Here there is a white tree.

Finally, a ways off, there is a burned out tree.
[(1) looking - succeeded]
[landmark_navigating the white tree - succeeded]

I’ve tried:

Does the player mean landmark_navigating during Scene_Lost:
	It is very likely.

Does the player mean room_navigating during Scene_Lost:
	It is very unlikely.

to no avail. rules doesn’t seem to show these “Does the player mean” rules.

I don’t want to disable the room_navigating but to have landmark_navigating prioritized during this scene and have “tree” match the object that landmark_navigating applies to.

Thoughts?

[severedhand]

Could it be because at the grammar level, ‘distant elusive_landmark’ is a more specific condition than ‘any room’ ? In which case, following Inform’s prioritising of specificity, landmark_navigating could keep room_navigating out of the equation whenever you type a term that could be either? That’s something I’d have to verify with a test.

One solution to this kind of thing in general is to ultimately funnel all auto-navigation through one mechanism.

I have this approach in my game, where the player can go to rooms, but also to things. I have a separate grammar token for each:

…“go to” [any room]" as approaching

…“go to [any thing]” as thing-approaching

– and extra check rules on attempts to go to a thing (e.g. go to jug). But once the game decides the player wants to go to the jug, what it does behind the scenes is convert this to an attempt to go to the room containing the jug. In other words, it then puts the jug’s room back into the ‘any room’ action to actually get the player there.

Using this approach, DTPM rules work. I can say things like ‘Does the player mean thing-approaching the jug when scene_1 is true: it is very unlikely’, or ‘Does the player mean approaching the forest: it is likely.’ Then I can tweak these rules as usual to produce the desired situational outcome.

This is just one way to approach the problem. Someone may have something that works with the way you’ve already split the actions.

-Wade

[drpeterbatesuk (Dr Peter Bates)]

@severedhand

Could it be because at the grammar level, ‘distant elusive_landmark’ is a more specific condition than ‘any room’ ? In which case, following Inform’s prioritising of specificity, landmark_navigating could keep room_navigating out of the equation whenever you type a term that could be either? That’s something I’d have to verify with a test.

As I understand it, ‘does the player mean’ rules get involved once a grammar line has been matched, and therefore the action has already been decided, but when more than one object could represent the token matched.

Once the parser has identified a verb, it goes through grammar lines for that verb in sequence, until it finds one that matches, and that match then defines the action to be considered. Once a grammar line has been matched, the action is fixed and no subsequent grammar lines are ever considered. ( a grammar line is the I6 code produced by e.g. ‘Understand “(a-verb) [a-grammar-token]” as a-verbing’).

The sequence by which different grammar lines for the same verb are tried (which is the same as the sequence they appear in the I6 code) is set up by the I7 compiler at the time of compilation and can’t be changed by ‘does the player mean’ or other rules.

I haven’t tested all possible cases exhaustively, but it is the case that the compiler gives some types of grammar token priority over others when compiling the grammar line sequence for a verb. The priority is:

[object with a filter]
[something preferably held]
[things preferably held] = [other things]
[things inside]
[object with a scope routine]
[something] = [someone]

Where two types of token have equal priority, their grammar lines are listed in the order they appear in the I7 source.

An [object with a filter] might for example be [thing] (restricts to objects that are things), or [door], or [open something].
An [object with a scope routine] might for example be [any thing] (remove the usual scope restrictions)

so in this case, [distant elusive-landmark] is an object with a filter, and has highest priority, whereas [any room] is an object with a scope routine and will appear lower in the list. Anything the player types that matches ‘verb [distant elusive-landmark]’ will therefore never be tried against ‘verb [any room]’.

[wmodes (Wes Modes)]

@drpeterbatesuk

so in this case, [distant elusive-landmark] is an object with a filter, and has highest priority, whereas [any room] is an object with a scope routine and will appear lower in the list. Anything the player types that matches ‘verb [distant elusive-landmark]’ will therefore never be tried against ‘verb [any room]’.

I think this is the opposite of what I am observing. “Go to tree” matches room_navigating rather than landmark_navigating. “Tree” should be the distant white tree, not the room called top of the tree. Both have understand “tree” as a grammar line. Am I understanding this right?

In which case, following Inform’s prioritising of specificity, landmark_navigating could keep room_navigating out of the equation whenever you type a term that could be either?

To be clear, during a particular scene, I want the parser to prioritize landmark_navigating. Right now it is prioritizing room_navigating.

[severedhand]

@wmodes

To be clear, during a particular scene, I want the parser to prioritize landmark_navigating. Right now it is prioritizing room_navigating.

It might help if you can condense the whole thing (I mean all the code involved) to an example that other people can run.

Something else to check: How have you defined the white tree? I mean, can it definitely be addressed by the word ‘tree’ alone, particularly during scene_lost?

I tried to create a minimal example reproducing your situation, and it seemed to still privilege room-navigating when I just typed ‘go tree’. It’s possible you’ve got something else going on that’s interfering. But I haven’t see your object definitions.

My minimal case:

Summary

dark woods is a room.

tree place is a room.

limbo is a room.

distance is a container in limbo.

an elusive_landmark is a kind of thing.

white tree is an elusive_landmark. it is in distance.

Definition: an elusive_landmark is distant if it is in distance

landmark_navigating is an action applying to one thing.
Understand "go to [any distant elusive_landmark]" as landmark_navigating.

room_navigating is an action applying to one thing.
Understand "go to [any room]" as room_navigating.

Test me with "actions/go to tree".

-Wade

[BadParser]

I added the following code to the OP’s original two posted blocks to get it to compile:

[added]
Dark Woods is a room.
an elusive_landmark is a kind of thing.
The white tree is an elusive_landmark in The_distance.
Top of the Sentinel Tree is a room.
To say looking_for_available_exits:
	say "Not implemented.".
A person can be discouraged_from_compass_navigating or not discouraged_from_compass_navigating.
To move_within_dark_woods:
	say "Not implemented.".
[/added]

And this is the transcript:

Dark Woods

>actions
Actions listing on.

>go to tree
[landmark_navigating the white tree]
That isn't available.
[landmark_navigating the white tree - failed the basic accessibility rule]

>go to sentinel
[room_navigating Top of the Sentinel Tree]
You're no longer sure how to get there. Not implemented.
[room_navigating Top of the Sentinel Tree - succeeded]

Which seems to be the desired effect. (landmark_navigating is preferred)

What are you doing with the tree as far as moving it in and out of the_distance?

[drpeterbatesuk (Dr Peter Bates)]

OK, to see whether it’s the order of the grammar lines that’s the issue, compile your story, then using a file explorer navigate in your Inform → Projects directory to the Build directory of your story and open the auto.inf file in a text editor. Then search in that file for the following text:

Verb 'Go

That will take you to your list of compiled grammar lines, which should look something like

Verb 'go' 'walk' 'run' 
	* -> Go 
	*  noun=Noun_Filter1 -> Go 
	* noun -> Enter 
	* 'to'  noun=Noun_Filter2 -> A_landmark_navigating 
	* 'to'  scope=Scope_Filter1 -> A_room_navigating 
	* 'into' / 'in' / 'inside' / 'through' noun -> Enter;

[drpeterbatesuk (Dr Peter Bates)]

@severedhand

landmark_navigating is an action applying to one thing.
Understand "go to [any distant elusive_landmark]" as landmark_navigating.

room_navigating is an action applying to one thing.
Understand "go to [any room]" as room_navigating.

Here, by using ‘any’ before ‘distant elusive landmark’ in [any distant elusive landmark] you’ve made the token into a scope routine rather than a simple object filter- so the priority of both grammar lines is equal and they will be listed in source order.

If you simply omit ‘any’, no object out-of-scope will match the token, so the grammar line will only match distant objects (and therefore potentially be chosen ahead of room-navigating) if you place them in scope by some other means, e.g. by an ‘After deciding the scope’ rule.

[drpeterbatesuk (Dr Peter Bates)]

@wmodes

@drpeterbatesuk

so in this case, [distant elusive-landmark] is an object with a filter, and has highest priority, whereas [any room] is an object with a scope routine and will appear lower in the list. Anything the player types that matches ‘verb [distant elusive-landmark]’ will therefore never be tried against ‘verb [any room]’.

I think this is the opposite of what I am observing. “Go to tree” matches room_navigating rather than landmark_navigating. “Tree” should be the distant white tree, not the room called top of the tree. Both have understand “tree” as a grammar line. Am I understanding this right?

In which case, following Inform’s prioritising of specificity, landmark_navigating could keep room_navigating out of the equation whenever you type a term that could be either?

To be clear, during a particular scene, I want the parser to prioritize landmark_navigating. Right now it is prioritizing room_navigating.

Looking more closely at your code (oops, sorry!) I see that all your object grammar tokens are prefaced by ‘any’ so they will be listed (and therefore prioritised for parsing) in source-code order. So if by default you want landmark_navigating to be parsed in preference to room_navigating, you’ll need to have their ‘Understand…’ phrases defined in that order in your source.

As a couple of asides:

(i) ‘go’, ‘walk’ and ‘run’ are synonyms, which means that grammar lines that are identical other than the verb are redundant- any of these three synonyms beginning a typed command will match a grammar line defined with 'Understand “go…” ’

(ii) there is a typo in

	"go back/- to/around/near/by/-- [any room]",

there is a missing second hyphen in back/-, meaning the parser will literally try to match ‘back’ or ‘-’ as the second word of this grammar line, so in terms of what the player is likely to type,only ‘go back…’ will work

[BadParser]

@drpeterbatesuk

I see that all your object grammar tokens are prefaced by ‘any’ so they will be listed (and therefore prioritised for parsing) in source-code order.

I’m afraid that doesn’t do it either. (See code below.) I think @severedhand is correct about the specificity determining the precedence. However, as I stated before, the following code seems to yield the desired behavior (regardless of reordering of grammar, action definitions, or the Sentinel tree and Limbo). I don’t see the behavior exhibited in the OP’s original transcript (preferring room to landmark navigating). This is probably due to some conditions created by code not yet posted.

For example, in the original transcript, looking in the Dark Woods yields extra lines, beginning with, “Wait, in the distance, you can just make out a white tree…” Whatever is in the code that causes that might be changing the priority of the nouns. (For example, moving the white tree in and out of the location or scope.)

[BadParser]

Also:

@wmodes

Does the player mean landmark_navigating during Scene_Lost:
	It is very likely.

Does the player mean room_navigating during Scene_Lost:
	It is very unlikely.

I’m surprised this even compiles, since it’s missing an object. The DTPM rules are for disambiguating objects, not actions. It really only allows actions in the rule header to restrict when they are being checked, but they are just trying to determine the noun or second noun.

[drpeterbatesuk (Dr Peter Bates)]

@BadParser

I’m afraid that doesn’t do it either. (See code below.) I think @severedhand is correct about the specificity determining the precedence.

Hmmm. mea culpa, it seems that not all scope routines are created equal with regard to precedence after all- although some are. I’m not sure if the full rules are anywhere documented, but some experimentation suggests at least that

(i) other things being equal, scope routines derived from tokens with a filtered noun take precedence over the rest (so [any open door] will take precedence over [any door], [any person], [any room] etc.)
(ii) scope routines derived from tokens which are a sub-kind of a kind appearing in an otherwise identical token already in the grammar table take precedence and are inserted into the grammar table immediately beforehand (so [any man] takes precedence over and is inserted immediately before [any person], which takes precedence over and is inserted immediately before [any thing])
(iii) Grammar lines with scope routines derived from tokens containing different kinds (that are not sub-kinds of each other) but that are otherwise identical are inserted in source code order.
(iv) as an (apparently unique) rule, the scope routine from [any object] has lower precedence than otherwise identical grammar lines containing [something] or [someone] and is inserted below these

So the reason that source code order makes no difference in this case is that [any distant elusive landmark] refers to a filtered noun, so its scope routine is given precedence over [any room] (which refers to an unfiltered noun) regardless of where they appear in source.

[Zed (Zed Lopez)]

This should work:

Don’t use “any room”; explicitly add rooms to scope and those landmarks that are visible. Have “go” correspond to the same action for both cases, but dispatch to landmark-navigating if the noun is a landmark. Or, if it works out, leave them the same action with a separate Carry out navigating to a room: and Carry out navigating to a landmark:.

A landmark is a kind of thing.

Navigating to is an action applying to one visible thing.
landmark-navigating to is an action applying to one visible thing.

Understand the command "go" as something new.
Understand "go to/-- [landmark]" as navigating to.
Understand "go to/-- [room]" as navigating to.

before navigating to a landmark, instead try landmark-navigating to the noun.

The Tree House is a room.
The Shattered Tree is a landmark.

The Bridge is a room.
The Rock is a landmark.

After deciding the scope of the player:
  repeat with r running through rooms begin;
    place r in scope;
  end repeat;
  place the shattered tree in scope;

carry out navigating to: say "navigate to [noun].".
carry out landmark-navigating to: say "landmark-navigate to [noun].".

Possibly you’ll want a Does the player mean navigating to a landmark: it is likely. but I think just listing the landmark-case’s Understand line first will take care of it.

[wmodes (Wes Modes)]

Okay, here’s a more functional version that demonstrates the challenge I’m having:

Part - Room_Navigating

A person can be discouraged_from_compass_navigating or not discouraged_from_compass_navigating.

Room_navigating is an action applying to one thing.
Understand
	"go back/- to/around/near/by/-- [any room]",
	"return to [any room]",
	"walk to/-- [any room]",
	"run to/-- [any room]",
	"follow [any room]" 
	as room_navigating.

Check room_navigating:
	if the noun is the location, say "Well, happily you're already here." instead;

Carry out room_navigating:
	let initial location be the location;
	let the destination be the noun;
	if the initial location is the destination,
		say "." instead;
	let heading be the best route from the initial location to the destination;
	say "(DEBUG room_navigating: heading toward [noun] is [heading])[line break]";
	if heading is nothing:
		say cant_find_that instead;
	else:
		now player is not discouraged_from_compass_navigating;
		try going heading.

Part - Elusive_Landmarks and Landmark_navigating

An elusive_landmark is a kind of thing.

The_distance is a container.
The_distance is in Limbo.
[ Definition: an elusive_landmark is distant if it is in the_distance. ]

landmark_navigating is an action applying to one visible thing.
Understand
	"go to/near/by/-- [any elusive_landmark]",
	"walk to/near/by/-- [any elusive_landmark]",
	"run to/near/by/-- [any elusive_landmark]",
	"landmark_navigate [any elusive_landmark]"
	as landmark_navigating.

Check landmark_navigating:
	if the noun is touchable:
		say "Well, that's right here." instead;
	if the noun is not in the_distance:
		say cant_find_that instead;

To say cant_find_that:
	say "You're no longer sure how to get there.";

Carry out landmark_navigating:
	say "You head toward the [noun].";
	move_within_dark_woods;
    try looking.

To move_within_dark_woods:
    let distant_thing be a random elusive_landmark in the_distance;
    let next_thing be a random elusive_landmark in Limbo;
    let past_thing be a random elusive_landmark in location;
    now distant_thing is in location;
    now next_thing is in the_distance;
    now past_thing is in Limbo;

The can't reach inside rooms rule does nothing if landmark_navigating.

The can't reach inside rooms rule response (A) is "You can't get there from here."

Part - Rooms & Stuff

Dark Woods is a room.
"[dark_woods_desc].".

To say dark_woods_desc:
    let distant_thing be a random elusive_landmark in the_distance;
    say "It's dark and woody. You see [the distant_thing] in the distance";

The white tree is an elusive_landmark in The_distance.
Understand "tree" as white tree.

The madrone tree is an elusive_landmark in Dark Woods.
The tree stump is an elusive_landmark in Limbo.

Top of the Tree is a room [west of Dark Woods].
Understand "tree" as Top of the Tree.

And running it:

>look
[looking]
Dark Woods
It’s dark and woody. You see the white tree in the distance.
You can see a madrone tree here.
[looking - succeeded]

>go to white tree
[landmark_navigating the white tree]
You head toward the white tree.
[(1) looking]
Dark Woods
It’s dark and woody. You see the tree stump in the distance.
You can see a white tree here.
[(1) looking - succeeded]
[landmark_navigating the white tree - succeeded]

>go to white tree
[landmark_navigating the white tree]
Well, that’s right here.
[landmark_navigating the white tree - succeeded]

>go to tree
[room_navigating Top of the Tree]
(DEBUG room_navigating: heading toward Top of the Tree is nothing)
You’re no longer sure how to get there.
[room_navigating Top of the Tree - succeeded]

You can see that rather than landmark_navigating, it is prioritizing room_navigating with the ambiguous target “tree”.

And as Peter queried, does the order in the source determine which it privileges: I reversed the position within the source of “Part - Room_Navigating” and “Part - Landmark_Navigating,” and voila! It privileges Landmark_Navigating.

Though frustratingly, “go tree” still privileges “room_navigating Top of the Sentinel Tree” rather than “white tree”.

>go to tree
[Rule “Response Assistant reset responses list rule” applies.]
[Rule “ignore beta-comments rule” applies.]
[Rule “new_blank_line_replacement rule” applies.]
[Rule “declare everything initially unmentioned rule” applies.]
[room_navigating Top of the Sentinel Tree]

[drpeterbatesuk (Dr Peter Bates)]

OK, here is your grammar table for the synonyms ‘Go’ ‘Run’ ‘Walk’:

Verb 'go' 'walk' 'run' 
	* -> Go 
	*  noun=Noun_Filter1 -> Go 
	* noun -> Enter 
	* SlashGPR1  scope=Scope_Filter1 -> A_room_navigating 
	* SlashGPR2  scope=Scope_Filter2 -> A_room_navigating 
	* SlashGPR3  scope=Scope_Filter3 -> A_landmark_navigating 
	* SlashGPR4  scope=Scope_Filter4 -> A_landmark_navigating 
	* SlashGPR5  scope=Scope_Filter5 -> A_landmark_navigating 
	* 'into' / 'in' / 'inside' / 'through' noun -> Enter 
	* 'back' / '-//' SlashGPR6  scope=Scope_Filter6 -> A_room_navigating;

This illustrates another rule of grammar line precedence, which appears to trump others already discussed- before sorting on token precedence ( and then subsequently on whether or not a condition is attached, such as ‘when the player is in the Lab’) grammar lines are arranged in ascending order of the number of leading prepositions/alternate prepositions/prepositional parsing routines (SlashGPRx) after the verb.

so:

    "walk to/-- [any room]" (1 prepositional parsing routine, matching 'to/--') and
    "run to/-- [any room]" (1 prepositional parsing routine matching 'to/--')

come before

     "go back/- to/around/near/by/-- [any room] (1 alternate preposition matching 'back/-' (note persisting typo so this is an alternative between 'back' and '-' ( '-//' is arcane I6 code for 'the single character '-') rather than a prepositional parsing routine matching 'back/--') and 1 prepositional parsing routine, matching 'to/around/near/by/--' - so total of 2 (possible) leading prepositions

Note how

 'into' / 'in' / 'inside' / 'through' noun -> Enter 

which has just 1 leading alternate preposition also takes precedence despite having a low-precedence token (noun).

Note that this is the reverse of the example given in WI 17.22 for building new tokens rather than a grammar table. When building a new token possible matches are considered in descending order of number of possible prepositions (the example given being that ‘on top of’ (3 prepositions) comes before ‘on/in/inside’ (1 alternate preposition)).

I think the upshot of all this is that trying to manipulate the precedence of grammar lines to achieve specific game effects is complicated, fiddly and poorly documented/understood, so its best not to rely on it- at least in part because the precedence rules the compiler uses may change without warning or notice.

I think the correct approach must be to not have two separate actions here, but to channel all your grammar lines into one action, and then once that action has left the rarified and arcane workings of the parser and emerged as an action, use Before/Instead/Check/Carry Out/After/Report rules, whose workings are transparent and where you have more control, to separate out and channel your action how you want- into other actions if you like, e.g.

Before going an elusive landmark:
	try landmark_navigating the noun instead.

Note that landmark_navigating can be an ‘untypable’ action with no ‘Understand’ phrases of its own, just existing to receive redirections like the one above.

[wmodes (Wes Modes)]

@drpeterbatesuk

I think the correct approach must be to not have two separate actions here, but to channel all your grammar lines into one action

How would that action look? To minimize the effects on other actions (like swimming or jumping) which also use some of the same verbs, I’d prefer it only matched an elusive_landmark or a room, but

Room_or_landmark_navigating is an action applying to one thing.
Understand
	"go back/-- to/near/by/-- [any room or elusive_landmark]",
	"walk back/-- to/near/by/-- [any room or elusive_landmark]",
	"run back/-- to/near/by/-- [any room or elusive_landmark]",
	"return to/near/by/-- [any room or elusive_landmark]",
	"follow [any room or elusive_landmark]" 
	as room_or_landmark_navigating.

is not legal syntax.

[Zed (Zed Lopez)]

@wmodes

How would that action look? To minimize the effects of other things like swimming or jumping which also use some of the same verbs, I’d prefer it only matched an elusive_landmark or a room, but

``

well, it’d look like my example above where I took the same tack that Dr. Bates advised, right down to noting that it could be one action or two.

Preference an action during a scene

This should work: Don’t use “any room”; explicitly add rooms to scope and those landmarks that are visible. Have “go” correspond to the same action for both cases, but dispatch to landmark-navigating if the noun is a landmark. Or, if it works out, leave them the same action with a separate Carry out navigating to a room: and Carry out navigating to a landmark:. A landmark is a kind of thing. Navigating to is an action applying to one visible thing. landmark-navigating to is an action applying…

[otistdog]

As I understand your essential question, it’s how to get “tree” interpreted by default as the white tree during this scene, but in general to have a room such as Top of the Sentinel Tree preferred.

If that’s the case, then having separate landmark_navigating and room_navigating actions is inherently part of the problem. No matter how you arrange things, the grammar line for one of the actions will come before that of the other. (The same, unfortunately, applies to different specialized grammar lines for a single action.)

Your original approach to use DTPM rules can work only if the parser is trying to decide which object is the noun of a single action, and the rules are checked only while the player’s command is being evaluated to see whether it can be interpreted as validly requesting that action. It is important to understand that DTPM can only differentiate between objects that are in scope because they match to a word or words used in the player’s command. It can’t add things to scope, it can only give a preference (or dispreference) for things already decided to be in scope. [EDIT: Reading back over this, I see that I neglected to clarify an important point here: What is being evaluated when the DTPM rules are checked is a single grammar line. Thus, all of the objects to be weighted with respect to each other by DTPM rules must have been brought into scope at the same time.]

Although you can have one action decide to invoke another, this is not strictly necessary. The same action can execute different logic based on the nature of the noun and/or second noun. All you need to do is structure the rule preambles appropriately for check, carry out and other rules.

The following reworks things a bit in light of the above. Note that I reinserted some DTPM rules that depend on the state of the discouraged_from_compass_navigating property for the player. The conditional logic can be modified as you like to make use of scenes or whatever. The test me sequence shows how the command >GO TO TREE is interpreted based on the current situation.

Lost in the Woods

"Lost in the Woods"

Part - Room_Navigating

A person can be discouraged_from_compass_navigating or not discouraged_from_compass_navigating.

Navigating is an action applying to one object.

Definition: an object is navigable if (it is a room and it is not the location) or (it is an elusive_landmark and it is not in the location).

Understand
	"go back/- to/around/near/by/-- [any navigable object]",
	"go to/near/by/-- [any navigable object]",
	"return to [any navigable object]",
	"walk to/near/by/-- [any navigable object]",
	"walk to/-- [any navigable object]",
	"run to/near/by/-- [any navigable object]",
	"run to/-- [any navigable object]",
	"follow [any navigable object]"
	as navigating.

Does the player mean navigating a room when the player is discouraged_from_compass_navigating:
	it is unlikely.

Does the player mean navigating a distant elusive_landmark when the player is discouraged_from_compass_navigating:
	it is likely.


After waving hands:
	if the player is discouraged_from_compass_navigating:
		now the player is not discouraged_from_compass_navigating;
	otherwise:
		now the player is discouraged_from_compass_navigating;
	showme whether or not the player is discouraged_from_compass_navigating.

Check navigating a room:
	if the noun is the location, say "Well, happily you're already here." instead;

Carry out navigating a room:
	let initial location be the location;
	let the destination be the noun;
	if the initial location is the destination,
		say "." instead;
	let heading be the best route from the initial location to the destination;
	say "(DEBUG room_navigating: heading toward [noun] is [heading])[line break]";
	if heading is nothing:
		say cant_find_that instead;
	else:
		now player is not discouraged_from_compass_navigating;
		try going heading.

Part - Elusive_Landmarks and Landmark_navigating

An elusive_landmark is a kind of thing.

The_distance is a container.
The_distance is in Limbo.
Definition: an elusive_landmark is distant if it is in the_distance.

Check navigating an elusive_landmark:
	if the noun is touchable:
		say "Well, that's right here." instead;
	if the noun is not in the_distance:
		say cant_find_that instead;

To say cant_find_that:
	say "You're no longer sure how to get there.";

Carry out navigating an elusive_landmark:
	say "You head toward the [noun].";
	move_within_dark_woods;
	try looking.

To move_within_dark_woods:
	let distant_thing be a random elusive_landmark in the_distance;
	let next_thing be a random elusive_landmark in Limbo;
	let past_thing be a random elusive_landmark in location;
	now distant_thing is in location;
	now next_thing is in the_distance;
	now past_thing is in Limbo;

The can't reach inside rooms rule does nothing when navigating.

The can't reach inside rooms rule response (A) is "You can't get there from here."

Part - Rooms & Stuff

Dark Woods is a room.
"[dark_woods_desc].".

To say dark_woods_desc:
	let distant_thing be a random elusive_landmark in the_distance;
	say "It's dark and woody. You see [the distant_thing] in the distance";

The white tree is an elusive_landmark in The_distance.
Understand "tree" as white tree.

The madrone tree is an elusive_landmark in Dark Woods.
The tree stump is an elusive_landmark in Limbo.

Top of the Tree is a room [west of Dark Woods].
Understand "tree" as Top of the Tree.

Test me with "go to tree / wave / go to tree / g".

[drpeterbatesuk (Dr Peter Bates)]

Room_or_landmark_navigating is an action applying to one thing.
Understand
	"go back/-- to/near/by/-- [any room],
	"go back/-- to/near/by/-- [any elusive_landmark],
	etc.
	etc.
	as room_or_landmark_navigating.

You could have all of these go through the Going action without having a new Room_or_landmark_navigating action and then just start processing at the Before stage (as in the example I gave)

[drpeterbatesuk (Dr Peter Bates)]

@otistdog

No matter how you arrange things, the grammar line for one of the actions will come before that of the other.

True, but you can make grammar lines conditional so that they swap in and out of parser consideration, e.g. ‘Understand “blow up [something]” as detonating when the player is in the mine. Understand “blow up [something]” as inflating when the player is in the balloon factory.’

Although as already stated, I think the whole approach of manipulating grammar line precedence/consideration like this is probably flawed and best avoided.