I don't want verbs like Insert to grab random nouns

I’ve been mucking around with actions that take two nouns, like inserting it into and giving it to, and I can never get the desired behaviour when the player just types GIVE or INSERT with no noun.

What I’d like is, if the player types either, the game asks that question ‘What do you want to (blah)?’… and will accept the player’s answer on the next line.

The reason I can’t guarantee that happens is because the outcome seems dependant on what’s in scope at the time. ‘Does the player mean’ rules favouring any object will cause INSERT to grab those as the first noun, no matter how nonsensical, beating any ‘rule for supplying a missing noun’ rules. GIVE seems less grabby – I assume this is because of its different grammar lines? – but it’s not NON-grabby.

I could make my own fob-off one word action, but the I don’t think I can get the helpful behaviour? As in, if I print my own ‘What do you want to give?’ message in response to GIVE, it’s just cosmetic. The player can’t really type the noun on the next line.

-Wade

PS - Obviously, I mean ‘random’ in an extremely prejudicial sense. I don’t mean literally, because the game is following a Does The Player Mean Rule that I wrote.

2 Likes

This is a terrible answer, but I’ve found the best way to do this without catastrophic parser intervention is to have a couple of objects in the player’s inventory at the start of play. Then the parser can’t select a single one to auto-grab.

4 Likes

Hm, well what’s going on in my situation is it’s grabbing the sky, a backdrop. And this is when the player has several things in their inventory.

If you wonder why my DTPM rule favours the sky in that room, it’s because there are a bunch of ‘white’ things, and if the player types ‘white’ at that moment, I actually want the sky to win. But not to be the first choice of thing to insert when the player has supplied nothing at all.

Why is it picking a backdrop anyway when I do have inventory items? Does the specificity of the DTPM rule used affect it? This one is very specific:

Does the player mean doing anything to reusable-sky when (player is in (REGION) and the location is not (ROOM IN THAT REGION)

-Wade

How hacky with I6/custom parsing do you want to get?

The problem you have is that when the parser is trying to match a grammar line that requires one or more nouns but they have been omitted from the typed command, it REALLY REALLY wants to infer a noun (or second noun) itself, and will only ask the player to supply one when it is unable to find a single best guess.

The first thing it tries to do is identify (if it can) just one thing that makes sense in context. For example, if you type ‘give’, for the first noun it will automatically choose the thing carried by the player if the player only carries one thing.

If more than one thing makes sense in context, the parser will then instead go on to calculate a compound score for all things in scope, giving a bonus to any that made sense in context.

However, if what the player typed corresponds to any ‘Does the player mean’ rule, the score it gets from that will override all other considerations when the parser tries to choose a ‘best guess’ (because the scores from DTPM rules are so large), so if only one thing in scope fits a ‘Does the player mean’ rule with outcome ‘it is likely’ or ‘it is very likely’, that thing will automatically be chosen.

All this means that to get what you want you will either need to

(i) intervene before the parser gets going (by putting code to get input and manipulate the player’s command in an ‘After reading a command’ rule)
(ii) rejig the parser itself to behave differently
(iii) have simpler grammar lines that match what the player typed (e.g. understand "insert" as inserting it into, `understand “insert [things preferably held]” as inserting it into) which will then fire the ‘supplying a missing noun’ or ‘supplying a missing second noun’ rules to get input to complete the command- these will fire before any DTPM rules.

EDIT

(iv) as Zarf suggests, manipulate the scenario so there is NEVER one best guess (can get tricky- Zarf’s trick will ensure that there’s always more than one thing that makes sense in context for giving, dropping or inserting, but when the parser then moves on to scoring you can only manipulate that through DTPM rules and if you’ve got broadly-stated DTPM rules like ‘doing something with the reusable-sky’, one thing is still quite likely to come out as the single highest-scoring winner)

(v) Alternatively, ensure that your DTPM rules always pick the winner you want, or exclude the ones you don’t want, or include/exclude the actions or group of actions you do/don’t want to interfere with. For example, if you want to specifically exclude inserting or giving the sky, you can do that in your DTPM rule:

Does the player mean doing anything to reusable-sky when ((not giving) and (not inserting)) and (player is in (REGION) and the location is not (ROOM IN THAT REGION):

1 Like

(I was typing this up before the responses above appeared. Have to try if it helps in that situation.)

One way could be to modify the DTPM rules (favouring the objects) so that they don’t apply to giving and inserting.

Scenario:

The Lab is a room.

The box is a container in the Lab.

The nice widget is in the Lab.
The scary widget is in the Lab.

Alice is a woman in the Lab.
Bob is a man in the Lab.

The block giving rule is not listed in any rulebook.

Does the player mean doing something except giving or inserting with the nice widget: it is very likely.

Output for EAT (to show that that still favours the nice widget) and GIVE:

Lab
You can see a box (empty), a nice widget, a scary widget, Alice and Bob here.

>eat
(the nice widget)
That’s plainly inedible.

>give
Whom do you want to give?

>alice
What do you want to give Alice?

>widget
Which do you mean, the nice widget or the scary widget?

>nice
(first taking the nice widget)
You give the nice widget to Alice.

For INSERT:

Lab
You can see a box (empty), a nice widget, a scary widget, Alice and Bob here.

>insert
What do you want to insert?

>widget
Which do you mean, the nice widget or the scary widget?

>scary
What do you want to insert the scary widget in?

>box
(first taking the scary widget)
You put the scary widget into the box.

1 Like

You can also write a more specific DTPM rule that says it’s very unlikely they want to give or insert the sky. (Or a backdrop more generally, or scenery even more generally.)

1 Like

A take matters into your own hands approach works, but is very tedious:

Understand "give [thing]" as giving it to.

To decide what action name is the prospective-action: (- action_to_be -)

For issuing the response text of the action processing internal rule response (H) when the prospective-action is giving it to action:
  say "[There]'s no one here to give anything to.[no line break]";

Definition: a person is handy if it is not the person asked and the person asked can touch it.

for supplying a missing second noun when an actor giving something to:
    if there is a handy person (called the recipient) begin;
      now the second noun is the recipient;
      say "(to [the recipient])";
    end if;

(Example shows the missing second noun case, but the same technique could be extended to the noun.)

I related an interesting approach by @OtisTDog here: Unlocking while empty-handed always disambiguates to something worn - #5 by Zed

Thank you all for the breakdown and ideas.

I had thought of adding conditions to the DTPM rules, but it seemed pretty tedious. I’ve always been glad that (I thought I) could write these in a kind of isolation. Weird rules like ‘Does someone mean doing something to the sky: yeah!’ were only about grammar clashes in context, not the general likelihood of wanting to attend to the sky. It’s like auto-putting your finger on the scale at the right moment. Now I realise the game treats every moment as the right moment for certain verbs.

I could revise the 150ish DTPM rules so far and add clauses to future ones, but yeah, that strikes me as the path of great annoyance and future annoyance.

Btw, I probably forgot to say (or remember) why the sky even gets a look-in for GIVE. It’s because I rewrote GIVE to allow attempts on inanimate objects. These include backdrops called crowd-classes, AI and other things.

I think I might try Dr Peter Bates suggestion number iii: Rewrite INSERT using ‘preferably held’ grammar, and try to intercept stupidity with rules for supplying nouns.

-Wade

1 Like

If you want to print a response such as ‘What do you want to insert?’ or ‘What do you want to insert that into?’ in a ‘rule for supplying a missing [second] noun’ asking the player to supply said missing noun, you’ll probably most easily do that by lifting the relevant section of I6 code from the parser and tweaking it slightly.

That said, if we’re getting into I6 hacking it would probably be simpler to block the parser from trying to infer nouns at all for particular actions such as ##Insert & ##Give or whatever…

I rewrote inserting it into like this:

Understand the command "insert" as something new.

Understand "insert [something preferably held] into [something]" as inserting it into.

Understand "insert [something preferably held]" as inserting it into.

This has in practice fixed my problems.

Preferring held stuff gets nonsense like the sky out of contention. Anything held is going to be at least semi-sensical. I can also keep writing weird rules about the sky, and indeed, I want to keep writing DTPM rules the way I am doing so, and not change the ones I’ve already written, either.

Any PC of mine will always have stuff in their inventory, except in chapters where some actions are totally blocked. So now if I type INSERT, I get ‘What do you want to insert?’. I’m living the dream *TO THE EXTENT THAT I’VE TESTED THESE CHANGES

-Wade

1 Like

It wouldn’t help in this situation, but if we removed noun inference entirely apart from DTPM rules, I’m not sure it would be missed. It seems to go wrong more often than it goes right.

1 Like

Possibly unfair- its rules re pretty sensible and work well for most reasonable commands in common situations. I suspect you just don’t notice it so much when it goes right. A player who types ‘Insert’ when they are holding nothing and the only object in scope is Alice probably deserves everything they get (although Alice probably doesn’t)!

And in the case of the DTPM rule that kicked this thread off, the parser is simply doing what It’s been asked to do…

I think current behaviour reflects the parser’s general philosophy of erring in the direction of accepting all reasonable inputs at the expense of also accepting some unreasonable ones.