Inform is driving me insane: why does declaring a room work in one place, but not another?

Authoring Inform 7
1

Basically, I have code that goes like this:

InteleTek Storefront is west of Megablock Sidewalk. The description is "..."

A display window is scenery in the InteleTek Storefront. "..."

The InteleTek Store Interior is inside from the InteleTek Storefront. The InteleTek
 Store Interior is west from the InteleTek Storefront. The description is "..."

Gibson Storefront is north of InteleTek Storefront. The description is "..."

The Gibson Store Interior is inside from the Gibson Storefront. The Gibson
 Store Interior is west from the Gibson Storefront. The description is "..."

Simple enough, right? Well, not so fast. See, everything works except the InteleTek Store Interior. That line, for whatever reason, doesn’t compile. If I remove it, everything compiles and runs just fine. If I leave it in, I get a compile “problem.”

It’s so fucking frustrating because I literally am using the exact same format as the Gibson store interior, I literally copied and pasted the line and changed the names, and that line does work. I’m at a complete loss. I have no fucking clue what’s going on here.

What’s worse, if I take the InteleTek store interior line and put it at the bottom of my file, below all the stuff for the Gibson store interior, guess what? It works just fine. What the hell am I missing here?

Honestly I kind of hate Inform so far. I’m an experienced programmer, but I feel like doing even basic things in this language is a nightmare due to the lack of actual syntax and proper programming constructs.

3 Likes
2

Weird, I copied your code exactly into a blank project and it compiled perfectly.

Do you have other code earlier in the project? And what error message did you receive?

5 Likes
3

Just confirming it’s working for me too. I wonder whether you have some other object with a name similar to “InteleTek Store Interior” that’s making your declaration ambiguous? As Brian says, it’d be helpful to see the actual compiler error you’re getting.

As for your gripes about Inform 10, there are definitely lots of experienced programmers who find it frustrating (and others who really like it, of course) – there is a small but very active TADS community, and that’s a language many folks with more traditional programming backgrounds like. There are also ways to make the Inform coding experience more controlled and structured, too – for example, if there is an issue with ambiguity in the room name, you can often get around that by just giving your rooms more precise names like gibson-interior and then using the printed name property for the more player-friendly version with spaces and such.

4 Likes
4

It seems ok in both 7 10.1.2 and 7 6M62.

I do a lot of the readability/structure stuff Mike’s talking about for reading and troubleshooting purposes, but I’m not sure what’s going on with your compile there.

3 Likes
5

Given that what you posted is an excerpt and people are pointing out that this excerpt compiles, the issue may owe to name ambiguity between the objects in this excerpt and other objects elsewhere (maybe involving “Gibson” or “InteleTek”).

While it’s a pain, you could guarantee (well, as much as one can even say “guarantee” where software is concerned) avoiding such issues with:

A room is usually privately-named. 
Inteletek-storefront is a room. Printed name is "InteleTek Storefront".
Understand "InteleTek", "Storefront" as Inteletek-storefront.

The privately-named bit is optional, but means that inteletek-storefront won’t be added to the dictionary as something the player can use at the command line… and given that, by default, only the first 9 characters are significant, with a prefix is long as “inteletek-” you’d probably want to either go with privately-named or Use DICT_WORD_SIZE of 13 or more.

Edited to add: it might well be the case that you won’t add any commands acting on rooms, i.e., wouldn’t be adding any Understand statements with [room] tokens. In this case, creating dictionary entries corresponding to your rooms becomes optional. (But if they’re privately-named and don’t have dictionary entries associated with them, you’d lose the ability to use SHOWME on them in test versions of your game.)

or, with this recent clue on accessing an object’s internal name from @drpeterbatesuk , this should let SHOWME work for most cases…

Section internal names (not for release)

Use DICT_WORD_SIZE of 25.

To say the/-- internal name of (o - object): (- print (object) {o}; -).

A room has a text called the internal-name.
Understand the internal-name property as describing a room.

when play begins:
  repeat with r running through rooms begin;
    let name be "[internal name of r]";
    if name matches the regular expression "^\(I_(.+)_U\d+\)$" begin;
      now name is the text matching subexpression 1;
      replace the text "_" in name with "-";
      now the internal-name of r is the substituted form of name;
    else;
      say "couldn't match [name].";
    end if;
  end repeat;
2 Likes
6

I did have some code earlier in the project, but then wouldn’t code above the sample effect the first line, not the third?

1 Like
7

Honestly my way of working with inform is just guess and check. There’s a lot of weird things with names where the more specific you are the more attention it pays to you. I just compile it and then click the problem arrow; and then lookup the error online. It’s not a great method lol

1 Like
8

Thank you so much everyone for answering my admittedly vague and exasperated question. I think it probably is indeed an issue with ambiguously named objects, but it’s a moot point anyway because I’ve decided to completely switch to TADS 3, after checking it out and finding I so vastly prefer it to Inform 7 it’s not even close lol. That’s not a knock btw, I7 is extremely cool in a lot of ways, but it just doesn’t mesh with how I think very well.

8 Likes
9

T3 is arguably a better choice for experienced programmers (a category in which you include yourself). I hope you’ll try the adv3Lite library with T3. I feel it’s superior to the default adv3 library in certain ways. For instance, it borrows the Region and Scene concepts from Inform.

Not to say there aren’t experienced programmers among Inform experts!!! I’m just talking about authors, not experts in the various systems. Since Mike Roberts is no longer active in supporting TADS, the supply of experts (other than Eric and Nikos) is not large.

I don’t like to get into a flame war about the differences. It’s true that the T3 IDE is Windows-only and is rather old-school. It’s true that Inform has a huge base of Extensions, which TADS doesn’t have. It’s also true that if you enter your game in a competition, you may get fewer players voting on it because they see “TADS” and turn away. (I don’t know if this happens, but it wouldn’t surprise me to learn that it does happen once in a while.) But the advantages of working in an object-oriented C-type language are significant. Multiple inheritance, code that looks like code, faster compilation…

Also, you’ll want to know about TADS templates. Template code doesn’t even look like C code. It’s weird until you understand how it works.

3 Likes
10

Probably happens a little bit but not too much, thankfully, at least based on my impressionistic read of the IFComp judging stats. I do think many folks who don’t play TADS games frequently are more likely to just play them via a multiformat interpreter like Lectrote or Gargoyle, which is too bad because I find the QTADS experience is much, much better. So PSA to other intermittent TADS players – use QTADS!

4 Likes
11

It’s funny you mention adv3Lite, because after a couple hours of research and messing with both yesterday, I had already decided to go with it! It’s really great in my opinion; it feels like it captures all of the best parts of Inform for me — especially regions, instead of rules, relations, scenes, and a design philosophy that favors composition over inheritance while still offering most of the convenience classes provides by adv3 — while also bringing with it the best parts of TADS and adv3.

Honestly, I was worried that I would miss a lot of features going from Inform to TADS and thus, no matter which one I chose, I’d end up being unhappy with my choice. But thanks to Eric Eve, I’m actually completely satisfied! I feel like I have a library that does everything I could possibly want it to do.

In fact, it has so many amazing and useful features, implemented in composable and coherent ways, that porting over my code from Inform has been a blast — it often takes three seconds to do something that took me 30 minutes in Inform. Not just thanks to the standard library but also thanks to TADS. It’s a really well designed language that’s easy to use, succinct, and flexible. It feels like programming in Ruby a bit actually, which is a very high complement in my opinion because — while it isn’t the best at performance or correctness — it absolutely is the best for just sheer enjoyment and flexibility of prototyping.

To your point on templates, I’ve seen a little bit of what they can do so far and I’m actually incredibly impressed with them. They really add a lot to what makes the language great I think, because they allow you to be even more concise than Inform at its best without sacrificing comprehensible and consistent syntax.

One other thing I really want to compliment TADS for is the documentation. Eric Eve is amazing at writing technical documentation. I’m going through Learning TADS 3 with adv3Lite, and the conciseness of the writing combined with its thoroughness and attention to providing useful examples is a breath of fresh air compared to the Inform documentation — as are the automatically generated standard library docs, the system manual, and the library manual. I was concerned that a big problem with writing in TADS as opposed to inform would be that there are basically no Google search results for TADS, so if I ran into a question about how to do something I’d be at a loss. But for the first time in nearly a decade of programming in various languages, I’ve found that I don’t really need to Google search anything when programing with TADS. Everything just seems to jump out at me when I need it.

Also I don’t miss the Workbench at all. I’m an unrepentant Emacs user and not only that but I’m extremely dependent on VIM key bindings so most pre-made IDEs for things are kind of useless to me. Instead I’ve just been working on improving the existing tags three mode for Emacs. It’s assuredly missing many of the features that the workbench offers but I’m content to use it for now and I’m going to be expanding it over time as I figure out how to do things.

Sorry, I just had to gush.

3 Likes
12

Ooh, good to know!

13

Yeah, one of the impulses is to have rooms with names like “West of House” but room names that include directions can be notoriously tricky and often need to be spelled out explicitly to the compiler. It’s not immediately obvious until you try it that you can’t say

West of House is west of House.

which throws I7 into recursive existential fits.

I had a similar issue when I made a game where every room had a light switch, so you had “The Foyer” and “the foyer light switch” and it took a while to settle in with how I7 needs it explained.

It helps to plan your item names well in advance or just get in the habit of saying A room called "West of House"... when you mention it the first time.

2 Likes
14

Right now I’m revising the Inform Handbook, which I first wrote in 2009. My main inspiration was Eric’s “Learning TADS 3” (which predates his adv3Lite). I could see that the Inform Documentation just wasn’t up to Eric’s standard, so I aspired to do an equivalent that would help Inform authors.

Eric is quite conversant with Inform, of course. He’s written several useful Inform extensions. So it’s not really a battle of the platforms. A lot of us (or at least a few of us) go back and forth.

2 Likes
15

At the risk of spoiling my Spring Thing entry, I have:

an elevator car, elevator door, elevator hall, elevator drop key, and a drop key hole. Those last two are really fun.

Which do you mean: elevator car, elevator door, elevator hall, or elevator drop key?

> drop key

Dropped.

Oh yes: drop key.

5 Likes