Hello, and "when multiple adj work as a noun" question

Authoring Inform 7
1

Hi there, I’m a forever long IF player and (I think) an excellent programmer. Over the years I’ve tried to create IF in Inform 6, now 7 and although I can whip up very clever stuff in perl, delphi, powershell, etc… and was well on my way learning Inform 6, Inform 7 (which I think is an awesome work of incredible genius) gives me F I T S !!! Mostly that’s because of the extremely particular syntax with all of those subtly seductive mistakes - and while the documentation is excellent, I frequently come up with things I wish to do that I can’t find documented in any clear way.

Here’s my first question. One of my worst peeves with IF is when this happens:

“Here is a dark, long, polished, wooden table”

x dark long
“You see nothing special about the table.”

Argh that’s annoying. There is no true noun there, only exclusively identifying adjectives.

You might think it’s pretty insignificant and that most players will not do that and if they did who cares anyway, but I’m an OCD perfectionist and to me that is glaring. And I want my code to do EXACTLY and precisely what I want it to do and I don’t want it do do that.

I couldn’t think of a way to make Inform respond “Do you mean the dark, long table?” So instead here’s what could figure out.

BTW. If anyone would care to show me better, more efficient or “correct” ways to write or format any part of what I have here, I’d really appreciate that as I’m really a total n00b and don’t want to develop bad habits.

Ok now for my question:

Specifically, with my fix, before the first > of player input, there is an extra line break. I am using a ‘fake’ object (able to configure an object as a concept, I love that!) to force disambiguation as a way of handling this situation more gracefully. I cannot figure out how to suppress the initial appearance of that fake object so the best I can do is set it to " " which causes the extra line break.

Is there a way to block the initial appearance completely? Remove the line break before the > only the first time it is displayed? Other ideas? I wish I could make use of the ‘bug’ I reference but then my fake object would still be mentioned, as being on top of something else.

"Trial and Error"

The Trial Room is a room
	having description "In this self-contained space, trials and errors take place."

The table is a fixed in place supporter in the Trial Room
	having description "A long narrow table made of a dark polished wood.  To it's front edge is a bright brass plate upon which is etched 'Judgement Table'."
	and initial appearance "A long, narrow table made of a dark polished wood stands prominently in this space."
	Understand "long", "narrow ", "dark", "polished", "wood", "wooden", "judgement", "judgement table" as table.
	
	Before examining the table:  change the printed name to "Judgement Table".
	Before taking the table: say "You breathe in, flex your knees, grab hold and..."
	Instead of taking the table, say "It's far too heavy to lift or move." 

A gavel
	having description "a small, ornate, wooden mallet."
	and initial appearance "A small, ornate, wooden mallet lies on the Judgement Table."[due to a bug when an object is initially upon another object the initial appearance is ignored]
	 is on the table.
	Understand "small", "ornate", "wood", "wooden", "mallet" as gavel.

something else is fixed in place in the Trial Room
	having description "There is nothing else."
	and initial appearance " ".
	Understand "long", "narrow ", "dark", "polished", "wood", "wooden", "judgement" as something else.

	Before doing something to the something else: say "There is nothing else."; stop the action.


Test me with "take long narrow / something else / take long narrow table / take dark polished / table"
2

It is startling, but it is also the way Inform has behaved since the early 90s. So it is not entirely unlikely that a player will do it just out of (bad) habit, and if so, how much effort do you want to put in to not understand the player’s command?

To answer the question: this is fairly difficult to do with I7. (It was quite easy with I6, but I7 has a more structured noun-parsing model – it makes some cases much easier, but not this case.)

The following code is very awkward, and relies on a special behavior of property-parsing, but it does reject adjective-only commands:

Table-adj-type is a kind of value. Table-adj is a table-adj-type.
Understand "long", "dark", "wood", "wooden" as table-adj.

The table is in the Kitchen.
The table has a table-adj-type. The table is table-adj.

Understand the table-adj-type property as referring to the table.

Getting the parser to respond with a secondary question (“Do you mean the long dark table?”) is much more involved; you’d have to dig down into the parser and build a new mechanism parallel to (but distinct from) the disambiguation-question mechanism.

Sorry; I don’t have a better answer for you.

3

Give it the scenery property.

4

Yep, and it’s annoyed me all that time :slight_smile: I’m the kind of player who spends as much time trying to find the limits, bugs and unintentional behavior of the parser and code as actually playing the game. As I get serious about my own games I will obsess over ‘fixing’ those kind of things.

If my fake object ‘something else’ is scenery then the disambiguation effect no longer works. The parser selects the more tangible table object and doesn’t ask “… or something else?” which I quite like as a workaround.

I am very intrigued by your custom property suggestion, I’ll try that.

Thank you!

As for my structure and “coding” style?

5

Oh and just to be clear, my fix does seem to work other than the one little extra line break (technically the single space initial appearance of ‘everything else’) on initial room description. Maybe I can ignore that.

6

HA! Figured it out.

Put this after the Trial Room description

Before printing the locale description: set the locale priority of something else to 0;

7

How well would this work?

[code]A long dark wooden table is in the Kitchen.

Instead of doing something when the current action involves the table and the player’s command does not include “table”:
say “Do you mean the long, dark, wooden table?”;
if the player consents, continue the action.
[/code](It will be intercepted by some parser errors, like “You can only do that to something animate” etc., but so would the original “something else” fix …)

8

Please do not do this! No one will ever think badly of your game because it understood them. They will if it unnecessarily asks for disambiguation! ALSO: what kind of weird players are going to type “x long dark” rather than “x table”??

In general I don’t think there is a good systematic way to do this, because Inform 7 doesn’t understand the difference between nouns and adjectives.

9

Not for tables, but for a noun that’s long or awkward to type, I frequently use an adjective instead. (And I’d certainly find it super-irritating if someone hacked the parser to be more pedantic about it.)

10

Agreed. My usual use for this, as a player, is something like:

I don’t think understanding “x red” here is any more artificial than understanding “x red dromiceiomimus” rather than “look at the red dromiceiomimus.” (If we were really using natural language we’d say “look at the red one.”)

11

It wouldn’t be hard to get the parser to ignore “one”, in which case “look at the red one” would be understood perfectly.

12

That might even be worth doing.

13

Something like this, maybe?

"The thing"

The Testing Chamber is a room.

A flower is a kind of thing. Understand "flower" as a flower.

A table is scenery in the testing chamber. A vase is on the table. A red chrysanthemum, a yellow chrysanthemum, a purple chrysanthemum and a white chrysanthemum are flowers in the vase.

Understand "one", "thing" and "object" as a thing.

Test me with "get red flower / get the white one / get one / get one thing / i".

(As the third and fourth commands in the test show, understanding “one” as a thing interacts in somewhat curious ways with the parser, since it can parse it either as a noun or as a numeral. It’s not really broken, though, just a bit odd.)

14

Giving a common word for everything can be a bit dangerous in practice, though. The player can then type X THING and get a list of every object in the location.

15

Points taken… 1/2 my motivation is working toward mastery over Inform - so just practice aka ‘trial and error’. To that extent, it’s not a goal for a final game, just ‘testing’.

The other 1/2 is that I want my game to communicate in a more polished way than typical and I’d like the player to do so as well. I would not like to have a troublesome noun that didn’t have one more more shorter sensible aliases.

But again, points taken.

16

Part of this is actually a pet peeve of mine. I don’t object to understanding something by adjectives when there are no alternatives, but I had a hell of a time making things clear in A Killer Headache because some adjectives apply to a lot of different things, and are sometimes used as nouns. I went to a lot of trouble to make sure that

and

were clearly understood as different things. I can’t remember if I succeeded. But this is the sort of situation where I wish Inform had expanded the “referring to” syntax to include arbitrary text tokens. How hard would that be?

17

I don’t know how hard it would be. It’s an open feature request.