Jake the Frustrated Noob Programmer

EmacsUser – is this a bug? It seems to me that 3.26 does suggest that you have to explicitly declare both left and right as directions.

Perfect! Thank you.

Lightning round! New problem, and possibly the last for this project:
I have rooms for buildings, like ‘Location’ and rooms outside of them, named ‘Just Outside Location’.
The problem is that “Just Outside x” is understood as “x” because the word “x” is in it. Likewise, House Entrance and House are mistaken as the same room, which leads to two-locations-for-one-room errors.

Oops—you’re right. Good catch, matt w.

The usual solution is to declare the one with the shorter name first, as inHouse is a room. Just Outside House is a room.
That way, Inform knows that something with a shorter name exists when it sets up synonyms for the room with the longer name.

IMHO, it should still be filed as a deficiency (or whatever Inform7’s equivalent of “deficiency” is). The same section explicitly states,

This strongly implies that it is an error to create a direction without an opposite, or a direction whose opposite is a thing/person/etc. This in turn strongly implies that Inform 7 should do the right thing when presented with the completely unambiguous code snippet Foo is a direction. The opposite of foo is bar. If Inform 7 in fact crashes when presented with this snippet, that’s at least a deficiency, IMHO. :confused:

Okay, first project’s finished. It’s nothing big, just a proof of concept, but there’s a new problem in town.

To paraphrase the issue, here’s a minute of play:

My guess is that you’ve got a rule firing (probably an Instead) for going north someplace, but it doesn’t report doing so when you’re in the starting location. So something like:

Instead of going north: if the toaster is held by the player and the dog is sad and the location of the player is the Piccolo Factory, say "You can't just walk out of the factory with a toaster: Poochy needs that to cuddle."
If you have a rule like that, it’ll stop all attempts to go north in other locations and not give a message why. But uh, there are other possible explanations.

Yes; and if that is the case, try putting some or all of the conditions in the rule ‘preamble’:

Instead of going north while eating a chicken sandwich: say "Birdie nam nam." only applies if the player is both trying to go north and currently eating a chicken sandwich, and it will be ignored by the game otherwise; whereas

Instead of going north: if the player is eating a chicken sandwich, say "Birdie nam nam." always applies as soon as the player tries going north, but it will only ever say anything, if the player is eating a chicken sandwich.

Ttry this:

and see what happens.
The standard output would be:

Any deviances from this might help you to spot the bug.

Yes. Bug 935 has been added.

Also true; that would be 794, which has been fixed.

Aha! Here’s the culprit.

Instead of going somewhere: If the player has this object, say “You wouldn’t want to steal this object, now, would you?”

Fixed, and now I can move. Huzzah!

Awesome. :slight_smile:

I also wonder whether it would be possible for Inform to actually detect and diagnose bad rules such as Jake’sInstead of going somewhere: If the player has the crown, say "You wouldn’t want to steal the crown, now, would you?"Inform could definitely detect this as a potential problem: There is a path through this "instead" rule that does not necessarily execute any actions. If this rule is the only rule triggered on a given turn, no response will be given to the player.

In fact Inform has enough information to provide a hint like “An example of such a command is GO NORTH when the player is in the House and does not have the crown.”, although actually producing that hint would be extremely non-trivial. Basically, Inform would have to work backwards through the map (to find a room from which it’s possible to “go somewhere”), the list of understood verbs (to find a player input that triggers an appropriate “go” action), and the instead rule itself, then reassemble all of those pieces into a coherent sentence. This seems pretty close to Inform’s core competence, but I know it’s different in several non-trivial ways.

I almost filed this on the bug tracker, but I wanted to search for duplicates first, and realized that the only keyword I could think of to search for was “instead”. So I didn’t.

I wouldn’t be surprised if the Inform people weren’t terribly interested in implementing static analysis any time soon…

Inform already does a form of static analysis on rulebook conditions – it helps get rulebooks sorted correctly. Checking for “bad rules” isn’t that far-fetched.

However, hunting for dead code is always trickier than it looks. The canonical case is a line that looks like “if SPECIAL_DEBUGGING: do …” When you turn off special debugging, that line can never be executed, but you don’t want the compiler to throw an error or even a warning about it.

That case isn’t exactly applicable to I7, because there’s no such thing as compile-time constants per se. But you can imagine similar situations. Extensions are particularly prone to this sort of thing – maybe an extension defines a rule to cover a possible situation, but your game is built so that that situation is impossible. There shouldn’t be a warning about that.

(Not to mention the fact that I7 doesn’t have warnings, only errors and run-time errors…)