Problem with topics in a book

I have a book. You can read about topics in the book. One of the topics is ‘ball’. When you READ ABOUT BALL, it tells you the materials you need to make a rubber ball.

Elsewhere in the game, I have a ball of twine. This can be referred to as ‘ball of twine’, ‘ball’ or ‘twine’. The mere existence of this object causes READ ABOUT BALL to fail. Rather than noun1 returning ‘ball’, as it should, it gets coerced into ‘twine’. I did not type ‘twine’, the ball of twine is not in scope, I am not carrying it, it is not in the room, it hasn’t even been created, so why does Adventuron change my input from ‘ball’ to ‘twine’ and how do I stop it from doing this?

The following minimal code demonstrates the problem. When you enter READ ABOUT BALL, the expected response is “It says you only need rubber to make a ball.” The actual response is “There’s no topic on that.” In the match statement, I’ve added an alternative noun. If you type READ ABOUT BALLS, you get the correct response. In this case, Adventuron is not doing the automatic conversion between singular and plural, as it normally does. Debugging code is included so that you can see where Adventuron is returning the wrong thing for noun1.

start_at = room

game_settings {
   experimental_new_parser = true
}

locations {
   room : location "You're in a room.";
}

objects {
   twine : object "a ball of twine" {experimental_matching_text_sequences = ["ball of twine", "ball", "twine"]}
   book : object "a book" at = "room";
}

on_command {
   : match "_ _" {
      : mask {
         : print {("^n^verb = " + original "verb")}
         : print {("^n^preposition1 = " + original "preposition1")}
         : print {("^n^noun1 = " + original "noun1")}
         : print {("^n^preposition2 = " + original "preposition2")}
         : print {("^n^noun2 = " + original "noun2" + "^m^")}
      }
   }
   : if (is_present "book") {
      : match "examine book;read book" {
         : print "It's a book about making a rubber ball. I guess you could READ ABOUT BALL.";
         : done;
      }
      : match "read _" {
         : if (preposition1_is "about") {
            : if (noun1_is "ball" || noun1_is "balls") {
               : print "It says you only need rubber to make a ball.";
               : done;
            }
            : print "There's no topic on that.";
            : done;
         }
      }
   }
}

Is the experimental_matching_text_sequence reading ‘ball’ as ‘twine’ not how that function is supposed to work? I’ve never used it myself.

The experimental_matching_text_sequence works great, but it is full of traps and pitfalls.

Trap #1: It stops pattern matching at the first match, so if I had defined ‘ball’ before ‘ball of twine’ and entered the latter in a game, it would stop searching as soon as it recognised ‘ball’ and spit the dummy from that point onwards.

Trap #2: If you have any other objects with the same noun as one of the nouns in the array, it does a wrong match. That’s the problem here. This does not happen for objects defined in the normal way.

Trap #3: It appears that the ‘primary’ noun may sometimes be incorrect. That is not the case here, but for some reason, it associates the primary noun for the ball with a completely different object that has a different primary noun (twine).

Trap #4: When you use a test like : if (noun1_is "blah"), you are supposed to be able to use any of the nouns defined as synonyms in the vocabulary table for ‘blah’. As these patterns are not in the vocabulary table, this doesn’t seem to work. In my experience, you have to use the noun in the object ID for ‘blah’.

Trap #5: The order in which you define your objects seems to have an impact. If you have two objects with a common noun, it seems to stop at the first one that it finds, as is the case here. I haven’t tested this, but I think that if I had defined the ‘ball’ topic as an object (even though there is no such object) before the ‘ball of twine’ object, then the ball topic would be found first and this would be used for noun1.

Trap #6: You must have at least one single-word noun, otherwise you can’t enter it in match statements. You need a single-word noun for the object ID anyway, but it’s not always easy to find a single-word noun. For example, I have a jack-in-the-box that can be defined using experimental_matching_text_sequence, but what do I use as a single-word noun? I couldn’t use ‘box’, as I had another box, so I used ‘jack_box’, even though that is not the right adjective.

There may be other traps and some of these traps may just be coincidental or ignorance on my part. It’s hard to know exactly what’s going on internally, as none of this is documented. There are at least 5 different ways of defining the nouns and adjectives for an object and it is hard to know which one to use in which circumstances, which one takes priority and what happens when there’s a clash.

Chris will say that this will all change in future when he has object-based object definition and a better way of defining the grammar, but that doesn’t help us now.

Adventuron is a great engine, but for those of us on the bleeding edge, it’s a continually moving target. It’s not unusual to find that something has changed or stops working after doing an upgrade.

1 Like

Right…I’ll definitely avoid using that experimental function then! I have enough difficulties already. I often find it easier to simply write around the problems rather that try to unpick them (eg rename an object altogether to avoid disambiguation issues - a green bottle and a brown bottle was troublesome for me; not I have a bottle and flask instead). That’s not helping to solve the problem, but I don’t have the technical skills to do that or, often, even to define the problem.

It occurs to me occasionally that I could just use Inform(6/7), or Dialog, or TADS and this stuff would just, well: work. Without all this messing around. And yet Adventuron appeals more for some mysterious reason - probably because I’m British, so giving myself an unnecessarily difficult and complicated time of it is part of my cultural makeup. Others must invent their own excuses.

I’m not suggesting that you abandon experimental_matching_text_sequence. It’s actually very handy and I’ve been using it a lot. It’s the only way to allow punctuation to be included in the input for an object. For example, ‘nurse’s uniform’ or ‘coat-of-arms’ or ‘button no. 1’ or ‘apartment #2’. Just beware of some of the issues that I’ve discovered. There are workarounds for all of them, but I’m sure any issues will be fixed in due course.

 And yet Adventuron appeals more for some mysterious reason

Same for me!
One of the main reasons is the ease of use for my players while still retaining a parser-based game. (My players tend to not be familiar with text games, and yet I still make them use it…)

That is a much more excellent and considered reason than simple masochism.

1 Like

I hate Adventuron, but I still use it. There’s something appealing about it that I can’t put my finger on. Maybe I’m just a masochist…or I like a challenge.

All this banter is not solving my scoping problem with topics in a book.

It’s not not certain that using the softwares you mention won’t give you some well-deserved headaches. There is nothing easy about them.

I add a bit of banter, but I think you’re being unfair and too demanding with Adventuron. It’s newer software, and you’re asking it to do what much older software does and not always very well.
It seems to me that the internal logic of Adventuron is closer to The Quill, PAWs, DAAD than to Inform 6, for example. Wanting to do with Adventuron what you do with Inform 6 doesn’t seem to me to be masochism, but nonsense.

1 Like

Of course, but when were users ever not that? I like to comfort myself (probably delude myself) that we’re helping along development by kicking the system like this.

Actually, I don’t want it to do anything really complicated. Just handle containers and not return unexpected responses. I bandy about the names of Inform etc but I’ve never actually wanted to use them: I need Adventuron’s colourful, web-based PAW thing, but with just slightly more depth.

(Sorry Garry - you can get back to your scoping nightmare now.)

1 Like

Thoroughly testing the system is good. Reporting bugs and suggestions is good. Saying you hate the engine and that you feel like a masochist for using it in a thread that you know the author will read is not constructive in the least and is incredibly rude. It only takes a few seconds of browsing the category to see how hard he’s been trying to respond to the bug reports thrown at him left and right. I think you’re all being pretty unfair.

Not at all: I think Chris knows me well enough by now to know how much I love the engine and appreciate his continuing, Herculean efforts to sort out the bugs.

My tongue is in my cheek; Garry can account for himself.

My tongue is in my cheek too. This is a very small community and most of us know one another quite well. Chris does a great job (as you rightly pointed out) and none of us would ever do anything to harm the friendship or the terrific effort that Chris puts in.

Despite its maturity, Chris has big plans for making Adventuron even better than it already is. Some of us are on the bleeding edge, and that can be frustrating, but it’s part of the fun and the challenge.

2 Likes

“Never explain — your friends do not need it, and your enemies will not believe you anyway.” –Elbert Hubbard

I hope many of us have our tongues in our cheeks.

3 Likes