This isn’t a support question so much as an understanding check.
I’m finally getting around to learning TADS, and I’m at the TravelConnectors bit of the Learning TADS manual. I noticed that although most of the various types of connectors that add some kind of destination or “other side” to the template with → still allow you to define the vocab words and name of the object the way you would any normal thing, it complained about that when I tried it with the OneWayRoomConnector. Looking at the Library Reference Manual, it looks like all the other such objects have “inherited” as part of their template, but OneWayRoomConnector does not. Why is this? Is there a reason I’m missing that you would not want to implement vocab words or a name for a one-way connector? Am I misunderstanding how this is meant to be used? Or is this an error in the template?
Hah, this one is a head scratcher I agree. It reads to me like it was conceived of as a descendent of RoomConnector, which is how rooms are stitched together (without doors or stairs or other connectors). Commonly, those are not treated as objects to pay attention to, just directions to go to get to the next location. In the case of one-way, its distinguishing feature would be WHICH way, so wanting shorthand is understandable I guess. Weirdly though, directly implemented RoomConnectors WOULD inherit from Thing as they have no templates of their own!
If there is a deeper reasoning than that, I don’t see it.
Thank you for your explanation, it makes things much clearer to me. I had been working on the exercise associated with this section in the manual and had implemented the “laundry chute” as a OneWayRoomConnector at one end and an ExitOnlyPassage at the other, but it seems that the “intended” method of implementing such a connection is to pair the ExitOnlyPassage with a regular directional passage of some sort, as the ExitOnlyPassage implements the one-way functionality on its own. For some reason I had assumed that both ends must “know” that the passage is one way, but in hindsight there’s really no reason why the “entering” side would need that information.
Basically, a TravelConnector isn’t meant to be an in-scope simulation object. Its subclasses and related classes are meant to be, such as Enterables and Stairways and the like. OneWayRoomConnector is the same kind of abstraction as a TravelConnector unless paired with something else.