Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000292Core InformUnderstandingpublic2010-09-16 08:512010-10-28 00:31
Reporterleandro ribeiro 
Assigned Tograham 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSLinuxOS VersionAny
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000292: "[something visible]" doesn't match on the turn after entering a room
DescriptionI've come up with a way to make it possible to examine objects just by typing their names.

I've recently noticed that it fails immediately after entering a room, although 
it works in the next turn. It goes something like this:

-----------------
        A Nice Room
        This nice room is very nice. It has a nice book in it.

        >book
        I didn't understand that sentence.

        >book
        It is the nicest book in the Universe.
------------------

I now know there are other, simpler ways, to achieve this, but I've wrote it before I knew them and I got curious as to why it isn't working.

Thanks.

Ps.: I was unsure as to which category should I post this. Sorry about any trouble.
Minimal Source Text To Reproduce
Keyword is indexed text that varies.

After reading a command:
    if the player's command matches "[something visible]":
        now keyword is the player's command;
        replace the player's command with "x [keyword]".
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships

-  Notes
(0000554)
Victor Gijsbers (reporter)
2010-09-16 09:56

I have tried to find out what is going on, but it seems the decisions here are made by parts of Inform 6 that are to me utterly obscure. The weird thing is that if you print out a list of visible things before the "after reading a command" rule runs, that list is already correct. So apparently, the parser has some other way to access a list of visible things; and this isn't working.

It looks like a bug to me, but perhaps there are deep Inform things involved that make matching commands to things rather than topics unreliable? If so, I think it should not compile.

Here is a somewhat more complete source text, including a testing command:


Keyword is indexed text that varies.

After reading a command:
if the player's command matches "[something visible]":
now keyword is the player's command;
say "Replacing [keyword]!";
replace the player's command with "x [keyword]".]

Church is a room. The player is in church.

Palace is north of Church.

An apple is in Church. A peach is in Palace.

Test me with "n / peach / peach".
(0000557)
EmacsUser (manager)
2010-09-17 11:29

Yes, the book is visible both times, but it doesn't seem to be in scope until the second try. It looks to me like actors_location isn't being set until after Inform has gone through the reading-a-command activity, so on the first try SearchScope is choosing objects from the wrong location.
(0000670)
graham (administrator)
2010-10-03 17:04

I have fixed this, but I tend to think that the "reading a command" activity runs at a time when actor-dependent parsing shouldn't be expected to work - since we don't yet know who the actor will be; it depends on the command, which hasn't yet been parsed.

- Issue History
Date Modified Username Field Change
2010-09-16 08:51 leandro ribeiro New Issue
2010-09-16 09:56 Victor Gijsbers Note Added: 0000554
2010-09-16 17:09 jmcgrew Status new => acknowledged
2010-09-16 17:09 jmcgrew Category Testing commands => Understanding
2010-09-16 17:09 jmcgrew Summary Entering a room "kills" some code => "[something visible]" doesn't match on the turn after entering a room
2010-09-17 11:29 EmacsUser Note Added: 0000557
2010-09-17 11:29 EmacsUser Status acknowledged => confirmed
2010-10-03 17:04 graham Note Added: 0000670
2010-10-03 17:04 graham Status confirmed => resolved
2010-10-03 17:04 graham Resolution open => fixed
2010-10-03 17:04 graham Assigned To => graham
2010-10-25 21:14 jmcgrew Fixed in Version => 6F95
2010-10-28 00:31 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker